* Re: [Bitcoin-development] BIP0039: Final call [not found] <mailman.423274.1390277261.21953.bitcoin-development@lists.sourceforge.net> @ 2014-01-21 5:43 ` Tamas Blummer 2014-01-21 10:01 ` Gary Rowe 0 siblings, 1 reply; 17+ messages in thread From: Tamas Blummer @ 2014-01-21 5:43 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] BIP0039: Final call 2014-01-21 5:43 ` [Bitcoin-development] BIP0039: Final call Tamas Blummer @ 2014-01-21 10:01 ` Gary Rowe 2014-01-21 10:11 ` Mike Hearn 0 siblings, 1 reply; 17+ messages in thread From: Gary Rowe @ 2014-01-21 10:01 UTC (permalink / raw) To: Bitcoin Development List [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] BIP0039: Final call 2014-01-21 10:01 ` Gary Rowe @ 2014-01-21 10:11 ` Mike Hearn 0 siblings, 0 replies; 17+ messages in thread From: Mike Hearn @ 2014-01-21 10:11 UTC (permalink / raw) To: Gary Rowe; +Cc: Bitcoin Development List [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Bitcoin-development] BIP0039: Final call
@ 2014-01-20 17:42 slush
2014-01-20 19:55 ` Mike Hearn
` (3 more replies)
0 siblings, 4 replies; 17+ messages in thread
From: slush @ 2014-01-20 17:42 UTC (permalink / raw)
To: bitcoin-development
[-- 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 --]
^ permalink raw reply [flat|nested] 17+ messages in thread* Re: [Bitcoin-development] BIP0039: Final call 2014-01-20 17:42 slush @ 2014-01-20 19:55 ` Mike Hearn 2014-01-20 20:02 ` Luke-Jr ` (2 subsequent siblings) 3 siblings, 0 replies; 17+ messages in thread From: Mike Hearn @ 2014-01-20 19:55 UTC (permalink / raw) To: slush; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] BIP0039: Final call 2014-01-20 17:42 slush 2014-01-20 19:55 ` Mike Hearn @ 2014-01-20 20:02 ` Luke-Jr 2014-01-20 21:47 ` slush 2014-01-20 22:01 ` Mark Friedenbach 2014-01-20 22:05 ` Brooks Boyd 3 siblings, 1 reply; 17+ messages in thread From: Luke-Jr @ 2014-01-20 20:02 UTC (permalink / raw) To: bitcoin-development 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] BIP0039: Final call 2014-01-20 20:02 ` Luke-Jr @ 2014-01-20 21:47 ` slush 0 siblings, 0 replies; 17+ messages in thread From: slush @ 2014-01-20 21:47 UTC (permalink / raw) To: Luke-Jr; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] BIP0039: Final call 2014-01-20 17:42 slush 2014-01-20 19:55 ` Mike Hearn 2014-01-20 20:02 ` Luke-Jr @ 2014-01-20 22:01 ` Mark Friedenbach 2014-01-20 22:05 ` Brooks Boyd 3 siblings, 0 replies; 17+ messages in thread From: Mark Friedenbach @ 2014-01-20 22:01 UTC (permalink / raw) To: bitcoin-development -----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----- ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] BIP0039: Final call 2014-01-20 17:42 slush ` (2 preceding siblings ...) 2014-01-20 22:01 ` Mark Friedenbach @ 2014-01-20 22:05 ` Brooks Boyd 2014-01-20 22:35 ` Peter Todd 3 siblings, 1 reply; 17+ messages in thread From: Brooks Boyd @ 2014-01-20 22:05 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] BIP0039: Final call 2014-01-20 22:05 ` Brooks Boyd @ 2014-01-20 22:35 ` Peter Todd 2014-01-20 23:06 ` Christophe Biocca 2014-01-20 23:14 ` Adam Back 0 siblings, 2 replies; 17+ messages in thread From: Peter Todd @ 2014-01-20 22:35 UTC (permalink / raw) To: Brooks Boyd; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] BIP0039: Final call 2014-01-20 22:35 ` Peter Todd @ 2014-01-20 23:06 ` Christophe Biocca 2014-01-20 23:18 ` slush 2014-01-20 23:14 ` Adam Back 1 sibling, 1 reply; 17+ messages in thread From: Christophe Biocca @ 2014-01-20 23:06 UTC (permalink / raw) To: bitcoin-development 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 > ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] BIP0039: Final call 2014-01-20 23:06 ` Christophe Biocca @ 2014-01-20 23:18 ` slush 2014-01-21 0:00 ` Thomas Voegtlin 0 siblings, 1 reply; 17+ messages in thread From: slush @ 2014-01-20 23:18 UTC (permalink / raw) To: Christophe Biocca; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] BIP0039: Final call 2014-01-20 23:18 ` slush @ 2014-01-21 0:00 ` Thomas Voegtlin 2014-01-24 9:05 ` Peter Todd 0 siblings, 1 reply; 17+ messages in thread From: Thomas Voegtlin @ 2014-01-21 0:00 UTC (permalink / raw) To: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] BIP0039: Final call 2014-01-21 0:00 ` Thomas Voegtlin @ 2014-01-24 9:05 ` Peter Todd 2014-01-24 16:47 ` Thomas Voegtlin 0 siblings, 1 reply; 17+ messages in thread From: Peter Todd @ 2014-01-24 9:05 UTC (permalink / raw) To: Thomas Voegtlin; +Cc: bitcoin-development [-- 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 --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] BIP0039: Final call 2014-01-24 9:05 ` Peter Todd @ 2014-01-24 16:47 ` Thomas Voegtlin 0 siblings, 0 replies; 17+ messages in thread From: Thomas Voegtlin @ 2014-01-24 16:47 UTC (permalink / raw) To: bitcoin-development 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. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] BIP0039: Final call 2014-01-20 22:35 ` Peter Todd 2014-01-20 23:06 ` Christophe Biocca @ 2014-01-20 23:14 ` Adam Back 2014-01-20 23:18 ` Mark Friedenbach 1 sibling, 1 reply; 17+ messages in thread From: Adam Back @ 2014-01-20 23:14 UTC (permalink / raw) To: Peter Todd; +Cc: 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: >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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Bitcoin-development] BIP0039: Final call 2014-01-20 23:14 ` Adam Back @ 2014-01-20 23:18 ` Mark Friedenbach 0 siblings, 0 replies; 17+ messages in thread From: Mark Friedenbach @ 2014-01-20 23:18 UTC (permalink / raw) To: bitcoin-development -----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----- ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2014-01-24 16:47 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mailman.423274.1390277261.21953.bitcoin-development@lists.sourceforge.net>
2014-01-21 5:43 ` [Bitcoin-development] BIP0039: Final call Tamas Blummer
2014-01-21 10:01 ` Gary Rowe
2014-01-21 10:11 ` Mike Hearn
2014-01-20 17:42 slush
2014-01-20 19:55 ` Mike Hearn
2014-01-20 20:02 ` Luke-Jr
2014-01-20 21:47 ` slush
2014-01-20 22:01 ` Mark Friedenbach
2014-01-20 22:05 ` Brooks Boyd
2014-01-20 22:35 ` Peter Todd
2014-01-20 23:06 ` Christophe Biocca
2014-01-20 23:18 ` slush
2014-01-21 0:00 ` Thomas Voegtlin
2014-01-24 9:05 ` Peter Todd
2014-01-24 16:47 ` Thomas Voegtlin
2014-01-20 23:14 ` Adam Back
2014-01-20 23:18 ` Mark Friedenbach
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox