From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WNonf-0000X0-7e for bitcoin-development@lists.sourceforge.net; Wed, 12 Mar 2014 19:26:47 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of me.com designates 17.172.220.236 as permitted sender) client-ip=17.172.220.236; envelope-from=jeanpaulkogelman@me.com; helo=st11p02mm-asmtp001.mac.com; Received: from st11p02mm-asmtpout001.mac.com ([17.172.220.236] helo=st11p02mm-asmtp001.mac.com) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WNone-0001kJ-2m for bitcoin-development@lists.sourceforge.net; Wed, 12 Mar 2014 19:26:47 +0000 Received: from st11p02mm-spool001.mac.com ([17.172.220.246]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTP id <0N2C004A38OFVY90@st11p02mm-asmtp001.mac.com> for bitcoin-development@lists.sourceforge.net; Wed, 12 Mar 2014 19:26:40 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87,1.0.14,0.0.0000 definitions=2014-03-12_07:2014-03-12, 2014-03-12, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1401130000 definitions=main-1403120110 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_CKLxorly3Iyv6nT+FElvig)" Received: from localhost ([17.172.220.223]) by st11p02mm-spool001.mac.com (Oracle Communications Messaging Server 7u4-27.01(7.0.4.27.0) 64bit (built Aug 30 2012)) with ESMTP id <0N2C00F018OF6HC0@st11p02mm-spool001.mac.com>; Wed, 12 Mar 2014 19:26:39 +0000 (GMT) To: Pavol Rusnak From: Jean-Paul Kogelman Date: Wed, 12 Mar 2014 19:26:39 +0000 (GMT) X-Mailer: iCloud MailClient14A49 MailServer14A.15417 X-Originating-IP: [159.153.138.53] Message-id: <44fcb02b-3784-45a6-816a-312c78d940cd@me.com> In-reply-to: <53208356.7010209@gk2.sk> X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.0 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars X-Headers-End: 1WNone-0001kJ-2m Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] [RFC] Proposal: Base58 encoded HD Wallet root key with optional encryption 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: Wed, 12 Mar 2014 19:26:47 -0000 --Boundary_(ID_CKLxorly3Iyv6nT+FElvig) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable =0A=0AOn Mar 12, 2014, at 08:55 AM, Pavol Rusnak wrote:=0A=0A= On 03/12/2014 04:45 PM, Jean-Paul Kogelman wrote:=0AYes I am. There are so= me differences between BIP 39 and my proposal though.=0A- BIP 39 offers an= easy list of words, no gnarly string of case sensitive letters and number= s.=0A=0AWhich is better IMO. I can't imagine anyone writing down a long Ba= se58=0Aencoded string.=0A=A0=0AThat depends on your use case. A list of wo= rds is totally fine for someone to write down, a long string of case sensi= tive letters is easier to put into a QR code.=0A=0A=0A- BIP 39 only offers= one fixed length of entropy, always 12 words, no option to increase or de= crease the length.=0A=0ANot true, BIP39 supports 12/18/24 words (=3D 128/1= 92/256 bits of entropy).=0A=A0=0AI stand corrected.=0A=0A=0A- BIP 39 doesn= 't have a genesis date field, so no optimization during blockchain rescan.= =0A=0AThis is nice addition, indeed. But we needed to limit the data as=0A= possible in order not to increase the number of words needed to be noted=0A= down.=0A=A0=0AMy proposal didn't have this either initially, but it was de= emed an essential feature for SPV clients.=0A=0A=0A- BIP 39 doesn't have p= assword typo detection. No easy way to recover a password if you know most= of it.=0A=0AIt has a detection. Not correction though.=0A=A0=0AIf I under= stand the code correctly (and please correct me if I'm wrong), the validat= ion only happens on the mnemonic list, not on the password:=0A=0A"Describe= d method also provides plausible deniability, because every passphrase gen= erates a valid seed (and thus deterministic wallet) but only the correct o= ne will make the desired wallet available"=0A=0ASo upon entering a passwor= d with a typo, the user will not be notified of an error, but be presented= with a wallet balance of 0, after the blockchain has been scanned. I'm so= rry, but that's not the kind of experience I would want to present to my u= sers.=0A=0A=0A- BIP 39 does not have a user selectable KDF, only 2048 roun= d PBKDF2-HMAC-SHA512.=0A- BIP 39 can't outsource the KDF computation to a = 3rd party.=0A=0ATrue, but having one or two solid options are better than = having=0Agazillions of possible options.=0A=A0=0A5 defined KDFs out of a p= ossible 32 is hardly "gazillions".=0A=0A- BIP 39 wallet implementors can u= se their own word lists, breaking cross wallet compatibility.=0A=0ATrue, b= ut they are encouraged to use the list provided. Possibility to=0Aoutsourc= e KDF outside of your "standard" breaks much more compatibility=0Athan thi= s.=0A=A0=0AWould you care to elaborate how optional outsourcing of the KDF= breaks compatibility?=0A=0Ajp=0A=0A= --Boundary_(ID_CKLxorly3Iyv6nT+FElvig) Content-type: multipart/related; boundary="Boundary_(ID_62p/hF7SnXG+aZ/xu/4xqQ)"; type="text/html" --Boundary_(ID_62p/hF7SnXG+aZ/xu/4xqQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable


On Mar 12, 2014, at 08:55 AM, Pavol Rusnak <stick@gk2.sk&g= t; wrote:

On 03/12/2014 04:45 PM, Jean-Paul Kogelman wr= ote:
Yes I am. Th= ere are some differences between BIP 39 and my proposal though.
- BIP 39 offers an easy l= ist of words, no gnarly string of case sensitive letters and numbers.
Which is better IMO. I can't imagine anyone writing down a lo= ng Base58
encoded string.
 
That depends on your use case. A list of words is totally f= ine for someone to write down, a long string of case sensitive letters is = easier to put into a QR code.


- BIP 39 only offers one fixed length of entr= opy, always 12 words, no option to increase or decrease the length.
Not true, BIP39 supports 12/18/24 words (=3D 128/192/256 bits o= f entropy).
 
I s= tand corrected.


- BIP 39 doesn't have a genesis date field, so n= o optimization during blockchain rescan.

This is nice add= ition, indeed. But we needed to limit the data as
possible in order no= t to increase the number of words needed to be noted
down.
<= /div>
 
My proposal didn't have th= is either initially, but it was deemed an essential feature for SPV client= s.


- BIP 39 doesn't have password typo detection. No easy way to= recover a password if you know most of it.

It has a dete= ction. Not correction though.
 
If I understand the code correctly (and please correct me i= f I'm wrong), the validation only happens on the mnemonic list, not on the= password:

"Described method also provides plausible deniability, because ev= ery passphrase generates a valid seed (and thus deterministic wallet) but = only the correct one will make the desired wallet available"
<= div>
<= span style=3D"color: rgb(51, 51, 51); font-family: Helvetica, arial, frees= ans, clean, sans-serif; line-height: 25.5px;">So upon entering a password = with a typo, the user will not be notified of an error, but be presented w= ith a wallet balance of 0, after the blockchain has been scanned. I'm sorr= y, but that's not the kind of experience I would want to present to my use= rs.


- BIP 39 does not have a user selectable KDF, only 2048 round PB= KDF2-HMAC-SHA512.
- BIP 39 can't outsource the KDF computation to a 3rd party.
True, but having one or two solid options are better than ha= ving
gazillions of possible options.
 
5 defined KDFs out of a possible 32 is hardly "g= azillions".

- BIP 39 wallet implementors can use their own word lists,= breaking cross wallet compatibility.

True, but they are = encouraged to use the list provided. Possibility to
outsource KDF outs= ide of your "standard" breaks much more compatibility
than this.
<= /div>
 
Would you care to el= aborate how optional outsourcing of the KDF breaks compatibility?

jp

= --Boundary_(ID_62p/hF7SnXG+aZ/xu/4xqQ)-- --Boundary_(ID_CKLxorly3Iyv6nT+FElvig)--