From: Thomas Voegtlin <thomasv1@gmx•de>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Proposal to replace BIP0039
Date: Fri, 25 Oct 2013 11:27:24 +0200 [thread overview]
Message-ID: <526A397C.2080006@gmx.de> (raw)
In-Reply-To: <CAJna-HhzGmdoaaoFkp8tBeKCZ4DhDpNO43wzzk_ke7-kH2smbg@mail.gmail.com>
slush wrote :
> Two years ago I proposed exactly this and you refused to add extra
> information to mnemonic, because "it isn't necessary" and "it makes it
> longer to mnemonization". What changed since then?
I was wrong, and I fully acknowledge it.
My concern was that adding extra information would make the mnemonic
longer than 12 words.
In addition, you proposed to allocate these extra bits for a checksum,
not for metadata.
However, a checksum does not really add any information, because
Electrum checks the existence of a wallet directly from the blockchain.
So, my feeling at that time was that adding extra bits would increase
the risks (a longer seed is harder to memorize, increases the
probability of mistakes, etc), and did not bring any real benefit.
However, you showed since then how to solve this by using a slightly
longer dictionary, and I do like your solution, I find it absolutely
brilliant.
In addition, I realize now that metadata (ie a "version number") is
crucially needed, for the reasons mentioned in my previous post.
> Hm, what exactly do you need to store about wallet structure? I lived
> in opinion that everything is able to recover using CKD function to
> generate new addresses and blockchain lookups for their balances.
BIP32 gives a lot of freedom to wallet developers: it does not specify
which branches of the HD tree shall be used for which purpose.
However, if you want to recover a wallet from its mnemonic (a
requirement for Electrum), then you need to know which branches to explore.
In Electrum 1.9 I had to make some choices about branch allocation.
However, the decisions that I made are certainly not final, so it is
important to be able to change them in the future. Thus, this metadata
needs to be added to the mnemonic.
> Yes, that's true. It isn't possible to make everybody 100% happy. At
> least I wanted to be constructive and asked you to replace the most
> problematic words. No pull request from you so far.
The solution I propose is very different from BIP39, and it does not
require to predefine a dictionary.
My proposal is actually somewhat similar to Pieter Wuille's proposal,
which I discovered after his recent post.
( https://bitcointalk.org/index.php?topic=102349.0 )
> Yes, it was original idea. So far I don't think this is a problem. Of
> course some words may have some meaning across languages, but it
> should be easy to avoid them. There are tens of thousands words in
> every language and we need to pick "only" 2048 words to wordlist.
> ...
> Are your worries about overlapping words across languages a real issue?
No, there are not so many words that are frequent enough.
Overlapping will be an issue, especially if we go for a 4096 words
dictionary.
> If I understand this well, it is basically one-way algorithm "mnemonic
> -> seed", right? Seed cannot be printed out as mnemonic, because
> there's hashing involved, but the bi-directionality has been the
> original requirement for such algorithm (at least in Electrum and bip39).
You are right, this encoding is not symmetric.
Bi-directionality has never been a requirement for Electrum. May I ask
why you need bi-directionality in Trezor?
(the only reason I can think of is if you want to export a bip32 branch
into another wallet, but this would create a very long mnemonic string)
> Then, how is this different to picking 12 random words from dictionary
> and hashing them together? I don't see any benefit in that "mining"
> part of the proposal (except that it is lowering the entropy for given
> length of mnemonic).
it makes it possible to hash a utf8 string, and to retrieve the metadata
from the hash.
Thus we don't need to spend ages arguing about the best choice of a
dictionary, and to set it in stone.
next prev parent reply other threads:[~2013-10-25 9:27 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-24 17:29 thomasV1
2013-10-24 18:09 ` slush
2013-10-25 9:27 ` Thomas Voegtlin [this message]
2013-10-24 18:54 ` slush
2013-10-26 15:24 ` Thomas Voegtlin
2013-10-26 20:47 ` slush
2013-10-26 21:30 ` Pieter Wuille
2013-10-31 9:13 ` Thomas Voegtlin
2013-10-31 10:41 ` slush
2013-10-31 11:07 ` Peter Todd
2013-11-02 9:44 ` Thomas Voegtlin
2013-11-03 6:41 ` Timo Hanke
2013-11-03 7:03 ` Thomas Voegtlin
2013-11-03 7:40 ` Timo Hanke
2013-11-03 8:39 ` Thomas Voegtlin
2013-11-04 15:10 ` Timo Hanke
2013-11-16 23:41 ` Pavol Rusnak
2013-11-16 23:49 ` Pavol Rusnak
2013-11-17 0:42 ` Timo Hanke
2013-11-17 0:49 ` Pavol Rusnak
2013-10-31 11:11 ` slush
2013-10-31 11:18 ` slush
2013-11-02 10:10 ` Thomas Voegtlin
2013-10-24 21:55 ` Luke-Jr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=526A397C.2080006@gmx.de \
--to=thomasv1@gmx$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox