Re: [Bitcoin-development] BIP0039: Final call

Re: [Bitcoin-development] BIP0039: Final call

[Tamas Blummer]

[-- Attachment #1.1: Type: text/plain, Size: 491 bytes --]

> At least Trezor and bitcoinj (Multibit) seems to be going in this way,
> which is 100% of clients which expressed interest in bip39 :-).
> 
> slush

The the current spec with TREZOR's wordlist is also implemented by Bits of Proof
https://github.com/bitsofproof/supernode/blob/master/api/src/main/java/com/bitsofproof/supernode/wallet/BIP39.java

and deployed in two projects, one being btc1k also open sourced at our github.

Regards,

Tamás Blummer
http://bitsofproof.com


[-- Attachment #1.2: Type: text/html, Size: 4267 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

Re: [Bitcoin-development] BIP0039: Final call

[Gary Rowe]

[-- Attachment #1: Type: text/plain, Size: 1171 bytes --]

MultiBit here.

>At least Trezor and bitcoinj (Multibit) seems to be going in this way,
>which is 100% of clients which expressed interest in bip39 :-).
>
>slush

We'll be using the BIP39 implementation present in Bitcoinj as slush says.

>Proper Unicode handling is a serious issue however. You don't want
>someone to move from one input method / machine to another and
>suddenly find that their coins are inaccessible, because of an issue
>of decomposed vs. compatibility forms or whatever.

We generate the word list internally (12,18,24) and confirm it is entered
correctly through a retyping operation. This will allow us to detect
character encoding transpositions (e.g. u0032 vs u00a0) and alert the user
before it becomes an issue.

While English is the language of the first word list to be implemented, we
would definitely integrate alternative non-English word lists to make life
easier for the global community. In general the approach would be for the
user to select their language (implying a locale) and then the word list to
be selected from that locale if available with a fallback to English. This
follows the same approach as resource bundles in Java.

[-- Attachment #2: Type: text/html, Size: 2188 bytes --]

Re: [Bitcoin-development] BIP0039: Final call

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2127 bytes --]

We should just perform Unicode canonicalization before any text hits the
crypto code.  There are algorithms that automatically resolve such issues.
Although with an English wordlist it would seem to make no difference
anyway.


On Tue, Jan 21, 2014 at 10:01 AM, Gary Rowe <g.rowe@froot.co.uk> wrote:

> MultiBit here.
>
> >At least Trezor and bitcoinj (Multibit) seems to be going in this way,
> >which is 100% of clients which expressed interest in bip39 :-).
> >
> >slush
>
> We'll be using the BIP39 implementation present in Bitcoinj as slush says.
>
> >Proper Unicode handling is a serious issue however. You don't want
> >someone to move from one input method / machine to another and
> >suddenly find that their coins are inaccessible, because of an issue
> >of decomposed vs. compatibility forms or whatever.
>
> We generate the word list internally (12,18,24) and confirm it is entered
> correctly through a retyping operation. This will allow us to detect
> character encoding transpositions (e.g. u0032 vs u00a0) and alert the user
> before it becomes an issue.
>
> While English is the language of the first word list to be implemented, we
> would definitely integrate alternative non-English word lists to make life
> easier for the global community. In general the approach would be for the
> user to select their language (implying a locale) and then the word list to
> be selected from that locale if available with a fallback to English. This
> follows the same approach as resource bundles in Java.
>
>
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 3757 bytes --]

Re: [Bitcoin-development] BIP0039: Final call

[Thomas Voegtlin]

Le 24/01/2014 10:05, Peter Todd a écrit :
> On Tue, Jan 21, 2014 at 01:00:43AM +0100, Thomas Voegtlin wrote:
>> Hi slush,
>>
>> Thank you for your new proposal; it seems to be a compromise.
>>
>> @Christophe Biocca:
>> If the wordlist becomes part of the standard, then we will run into
>> problems of collisions once users ask for wordlists in every language.
>>
>> IMO the right approach is to implement checksums that do not depend
>> on the wordlist (eg the 'brute force' method, Hash(mnemonic||1) mod
>> 2^k == 0 )
>> this would also allow us to implement sipa's variable stretching proposal.
>>
>> I understand this is not possible because of the computational
>> requirements of devices such as trezor.
> Is it? Surely the trezor can bruteforce, say, 8 bits == 0. How many
> SHA256/sec can the trezor hardware do? Generating your seed is a
> one-time thing after all - that taking 10-30s doesn't seem like a big
> deal to me.
>
> Even a 1/256th "checksum" will really cut down on the number of mistakes
> made and money lost.

slush, correct me if I'm wrong, but I don't think that's the only reason:
They want to generate a seed by combining entropy from the trezor device 
and from the user's computer;
In addition, they want the computer to be able to check that the seed 
actually was derived from the entropy it provided, using only a master 
public key (the computer does not have access to the seed)

This is why they designed bip39 that way.

I think the new bip39 proposal could be used in Electrum as an option 
for trezor, but I am reluctant to make it default, because it imposes 
its own dictionary.

Re: [Bitcoin-development] BIP0039: Final call

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

On Tue, Jan 21, 2014 at 01:00:43AM +0100, Thomas Voegtlin wrote:
> Hi slush,
> 
> Thank you for your new proposal; it seems to be a compromise.
> 
> @Christophe Biocca:
> If the wordlist becomes part of the standard, then we will run into
> problems of collisions once users ask for wordlists in every language.
> 
> IMO the right approach is to implement checksums that do not depend
> on the wordlist (eg the 'brute force' method, Hash(mnemonic||1) mod
> 2^k == 0 )
> this would also allow us to implement sipa's variable stretching proposal.
> 
> I understand this is not possible because of the computational
> requirements of devices such as trezor.

Is it? Surely the trezor can bruteforce, say, 8 bits == 0. How many
SHA256/sec can the trezor hardware do? Generating your seed is a
one-time thing after all - that taking 10-30s doesn't seem like a big
deal to me.

Even a 1/256th "checksum" will really cut down on the number of mistakes
made and money lost.

-- 
'peter'[:-1]@petertodd.org
0000000000000001d8b9d438c18e856735ddae5b1d918416010350d19794aab6

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] BIP0039: Final call

[Thomas Voegtlin]

[-- Attachment #1: Type: text/plain, Size: 2114 bytes --]

Hi slush,

Thank you for your new proposal; it seems to be a compromise.

@Christophe Biocca:
If the wordlist becomes part of the standard, then we will run into
problems of collisions once users ask for wordlists in every language.

IMO the right approach is to implement checksums that do not depend
on the wordlist (eg the 'brute force' method, Hash(mnemonic||1) mod 2^k 
== 0 )
this would also allow us to implement sipa's variable stretching proposal.

I understand this is not possible because of the computational
requirements of devices such as trezor.

I am leaning toward considering these devices as a nonstandard case,
instead of enforcing a given wordlist in the standard.

Thomas






Le 21/01/2014 00:18, slush a écrit :
>
> On Tue, Jan 21, 2014 at 12:06 AM, Christophe Biocca 
> <christophe.biocca@gmail.com <mailto:christophe.biocca@gmail.com>> wrote:
>
>     I remember the wordlist choice getting bikeshedded to death a
>     month ago.
>
>     I would just include the wordlist as part of the standard (as a
>     recommendation) so that fully compliant implementations can correct a
>     user's typos regardless of the original generator.
>
>
> That's exactly our attitude. We realized that have a community-wide 
> agreement on the wordlist itself is simply imposible, so to reach at 
> least some consensus we split the proposal to two parts - one what is 
> essential to call itself a "bip39 compatible", i.e. converting the 
> mnemonic to bip32 node and second which is optional, including our 
> proposed wordlist, which has some advanced features like checksums 
> etc. Now it is up to client developers to decide if they really insist 
> on their superior wordlist or if they'll implement checksums following 
> the full specification.
>
>     Those who don't like it will have to deal with the compatibility
>     concerns themselves, or get an alternate wordlist approved as a BIP. 
>
>     Odds are no one will go that route.
>
> At least Trezor and bitcoinj (Multibit) seems to be going in this way, 
> which is 100% of clients which expressed interest in bip39 :-).
>
> slush
>


[-- Attachment #2: Type: text/html, Size: 4467 bytes --]

Re: [Bitcoin-development] BIP0039: Final call

[Mark Friedenbach]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Proper Unicode handling is a serious issue however. You don't want
someone to move from one input method / machine to another and
suddenly find that their coins are inaccessible, because of an issue
of decomposed vs. compatibility forms or whatever.

On 01/20/2014 03:14 PM, Adam Back wrote:
> Because the mnemonic is an encoding of a 128-bit random number
> using its hash as a private key (or derived part of one) is not a
> problem, its just an alternate alphabet encoding of the random
> private key.
> 
> Not being able to generically understand the checksum.  Seems
> tricky to solve other than say brute force eg H(mnemonic||1) mod
> 2^k == 0 where k is the amount of check digit redundancy.  But that
> might be expensive for a trezor if k is very big at all.  And then
> key = H(mnemonic).
> 
> Adam
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS3a7MAAoJEAdzVfsmodw4/MAP/3Rk4sbQBv5aGqM2iAMBZkjq
CxGNSrzxKKgAYf+aFka6FVrBZJRHU39mEon53H0DR92+3vA2BHns8YEKH18LneQ9
16qJAp4y+ml5jbdCI6TY1JCM4ObmXsZbsPF17lKdVPISkz8DhUMUNLHdOx8cZHkw
Kj5RXuLBFwqFiCcAqYdoIpFmDpfaJfZ3k9OHzPRsto1oyOrXdwc+TK8YZHISWR3M
nzsMcp2z9Uu8M/NeDo4gM0WFpIZ41W9JsYeMeJzdU6xd1HKdmC0CZCyc8EmAre58
XGc2gtc9PjXIwWW+FTkZ5pYJz718WBq4Wja1hir5eaTJZurs1fp+1iJ7jiDkloJH
h/pWp8wcXVaAklaImota3PASr5qnP8zjzaKZALn/0gJEkIKnIJz3N32BLw7QsoEL
k5VaMQ5x7/9zK+Qc5kWvtTjleRO23DnW+XVud0jbAHTM1wfTQH0dJIgEpe3HQZOR
9a09/ZKN8kC+2fj/u6EjkVh5RvwTv0iq+RvBDmsFjaVOfBzRL1LVKgKJvdG+0hix
XyPtnBflC1uNLNg/yjBEP7/cKePJVMcDzVBwjpbnEOo9ZGO2ixSh8qMQ/nn6V96R
hZZv8mVI1bGhWlvQEoMw5X7M4xyP25GboCv4wJrYT/8VQfe56BSKXS+AHfl+hIoa
Jjmcqvm+sfk/0awxj4Ce
=1crJ
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] BIP0039: Final call

[slush]

[-- Attachment #1: Type: text/plain, Size: 4086 bytes --]

On Tue, Jan 21, 2014 at 12:06 AM, Christophe Biocca <
christophe.biocca@gmail.com> wrote:

> I remember the wordlist choice getting bikeshedded to death a month ago.
>
> I would just include the wordlist as part of the standard (as a
> recommendation) so that fully compliant implementations can correct a
> user's typos regardless of the original generator.
>
>
That's exactly our attitude. We realized that have a community-wide
agreement on the wordlist itself is simply imposible, so to reach at least
some consensus we split the proposal to two parts - one what is essential
to call itself a "bip39 compatible", i.e. converting the mnemonic to bip32
node and second which is optional, including our proposed wordlist, which
has some advanced features like checksums etc. Now it is up to client
developers to decide if they really insist on their superior wordlist or if
they'll implement checksums following the full specification.



> Those who don't like it will have to deal with the compatibility
> concerns themselves, or get an alternate wordlist approved as a BIP.

Odds are no one will go that route.
>
>
At least Trezor and bitcoinj (Multibit) seems to be going in this way,
which is 100% of clients which expressed interest in bip39 :-).

slush


> On Mon, Jan 20, 2014 at 5:35 PM, Peter Todd <pete@petertodd.org> wrote:
> > On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote:
> >> On Mon, Jan 20, 2014 at 11:42 AM, slush <slush@centrum.cz> wrote:
> >>
> >> > Hi all,
> >> >
> >> > during recent months we've reconsidered all comments which we received
> >> > from the community about our BIP39 proposal and we tried to meet all
> >> > requirements for such standard. Specifically the proposal now doesn't
> >> > require any specific wordlist, so every client can use its very own
> list of
> >> > preferred words. Generated mnemonic can be then applied to any other
> >> > BIP39-compatible client. Please follow current draft at
> >> > https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.
> >>
> >> So, because the [mnemonic]->[bip32 root] is just hashing, you've
> >> effectively made your "mnemonic sentence" into a brainwallet? Since
> every
> >> mnemonic sentence can now lead to a bip32 root, and only the client that
> >> created the mnemonic can verify the mnemonic passes its checksum
> (assuming
> >> all clients use different wordlists, the only client that can help you
> if
> >> you fat-finger the sentence is the client that created it)?
> >
> > That issue is more than enough to get a NACK from me on making the
> > current BIP39 draft a standard - I can easily see that leading to users
> > losing a lot of money.
> >
> > Have any wallets implemented BIP39 this way already in released code?
> >
> > --
> > 'peter'[:-1]@petertodd.org
> > 00000000000000009c3092c0b245722363df8b29cfbb86368f4f7303e655983a
> >
> >
> ------------------------------------------------------------------------------
> > CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> > Learn Why More Businesses Are Choosing CenturyLink Cloud For
> > Critical Workloads, Development Environments & Everything In Between.
> > Get a Quote or Start a Free Trial Today.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 6435 bytes --]

