On 17/11/13 01:42, Timo Hanke wrote:
> p.s. The question about auditing entropy would only apply to the generator,
> not the wallet. Is it yet documented how Trezor proves that external
> entropy was used?
We'll probably use the most straightforward way:
a) trezor prints entropy A on a display (p
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 tha
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 pr
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
---
On Sun, Nov 03, 2013 at 09:39:42AM +0100, Thomas Voegtlin wrote:
>
> 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
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
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 corresp
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,
On Sat, Nov 02, 2013 at 10:44:58AM +0100, Thomas Voegtlin 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 entro
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 solv
> 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 full private information to
> other computer, j
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 n
On Thu, Oct 31, 2013 at 10:13 AM, Thomas Voegtlin 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 common standard
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 leaki
Strange, I didn't receive the response from sipa in separate message, so
I'll respond to him at first place.
Le 26/10/2013 23:30, Pieter Wuille a écrit :
> I'm not sure whether we're ready to standardize on something like that
> yet, not having established best practices regarding different wallet
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 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 lik
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 specific
here is a simple implementation, with some ideas on how to format the
metadata:
https://en.bitcoin.it/wiki/Talk:BIP_0039
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application p
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
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
On Thu, Oct 24, 2013 at 7:29 PM, 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. However, BIP0039 su
On Thu, Oct 24, 2013 at 7:29 PM, 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. However, BIP0039 s
23 matches
Mail list logo
