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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YW7D2-0001oi-C9 for bitcoin-development@lists.sourceforge.net; Thu, 12 Mar 2015 17:47:48 +0000 X-ACL-Warn: Received: from gproxy5-pub.mail.unifiedlayer.com ([67.222.38.55]) by sog-mx-3.v43.ch3.sourceforge.com with smtp (Exim 4.76) id 1YW7D0-00045W-HL for bitcoin-development@lists.sourceforge.net; Thu, 12 Mar 2015 17:47:48 +0000 Received: (qmail 23078 invoked by uid 0); 12 Mar 2015 17:21:01 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy5.mail.unifiedlayer.com with SMTP; 12 Mar 2015 17:21:01 -0000 Received: from just26.justhost.com ([173.254.28.26]) by cmgw2 with id 2hLv1q00j0ZoGd101hLyw0; Thu, 12 Mar 2015 11:20:59 -0600 X-Authority-Analysis: v=2.1 cv=d8xml3TE c=1 sm=1 tr=0 a=W0pEH2JMt/Z8OgX48NRskQ==:117 a=BY8XqHikAAAA:8 a=f5113yIGAAAA:8 a=AUjNyygZAAAA:8 a=pGLkceISAAAA:8 a=1XWaLZrsAAAA:8 a=geqOZIdv6ycA:10 a=E5ewRcf9vxcA:10 a=emO1SXQWCLwA:10 a=t1VQV7EkAAAA:8 a=FP58Ms26AAAA:8 a=43qFkJKtdgF_JTJVCj8A:9 a=ieFiBJ-CYhyvoVUU:21 a=ixPFKREYKoOMdfT2:21 a=QEXdDO2ut3YA:10 a=mt_iAf2ko0gA:10 a=IoeQSOh0AAAA:8 a=j9DsRBbtpZGcZKfl-OYA:9 a=FKAWSqKIilljA9yS:21 a=2hRoHtr57HszsInw:21 a=xC4l_JduujifS-EM:21 Received: from [74.125.82.180] (port=36901 helo=mail-we0-f180.google.com) by just26.justhost.com with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.82) (envelope-from ) id 1YW6n3-0002iQ-2h for bitcoin-development@lists.sourceforge.net; Thu, 12 Mar 2015 11:20:57 -0600 Received: by wesx3 with SMTP id x3so17952573wes.4 for ; Thu, 12 Mar 2015 10:20:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.120.230 with SMTP id lf6mr88184241wjb.78.1426180853503; Thu, 12 Mar 2015 10:20:53 -0700 (PDT) Received: by 10.28.24.145 with HTTP; Thu, 12 Mar 2015 10:20:53 -0700 (PDT) In-Reply-To: References: <54F32EED.6040103@electrum.org> <550057FD.6030402@electrum.org> Date: Thu, 12 Mar 2015 17:20:53 +0000 Message-ID: From: Gary Rowe To: Bitcoin Development Content-Type: multipart/alternative; boundary=089e0115fe24289e0105111a9bf0 X-Identified-User: {3760:just26.justhost.com:bitcoinc:bitcoin-solutions.co.uk} {sentby:smtp auth 74.125.82.180 authed with gary.rowe@bitcoin-solutions.co.uk} 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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [67.222.38.55 listed in list.dnswl.org] 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1YW7D0-00045W-HL Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged 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, 12 Mar 2015 17:47:48 -0000 --089e0115fe24289e0105111a9bf0 Content-Type: text/plain; charset=UTF-8 When Jim and I were selecting which combination of HD wallet structures to support we noted the following: * BIP39 is a good standard list to select from that mandates words that do not look similar to each other, a certain spelling (no English US/UK confusion) and possible foreign language variants provided by experts later * BIP32 (m/0h/0/0) and BIP44 (m/44h/0h/0h/0/0) allow for maximum compatibility with other wallets * including a date in the "wallet words" themselves is open to spoofing since the generator cannot be sure the date is correct (local time drift, provided externally by untrusted third party etc) * a timestamp as optional external metadata is useful to reduce sync times in SPV * our experience verified that users will very often enter a timestamp incorrectly (locale, fat fingers, bad memory etc) so we opted for "number of days elapsed since Bitcoin genesis block with a modulo 97 checksum appended" (e.g. 1850/07) to mitigate this * if a user has no timestamp then blank is the only alternative (no guessing) which is interpreted as "earliest possible BIP32 date" * if restoring the user has to select where the "wallet words" came from (e.g. MultiBit HD, Trezor, Mycelium etc) Users will naturally assume that they can type their "wallet words" (a more mainstream-friendly term than "seed phrase") into any wallet and with a bit of fiddling about get their bitcoins back. As wallet developers it is within our capability to make that happen and I think we're quite close already. On 12 March 2015 at 16:47, Mike Hearn wrote: > b) "Creation date" is just a short-term hack. >> > > I agree, but we need things to be easy in the short term as well as the > long term :) > > The long term solution is clearly to have the 12 word seed be an > encryption key for a wallet backup with all associated metadata. We're > heading in that direction one step at a time. Unfortunately it will take > time for wallets to start working this way, and all the pieces to fall into > place. Restoring from the block chain will be a semi regular operation for > users until then. > > WRT version number I have no real strong feelings about this. But > representing short pieces of binary data as words is so convenient, it > seems likely that it could be similar to addresses: people find other uses > for this mechanism beyond just storing a raw private key. Bitcoin addresses > have versions and that's proven to be useful several times, even though in > theory an address is "just" a hash of a pubkey. > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- Bitcoin Solutions Ltd provides bespoke software and consultancy. Find us at bitcoin-solutions.co.uk. --089e0115fe24289e0105111a9bf0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When Jim and I were selectin= g which combination of HD wallet structures to support we noted the followi= ng:

