Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VZPTB-0007GC-In for bitcoin-development@lists.sourceforge.net; Thu, 24 Oct 2013 18:17:17 +0000 X-ACL-Warn: Received: from mail-vc0-f171.google.com ([209.85.220.171]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VZPT9-0006J7-Uw for bitcoin-development@lists.sourceforge.net; Thu, 24 Oct 2013 18:17:17 +0000 Received: by mail-vc0-f171.google.com with SMTP id lf12so1765748vcb.16 for ; Thu, 24 Oct 2013 11:17:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=ZVUSzJlbb2H+dpm3uvha7fT67OIfK1qZzWUxy3YPkZI=; b=O8KoCgdbm3+S//fAuceseWRaKhwOgJ3PN8pb6zKWl6aeXoCdj+Gaj3sWzmvPvG9ga1 +kE0rf7+wlM3v/zBNS3C8bWQ2ojFU4YmtZyQUhJrSslpVYbb/MqIbzUVubA2eWb6j3uD QssrjljoIhrel7NQwtqEVmiqo4IfxlsxcTYew/BCZdpN68s+qBQya/77yEAOpvBBzKNp jHQKjECuqD8WmBk8aLPfYeAkPgSEHdyQxVJ0+ba2iiJFSksKRAf835GL3p/DoA5W75Ls MOjh65YJ4t2ogRL8oDrOH6e61ZddAi3ReXg8aKhsubBnJEIeu/nINkoHwpnYiNxHUhE2 0kWQ== X-Gm-Message-State: ALoCoQlyGaOVvGkutVjXIEIZU7WpmM6nC5/X/+RCEPddniXZUhWl89B71aQbvhEWVmUe36XaMVge X-Received: by 10.220.164.202 with SMTP id f10mr2050318vcy.25.1382638222564; Thu, 24 Oct 2013 11:10:22 -0700 (PDT) MIME-Version: 1.0 Sender: marek@palatinus.cz Received: by 10.59.1.2 with HTTP; Thu, 24 Oct 2013 11:09:52 -0700 (PDT) In-Reply-To: References: From: slush Date: Thu, 24 Oct 2013 20:09:52 +0200 X-Google-Sender-Auth: 14hVDQgIZx68_hkwEdBGOXVW06M Message-ID: To: "thomasV1@gmx.de" Content-Type: multipart/alternative; boundary=001a11c1e9801c13b604e9808c13 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (slush[at]centrum.cz) 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: gmx.de] 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1VZPT9-0006J7-Uw Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] Proposal to replace BIP0039 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 18:17:17 -0000 --001a11c1e9801c13b604e9808c13 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 24, 2013 at 7:29 PM, wrote: > > My initial problem was that BIP0039 is not backward compatible with > Electrum. When trying to solve that, I realized that the seed encoding used > in Electrum does not help, because it does not contain a version number > information. However, BIP0039 suffers the same shortcoming: it does nothing > to help a future replacement, it wants to be final. My first recommendation > is to allocate a few bits of the mnemonic, in order to encode a "version > number" along with the checksum bits. > > 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? > The second problem is the wallet structure. There are multiple ways to use > a BIP32 tree, and each client will certainly handle this differently. For > Electrum, it is important to be able to recover an entire wallet from its > mnemonic, using no extra information. Thus, the client needs to know which > branches of the BIP32 tree are populated by default. This means that the > "version number" I mentioned will not only be about the seed encoding, but > it should also give some information about the wallet structure, at least > in the case of Electrum. > > 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. > The third problem is the dictionary. I do not like the dictionary proposed > in BIP0039, because it contains too many short words, which are bad for > memorization (I explained here how I designed the dictionary used by > Electrum: > https://bitcointalk.org/index.php?topic=153990.msg2167909#msg2167909). I > had some discussions with slush about this, but I do not think it will ever > be possible to find a consensus on that topic. > > 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. > BIP0039 also suggests to use localized dictionaries, with non-colliding > word lists, but it is not clear how that will be achieved; it seems to be > difficult, because languages often have words in common. It looks like a > first-come-first-served aproach will be used. > > 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. > For these reasons, I believe that we need a dictionary-independent > solution. This will allow developers to use the dictionary they like, and > localization will be easy. > I would like to suggest the following solution: > > 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). 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). > This solution makes it possible for developers to define new dictionaries, > localized or adapted to a particular need. > Are your worries about overlapping words across languages a real issue? slush --001a11c1e9801c13b604e9808c13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Oct 24, 2013 at 7:29 PM, <thomasV1@gmx.de><= /span> wrote:

My initial problem was that BIP0039 is not backward compatible with Electru= m. When trying to solve that, I realized that the seed encoding used in Ele= ctrum does not help, because it does not contain a version number informati= on. However, BIP0039 suffers the same shortcoming: it does nothing to help = a future replacement, it wants to be final. My first recommendation is to a= llocate a few bits of the mnemonic, in order to encode a "version numb= er" along with the checksum bits.


Two years ago I proposed exactly= this and you refused to add extra information to mnemonic, because "i= t isn't necessary" and "it makes it longer to mnemonization&q= uot;. What changed since then?
=A0
The second problem is the wallet structure. There are multiple ways to use = a BIP32 tree, and each client will certainly handle this differently. For E= lectrum, it is important to be able to recover an entire wallet from its mn= emonic, using no extra information. Thus, the client needs to know which br= anches of the BIP32 tree are populated by default. This means that the &quo= t;version number" I mentioned will not only be about the seed encoding= , but it should also give some information about the wallet structure, at l= east in the case of Electrum.


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 lookup= s for their balances.
=A0
The third problem is the dictionary. I do not like the dictionary proposed = in BIP0039, because it contains too many short words, which are bad for mem= orization (I explained here how I designed the dictionary used by Electrum:= https://bitcointalk.org/index.php?topic=3D153990= .msg2167909#msg2167909). I had some discussions with slush about this, = but I do not think it will ever be possible to find a consensus on that top= ic.


Yes, that's true. It isn'= ;t possible to make everybody 100% happy. At least I wanted to be construct= ive and asked you to replace the most problematic words. No pull request fr= om you so far.
=A0
BIP0039 also suggests to use localized dictionaries, with non-colliding wor= d lists, but it is not clear how that will be achieved; it seems to be diff= icult, because languages often have words in common. It looks like a first-= come-first-served aproach will be used.


Yes, it was original idea. So fa= r I don't think this is a problem. Of course some words may have some m= eaning across languages, but it should be easy to avoid them. There are ten= s of thousands words in every language and we need to pick "only"= 2048 words to wordlist.
=A0
For these reasons, I believe that we need a dictionary-independent solution= . This will allow developers to use the dictionary they like, and localizat= ion will be easy.=A0
I would like to suggest the following solution:


If I understand this well, it is= basically one-way algorithm "mnemonic -> seed", right? Seed c= annot 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).

Then, how is this different to picking 12 r= andom 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).


This solution makes it possible for developers to define new dictionaries, = localized or adapted to a particular need.

<= div style>Are your worries about overlapping words across languages a real = issue?
=A0
slush
--001a11c1e9801c13b604e9808c13--