Re: [Bitcoin-development] BIP0039: Final call

[Adam Back]

Because the mnemonic is an encoding of a 128-bit random number using its
hash as a private key (or derived part of one) is not a problem, its just an
alternate alphabet encoding of the random private key.

Not being able to generically understand the checksum.  Seems tricky to
solve other than say brute force eg H(mnemonic||1) mod 2^k == 0 where k is
the amount of check digit redundancy.  But that might be expensive for a
trezor if k is very big at all.  And then key = H(mnemonic).

Adam

On Mon, Jan 20, 2014 at 05:35:02PM -0500, Peter Todd wrote:
>On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote:
>> On Mon, Jan 20, 2014 at 11:42 AM, slush <slush@centrum.cz> wrote:
>>
>> > Hi all,
>> >
>> > during recent months we've reconsidered all comments which we received
>> > from the community about our BIP39 proposal and we tried to meet all
>> > requirements for such standard. Specifically the proposal now doesn't
>> > require any specific wordlist, so every client can use its very own list of
>> > preferred words. Generated mnemonic can be then applied to any other
>> > BIP39-compatible client. Please follow current draft at
>> > https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.
>>
>> So, because the [mnemonic]->[bip32 root] is just hashing, you've
>> effectively made your "mnemonic sentence" into a brainwallet? Since every
>> mnemonic sentence can now lead to a bip32 root, and only the client that
>> created the mnemonic can verify the mnemonic passes its checksum (assuming
>> all clients use different wordlists, the only client that can help you if
>> you fat-finger the sentence is the client that created it)?
>
>That issue is more than enough to get a NACK from me on making the
>current BIP39 draft a standard - I can easily see that leading to users
>losing a lot of money.
>
>Have any wallets implemented BIP39 this way already in released code?
>
>-- 
>'peter'[:-1]@petertodd.org
>00000000000000009c3092c0b245722363df8b29cfbb86368f4f7303e655983a



>------------------------------------------------------------------------------
>CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>Learn Why More Businesses Are Choosing CenturyLink Cloud For
>Critical Workloads, Development Environments & Everything In Between.
>Get a Quote or Start a Free Trial Today.
>http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] BIP0039: Final call

[Christophe Biocca]

I remember the wordlist choice getting bikeshedded to death a month ago.

I would just include the wordlist as part of the standard (as a
recommendation) so that fully compliant implementations can correct a
user's typos regardless of the original generator.

Those who don't like it will have to deal with the compatibility
concerns themselves, or get an alternate wordlist approved as a BIP.
Odds are no one will go that route.

On Mon, Jan 20, 2014 at 5:35 PM, Peter Todd <pete@petertodd.org> wrote:
> On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote:
>> On Mon, Jan 20, 2014 at 11:42 AM, slush <slush@centrum.cz> wrote:
>>
>> > Hi all,
>> >
>> > during recent months we've reconsidered all comments which we received
>> > from the community about our BIP39 proposal and we tried to meet all
>> > requirements for such standard. Specifically the proposal now doesn't
>> > require any specific wordlist, so every client can use its very own list of
>> > preferred words. Generated mnemonic can be then applied to any other
>> > BIP39-compatible client. Please follow current draft at
>> > https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.
>>
>> So, because the [mnemonic]->[bip32 root] is just hashing, you've
>> effectively made your "mnemonic sentence" into a brainwallet? Since every
>> mnemonic sentence can now lead to a bip32 root, and only the client that
>> created the mnemonic can verify the mnemonic passes its checksum (assuming
>> all clients use different wordlists, the only client that can help you if
>> you fat-finger the sentence is the client that created it)?
>
> That issue is more than enough to get a NACK from me on making the
> current BIP39 draft a standard - I can easily see that leading to users
> losing a lot of money.
>
> Have any wallets implemented BIP39 this way already in released code?
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000009c3092c0b245722363df8b29cfbb86368f4f7303e655983a
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

