On 04/11/13 16:10, Timo Hanke wrote:
Does Trezor even use private derivation?
No. It can't. Private keys never leave the device so client would not
know how to generate addresses.
--
Best Regards / S pozdravom,
Pavol Rusnak st...@gk2.sk
On 03/11/13 08:40, Timo Hanke wrote:
Trezor picks random s and sends S=s*G to computer, keeping s secret.
That's a really neat trick!
One question remains: if you only write down the mnemonic how can you be
sure that it is correct and corresponds to the secret in Trezor?
Right. That's a
On Sun, Nov 17, 2013 at 12:49:04AM +0100, Pavol Rusnak wrote:
On 03/11/13 08:40, Timo Hanke wrote:
Trezor picks random s and sends S=s*G to computer, keeping s secret.
That's a really neat trick!
One question remains: if you only write down the mnemonic how can you be
sure that it is
Le 03/11/2013 07:41, Timo Hanke a écrit :
No. You mean the computer would use B for this check? (k,K) could be
rigged by Trezor, who computes b as k-a. Timo
I was just asking a question, in order to understand how this device
works, and what are its requirements.
if you think you can help,
I think the communication would have to go the other way around. Trezor
has to commit to a value First. Like this:
Trezor picks random s and sends S=s*G to computer, keeping s secret.
Computer picks random t and sends t to Trezor. Trezor makes r := s+t
its internal master private key with
Le 03/11/2013 08:40, Timo Hanke a écrit :
I think the communication would have to go the other way around. Trezor
has to commit to a value First. Like this:
Trezor picks random s and sends S=s*G to computer, keeping s secret.
Computer picks random t and sends t to Trezor. Trezor makes r :=
Le 31/10/2013 12:18, slush a écrit :
Oh, I forgot to one practical aspect; the way how the mnemonic is
mined in Thomas proposal prevents usage in embedded devices, because
difficulty of generating proper mnemonic is simply too high for
embedded microcontrollers. Maybe this can be solved
Indeed, I want to include a version number in the seed phrase because
there are
multiple ways to define the tree structure used with BIP32. It is
certainly too early
to make final decisions on that, or to achieve a common standard.
Also, I can imagine that bip32 itself might be superseeded in
On Thu, Oct 31, 2013 at 11:41:27AM +0100, slush wrote:
To be specific, we (in cooperation with / inspired by Timo Hanke) developed
method how to prove that the seed generated by Trezor has been created
using combination of computer-provided entropy and device-provided entropy,
without leaking
On Thu, Oct 31, 2013 at 10:13 AM, Thomas Voegtlin thoma...@gmx.de wrote:
Indeed, I want to include a version number in the seed phrase because
there are
multiple ways to define the tree structure used with BIP32. It is
certainly too early
to make final decisions on that, or to achieve a
Oh, I forgot to one practical aspect; the way how the mnemonic is mined
in Thomas proposal prevents usage in embedded devices, because difficulty
of generating proper mnemonic is simply too high for embedded
microcontrollers. Maybe this can be solved somehow by modifying the
proposal, but right
Hi Thomas,
can you more elaborate on that version bits? What is exact meaning of it?
I still think this is more an implementation problem. What stops Electrum
to do the same algorithm for searching branches as it is now for used
addresses?
These version bits need to be covered by the
Let's first try to agree on what we are solving.
It seems that Thomas wants - in addition to the cryptographic data -
to encode the tree structure, or at least version information about
what features are used in it, inside the seed.
I'm not sure whether we're ready to standardize on something
slush wrote :
Two years ago I proposed exactly this and you refused to add extra
information to mnemonic, because it isn't necessary and it makes it
longer to mnemonization. What changed since then?
I was wrong, and I fully acknowledge it.
My concern was that adding extra information would
I would like to propose a new BIP, that replaces BIP0039.
My initial problem was that BIP0039 is not backward compatible with Electrum.
When trying to solve that, I realized that the seed encoding used in Electrum
does not help, because it does not contain a version number information.
On Thu, Oct 24, 2013 at 7:29 PM, thoma...@gmx.de wrote:
My initial problem was that BIP0039 is not backward compatible with
Electrum. When trying to solve that, I realized that the seed encoding used
in Electrum does not help, because it does not contain a version number
information.
On Thursday, October 24, 2013 5:29:18 PM thoma...@gmx.de wrote:
I would like to propose a new BIP, that replaces BIP0039.
BIP 39 is still a draft. Just suggest revisions to the author(s)...
--
October Webinars: Code for
17 matches
Mail list logo
