BIP0039: Final call
17 messages, 20 to 24 Jan 2014. Started by slush.
slush (3), Mike Hearn (2), Mark Friedenbach (2), Peter Todd (2), Thomas Voegtlin (2), Luke Dashjr, Brooks Boyd, Christophe Biocca, +3 more
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
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:
Quoted text (31 lines)
> 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 > >
On Monday, January 20, 2014 5:42:37 PM slush wrote:
Quoted text (9 lines)
> 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??
Quoted text (3 lines)
> 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
On Mon, Jan 20, 2014 at 9:02 PM, Luke-Jr <luke@dashjr•org> wrote:
Quoted text (5 lines)
> > 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.
Quoted text (4 lines)
> 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
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:
Quoted text (21 lines)
> 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.
Quoted text (12 lines)
> 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 >
On Mon, Jan 20, 2014 at 11:42 AM, slush <slush@centrum•cz> wrote:
Quoted text (10 lines)
> 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
On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote:
Quoted text (18 lines)
> 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?
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:
Quoted text (41 lines)
> 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 >
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:
Quoted text (39 lines)
>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
On Tue, Jan 21, 2014 at 12:06 AM, Christophe Biocca < christophe.biocca@gmail•com> wrote:
Quoted text (7 lines)
> 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.
Quoted text (2 lines)
> 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.
Quoted text (2 lines)
> >
At least Trezor and bitcoinj (Multibit) seems to be going in this way, which is 100% of clients which expressed interest in bip39 :-).
slush
Quoted text (62 lines)
> 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 >
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:
Quoted text (13 lines)
> 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 >
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 :
Quoted text (32 lines)
> > 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 >
Quoted text (4 lines)
> 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
MultiBit here.
Quoted text (4 lines)
>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.
Quoted text (4 lines)
>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.
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:
Quoted text (42 lines)
> 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 > >
On Tue, Jan 21, 2014 at 01:00:43AM +0100, Thomas Voegtlin wrote:
Quoted text (15 lines)
> 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.
Le 24/01/2014 10:05, Peter Todd a écrit :
Quoted text (23 lines)
> 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.