Re: [Bitcoin-development] BIP0039: Final call

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote:
> On Mon, Jan 20, 2014 at 11:42 AM, slush <slush@centrum.cz> wrote:
> 
> > Hi all,
> >
> > during recent months we've reconsidered all comments which we received
> > from the community about our BIP39 proposal and we tried to meet all
> > requirements for such standard. Specifically the proposal now doesn't
> > require any specific wordlist, so every client can use its very own list of
> > preferred words. Generated mnemonic can be then applied to any other
> > BIP39-compatible client. Please follow current draft at
> > https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.
> 
> So, because the [mnemonic]->[bip32 root] is just hashing, you've
> effectively made your "mnemonic sentence" into a brainwallet? Since every
> mnemonic sentence can now lead to a bip32 root, and only the client that
> created the mnemonic can verify the mnemonic passes its checksum (assuming
> all clients use different wordlists, the only client that can help you if
> you fat-finger the sentence is the client that created it)?

That issue is more than enough to get a NACK from me on making the
current BIP39 draft a standard - I can easily see that leading to users
losing a lot of money.

Have any wallets implemented BIP39 this way already in released code?

-- 
'peter'[:-1]@petertodd.org
00000000000000009c3092c0b245722363df8b29cfbb86368f4f7303e655983a

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] BIP0039: Final call

[Brooks Boyd]

[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]

On Mon, Jan 20, 2014 at 11:42 AM, slush <slush@centrum.cz> wrote:

> Hi all,
>
> during recent months we've reconsidered all comments which we received
> from the community about our BIP39 proposal and we tried to meet all
> requirements for such standard. Specifically the proposal now doesn't
> require any specific wordlist, so every client can use its very own list of
> preferred words. Generated mnemonic can be then applied to any other
> BIP39-compatible client. Please follow current draft at
> https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.
>


So, because the [mnemonic]->[bip32 root] is just hashing, you've
effectively made your "mnemonic sentence" into a brainwallet? Since every
mnemonic sentence can now lead to a bip32 root, and only the client that
created the mnemonic can verify the mnemonic passes its checksum (assuming
all clients use different wordlists, the only client that can help you if
you fat-finger the sentence is the client that created it)?

Brooks

[-- Attachment #2: Type: text/html, Size: 1674 bytes --]

Re: [Bitcoin-development] BIP0039: Final call

[Mark Friedenbach]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Since you are taking the hash of Unicode data, I would strongly
recommend using a canonical form, e.g. Normalized Form C.

On 01/20/2014 09:42 AM, slush wrote:
> Hi all,
> 
> during recent months we've reconsidered all comments which we
> received from the community about our BIP39 proposal and we tried
> to meet all requirements for such standard. Specifically the
> proposal now doesn't require any specific wordlist, so every client
> can use its very own list of preferred words. Generated mnemonic
> can be then applied to any other BIP39-compatible client. Please
> follow current draft at
> https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.
> 
> Because we're quickly moving towards release of Trezor firmware and
> we need to finalize this part of the firmware, we're asking for the
> last comments to current BIP39 draft.
> 
> Thanks, slush
> 
> 
> ------------------------------------------------------------------------------
>
> 
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For 
> Critical Workloads, Development Environments & Everything In
> Between. Get a Quote or Start a Free Trial Today. 
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>
> 
> 
> 
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS3ZzAAAoJEAdzVfsmodw4L3sP/2VjvICLTYlkZcY6brBIZhoU
P6ei6qECzmBCWpW5iC1r99j76bPwP3M6jH6P7iBljj72J5NgHXq+K8GvA5M6qu0o
6s+WJ7HYJ8KwRZuvGPvcopXBKJAJXadrN7xSPikYD2zMm2KCZTUI5IurR1p/dpUR
3HzL2RdjbDugBOiAjiMMq0dAs1x9/vmF0F2KDZHiCJEtP/+gbtOE/KmXrnrAJSNI
Aswb/lZg1GWGpOs+iCdEaRfST2PIL/jGgnteJ4iKHvh2+dOW0/AhINo5g56LTVvU
Q+pAv8SRLad/30PVaWAStrtLMxu+j0JQ1wgEkRCrsQ0xE3iKtmbppzh2dIQ8Idrt
EkjqoykB2wn4Kw+QcT2TXIcBV7LBqSurE/jDWWIFtHxdV0++8PDYFOesq2Xf9Rif
VStYnUVvUhuzGXD3oOnIGpEvMm2i30Qyi33oJLvqfWUBkzJzFdtZ+YYBYlbpwBOQ
YLEr2DmVHLk/MXWL1POruvnIT4N+6uyh59HKHKRJI0nGMmRR3cBLkM8vEEHerD3P
ucg++TTdqXM6XoSmIk55CQnGdglDJEOGc+gzaGffqeDMJhmz/apEawN5en7ogN0o
XfWDWSdtwMvlza3F6cMejvBkuFZTLUxyaedP13vOTDhUIbmqsliyhwA2YrXE7udQ
1JMYADuvb18LYE/hQJX3
=Ycdc
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] BIP0039: Final call

