📅 Original date posted:2014-01-20
📝 Original message: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 at gmail.com <mailto:christophe.biocca at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140121/2f2ab616/attachment.html>;
Thomas Voegtlin [ARCHIVE] /
npub10f…7ej47
2023-06-07 15:12:23
in reply to nevent1q…003r
Author Public Key
npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47Published at
2023-06-07 15:12:23Event JSON
{
"id": "2b73dc2b9a91cbd27bb2bd27a77e8c1ef36f89b9f1ea06b09f3178a09e41e0e9",
"pubkey": "7a4ba40070e54012212867182c66beef592603fe7c7284b72ffaafce9da20c05",
"created_at": 1686150743,
"kind": 1,
"tags": [
[
"e",
"fc93117f98479f5d69e7743f0323a5e1a0e6bc3324ce5260981ec55279ad31dc",
"",
"root"
],
[
"e",
"80b341aa8a59aa99b5acd5bbc3e2bd767c5535ca3d1baa47081c7619bcabbccb",
"",
"reply"
],
[
"p",
"eb7ca795057ca7cabde6f541c741e661d013414934e5934c2e04c6677625c99a"
]
],
"content": "📅 Original date posted:2014-01-20\n📝 Original message:Hi slush,\n\nThank you for your new proposal; it seems to be a compromise.\n\n@Christophe Biocca:\nIf the wordlist becomes part of the standard, then we will run into\nproblems of collisions once users ask for wordlists in every language.\n\nIMO the right approach is to implement checksums that do not depend\non the wordlist (eg the 'brute force' method, Hash(mnemonic||1) mod 2^k \n== 0 )\nthis would also allow us to implement sipa's variable stretching proposal.\n\nI understand this is not possible because of the computational\nrequirements of devices such as trezor.\n\nI am leaning toward considering these devices as a nonstandard case,\ninstead of enforcing a given wordlist in the standard.\n\nThomas\n\n\n\n\n\n\nLe 21/01/2014 00:18, slush a écrit :\n\u003e\n\u003e On Tue, Jan 21, 2014 at 12:06 AM, Christophe Biocca \n\u003e \u003cchristophe.biocca at gmail.com \u003cmailto:christophe.biocca at gmail.com\u003e\u003e wrote:\n\u003e\n\u003e I remember the wordlist choice getting bikeshedded to death a\n\u003e month ago.\n\u003e\n\u003e I would just include the wordlist as part of the standard (as a\n\u003e recommendation) so that fully compliant implementations can correct a\n\u003e user's typos regardless of the original generator.\n\u003e\n\u003e\n\u003e That's exactly our attitude. We realized that have a community-wide \n\u003e agreement on the wordlist itself is simply imposible, so to reach at \n\u003e least some consensus we split the proposal to two parts - one what is \n\u003e essential to call itself a \"bip39 compatible\", i.e. converting the \n\u003e mnemonic to bip32 node and second which is optional, including our \n\u003e proposed wordlist, which has some advanced features like checksums \n\u003e etc. Now it is up to client developers to decide if they really insist \n\u003e on their superior wordlist or if they'll implement checksums following \n\u003e the full specification.\n\u003e\n\u003e Those who don't like it will have to deal with the compatibility\n\u003e concerns themselves, or get an alternate wordlist approved as a BIP. \n\u003e\n\u003e Odds are no one will go that route.\n\u003e\n\u003e At least Trezor and bitcoinj (Multibit) seems to be going in this way, \n\u003e which is 100% of clients which expressed interest in bip39 :-).\n\u003e\n\u003e slush\n\u003e\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140121/2f2ab616/attachment.html\u003e",
"sig": "084eeaaa358fd5274d694aaf55b765c7086c0eaf863a75cdce270a73bc6736057fd27694c734e8279930f724666a4abc3ae6f2e51a54d81d67ae268ce3c94abf"
}