* BIP39 is a good standard list to select from that mandates words that=20 do not look similar to each other, a certain spelling (no English US/UK=20 confusion) and possible foreign language variants provided by experts=20 later
* BIP32 (m/0h/0/0) and BIP44 (m/44h/0h/0h/0/0) allow fo= r maximum compatibility with other wallets
* including a date in the "wallet words" themselves is open to spo= ofing=20 since the generator cannot be sure the date is correct (local time=20 drift, provided externally by untrusted third party etc)
* a = timestamp as optional external metadata is useful to reduce sync times in S= PV
* our experience verified that users will very often enter a timestamp=20 incorrectly (locale, fat fingers, bad memory etc) so we opted for=20 "number of days elapsed since Bitcoin genesis block with a modulo 97= =20 checksum appended" (e.g. 1850/07) to mitigate this
* if a use= r=20 has no timestamp then blank is the only alternative (no guessing) which=20 is interpreted as "earliest possible BIP32 date"
* if re= storing the user has to select where the "wallet words" came from= (e.g. MultiBit HD, Trezor, Mycelium etc)

Users will naturally assume that they can type their "wallet words" (a= more=20 mainstream-friendly term than "seed phrase") into any wallet and = with a=20 bit of fiddling about get their bitcoins back. As wallet developers it=20 is within our capability to make that happen and I think we're quite=20 close already.

On 12 March 2015 at 16:47, Mike Hearn <mike@plan99.net> wro= te:
b) "Creation date" is just a short-term hack.
<= /div>

I agree, but we ne= ed things to be easy in the short term as well as the long term :)=C2=A0

The long term solution is clearly to have the 12 wor= d seed be an encryption key for a wallet backup with all associated metadat= a. We're heading in that direction one step at a time. Unfortunately it= will take time for wallets to start working this way, and all the pieces t= o fall into place. Restoring from the block chain will be a semi regular op= eration for users until then.

WRT version number I= have no real strong feelings about this. But representing short pieces of = binary data as words is so convenient, it seems likely that it could be sim= ilar to addresses: people find other uses for this mechanism beyond just st= oring a raw private key. Bitcoin addresses have versions and that's pro= ven to be useful several times, even though in theory an address is "j= ust" a hash of a pubkey.

-----------------------------------------------------------------------= -------
Dive into the World of Parallel Programming The Go Parallel Website, sponso= red
by Intel and developed in partnership with Slashdot Media, is your hub for = all
things parallel software development, from weekly thought leadership blogs = to
news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/
_________________________= ______________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment




--
Bitcoin Solutions Ltd provides bespoke so= ftware and consultancy. Find us at bitcoin-solutions.co.uk.
--089e0115fe24289e0105111a9bf0--