[slush]

[-- Attachment #1: Type: text/plain, Size: 788 bytes --]

On Mon, Jan 20, 2014 at 9:02 PM, Luke-Jr <luke@dashjr.org> wrote:

>
> How are they compatible if they could be using entirely different word
> lists??
>
>
Wordlist is necessary for the step [seed]->[mnemonic]. Step
[mnemonic]->[bip32 root] doesn't need any wordlist, there's just hashing
involved.
For this reason client can generate whatever mnemonic and unless all
clients use the same process [mnemonic]->[bip32 root], the result is the
same.


> Maybe I'm missing something, but shouldn't this be a client-side thing, not
> implemented in the Trezor firmware at all?? O.o;;
>
>
Trezor generates the seed and transforms it to mnemonic (which is then
shown on internal display). Generating the mnemonic outside the client-side
(computer) is one of main functionality of Trezor.

slush

[-- Attachment #2: Type: text/html, Size: 1381 bytes --]

Re: [Bitcoin-development] BIP0039: Final call

[Luke-Jr]

On Monday, January 20, 2014 5:42:37 PM slush wrote:
> Hi all,
> 
> during recent months we've reconsidered all comments which we received from
> the community about our BIP39 proposal and we tried to meet all
> requirements for such standard. Specifically the proposal now doesn't
> require any specific wordlist, so every client can use its very own list of
> preferred words. Generated mnemonic can be then applied to any other
> BIP39-compatible client. Please follow current draft at
> https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.

How are they compatible if they could be using entirely different word lists??

> Because we're quickly moving towards release of Trezor firmware and we need
> to finalize this part of the firmware, we're asking for the last comments
> to current BIP39 draft.

Maybe I'm missing something, but shouldn't this be a client-side thing, not 
implemented in the Trezor firmware at all?? O.o;;

Luke

Re: [Bitcoin-development] BIP0039: Final call

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]

We have an implementation of the latest spec in bitcoinj, with the wordlist
provided by slush+stick. As far as I can see it's all working fine so LGTM
from us.


On Mon, Jan 20, 2014 at 5:42 PM, slush <slush@centrum.cz> wrote:

> Hi all,
>
> during recent months we've reconsidered all comments which we received
> from the community about our BIP39 proposal and we tried to meet all
> requirements for such standard. Specifically the proposal now doesn't
> require any specific wordlist, so every client can use its very own list of
> preferred words. Generated mnemonic can be then applied to any other
> BIP39-compatible client. Please follow current draft at
> https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.
>
> Because we're quickly moving towards release of Trezor firmware and we
> need to finalize this part of the firmware, we're asking for the last
> comments to current BIP39 draft.
>
> Thanks,
> slush
>
>
> ------------------------------------------------------------------------------
> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
> Learn Why More Businesses Are Choosing CenturyLink Cloud For
> Critical Workloads, Development Environments & Everything In Between.
> Get a Quote or Start a Free Trial Today.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 2510 bytes --]

[Bitcoin-development] BIP0039: Final call

[slush]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

Hi all,

during recent months we've reconsidered all comments which we received from
the community about our BIP39 proposal and we tried to meet all
requirements for such standard. Specifically the proposal now doesn't
require any specific wordlist, so every client can use its very own list of
preferred words. Generated mnemonic can be then applied to any other
BIP39-compatible client. Please follow current draft at
https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.

Because we're quickly moving towards release of Trezor firmware and we need
to finalize this part of the firmware, we're asking for the last comments
to current BIP39 draft.

Thanks,
slush

[-- Attachment #2: Type: text/html, Size: 1048 bytes --]