diff options
| author | Mike Hearn <mike@plan99.net> | 2014-03-27 10:42:19 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-03-27 09:42:26 +0000 |
| commit | 1097c5d0f7b888d6c547b3d4d148fe0b84219c87 (patch) | |
| tree | 3a634da3c111fa3cadb7b6e1c5c95809dfa5250a | |
| parent | 21817f1e3c07137cdb6742a7b8329388125e1172 (diff) | |
| download | pi-bitcoindev-1097c5d0f7b888d6c547b3d4d148fe0b84219c87.tar.gz pi-bitcoindev-1097c5d0f7b888d6c547b3d4d148fe0b84219c87.zip | |
Re: [Bitcoin-development] New BIP32 structure
| -rw-r--r-- | 08/e8bbdb1f6d851663da7850cc48c941d91d756b | 299 |
1 files changed, 299 insertions, 0 deletions
diff --git a/08/e8bbdb1f6d851663da7850cc48c941d91d756b b/08/e8bbdb1f6d851663da7850cc48c941d91d756b new file mode 100644 index 000000000..be0254403 --- /dev/null +++ b/08/e8bbdb1f6d851663da7850cc48c941d91d756b @@ -0,0 +1,299 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <mh.in.england@gmail.com>) id 1WT6pO-0005Bf-V1 + for bitcoin-development@lists.sourceforge.net; + Thu, 27 Mar 2014 09:42:26 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.214.181 as permitted sender) + client-ip=209.85.214.181; envelope-from=mh.in.england@gmail.com; + helo=mail-ob0-f181.google.com; +Received: from mail-ob0-f181.google.com ([209.85.214.181]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1WT6pN-0005d9-Go + for bitcoin-development@lists.sourceforge.net; + Thu, 27 Mar 2014 09:42:26 +0000 +Received: by mail-ob0-f181.google.com with SMTP id wp4so3945540obc.40 + for <bitcoin-development@lists.sourceforge.net>; + Thu, 27 Mar 2014 02:42:20 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.60.97.193 with SMTP id ec1mr658079oeb.20.1395913340134; Thu, + 27 Mar 2014 02:42:20 -0700 (PDT) +Sender: mh.in.england@gmail.com +Received: by 10.76.71.231 with HTTP; Thu, 27 Mar 2014 02:42:19 -0700 (PDT) +In-Reply-To: <F2C8C044-EF92-4CCE-9235-28CA7FCE3526@bitsofproof.com> +References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com> + <F2C8C044-EF92-4CCE-9235-28CA7FCE3526@bitsofproof.com> +Date: Thu, 27 Mar 2014 10:42:19 +0100 +X-Google-Sender-Auth: A-bxqYGvsFkFGIuERUb7Uhrizkc +Message-ID: <CANEZrP0t6E5tKk_jcApwa+o4-qBg9uyRnePGarZXeLDxcKS+Rg@mail.gmail.com> +From: Mike Hearn <mike@plan99.net> +To: Tamas Blummer <tamas@bitsofproof.com> +Content-Type: multipart/alternative; boundary=089e0112c4bcc6ac0f04f59366da +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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (mh.in.england[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1WT6pN-0005d9-Go +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] New BIP32 structure +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Thu, 27 Mar 2014 09:42:27 -0000 + +--089e0112c4bcc6ac0f04f59366da +Content-Type: text/plain; charset=UTF-8 + +At this point I'm not sure how much further work people want to do on this: +I got the impression that Trezor will ship soon, and Thomas V seemed +satisfied too. I'm not sure we can get all wallets to be fully +interoperable given the flexibility inherent in BIP32 and people's +differing use cases. + +Andreas: good point but I really hope nobody ever deletes a seed after all +this work we put in to make backups so easy! I'm not sure we can really +stop it anyway: not unless we make the seed a full blown data structure +with hints to other apps that they should refuse to load it. And it's a bit +late for that now. + + + +On Thu, Mar 27, 2014 at 8:09 AM, Tamas Blummer <tamas@bitsofproof.com>wrote: + +> We had a similar meeting with Andreas Schildbach (Android Bitcoin Wallet), +> Jan Moller, Andreas Petersson (Mycelium), Thomas V (Electrum), Tamas +> Blummer, Tamas Bartfai (Bits of Proof) +> at the Inside Bitcoin Conference in Berlin. +> +> I remember that there were different opinions on how to use a hierarchy +> and it did seem to me they could eventually be "standardized" for the +> retail customer but definitelly not for corporate use, +> where hierarchy will certainly map to organisational hierarchy or cost +> centres. +> +> A notable suggestion was to instead of building a directory of magic +> numbers (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word +> "Bitcoin", "Litecoin", "Dogecoin", so collosion is unlikely and +> cetral directory is not needed. +> +> Regards, +> +> Tamas Blummer +> http://bitsofproof.com +> +> On 26.03.2014, at 21:49, Mike Hearn <mike@plan99.net> wrote: +> +> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure +> our BIP32 wallet structures would be compatible - and I discovered that +> only I was planning to use the default structure. +> +> Because I'm hopeful that we can get a lot of interoperability between +> wallets with regards to importing 12-words paper wallets, we brainstormed +> to find a structure acceptable to everyone and ended up with: +> +> /m/cointype/reserved'/account'/change/n +> +> The extra levels require some explanation: +> +> - cointype: This is zero for Bitcoin. This is here to support two +> things, one is supporting alt coins based off the same root seed. Right now +> nobody seemed very bothered about alt coins but sometimes feature requests +> do come in for this. Arguably there is no need and alt coins could just use +> the same keys as Bitcoin, but it may help avoid confusion if they don't. +> +> More usefully, cointype can distinguish between keys intended for +> things like multisig outputs, e.g. for watchdog services. This means if +> your wallet does not know about the extra protocol layers involved in this, +> it can still import the "raw" money and it will just ignore/not see the +> keys used in more complex transactions. +> +> - reserved is for "other stuff". I actually don't recall why we ended +> up with this. It may have been intended to split out multisig outputs etc +> from cointype. Marek, Thomas? +> +> - account is for keeping essentially wallets-within-a-wallet to avoid +> mixing of coins. If you want that. +> +> - change is 0 for receiving addresses, 1 for change addresses. +> +> - n is the actual key index +> +> For bitcoinj we're targeting a deliberately limited feature set for hdw v1 +> so I would just set the first three values all to zero and that is a +> perfectly fine way to be compatible. +> +> The goal here is that the same seed can be written down once, and meet all +> the users needs, whilst still allowing some drift between what wallets +> support. +> +> Pieter made the I think valid point that you can't really encode how keys +> are meant to be used into just an HDW hierarchy and normally you'd need +> some metadata as well. However, I feel interop between wallets is more +> important than arriving at the most perfect possible arrangement, which +> feels a little like bikeshedding, so I'm happy to just go with the flow on +> this one. +> +> +> ------------------------------------------------------------------------------ +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +> +> +> + +--089e0112c4bcc6ac0f04f59366da +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">At this point I'm not sure how much further work peopl= +e want to do on this: I got the impression that Trezor will ship soon, and = +Thomas V seemed satisfied too. I'm not sure we can get all wallets to b= +e fully interoperable given the flexibility inherent in BIP32 and people= +9;s differing use cases.<div> +<br></div><div>Andreas: good point but I really hope nobody ever deletes a = +seed after all this work we put in to make backups so easy! I'm not sur= +e we can really stop it anyway: not unless we make the seed a full blown da= +ta structure with hints to other apps that they should refuse to load it. A= +nd it's a bit late for that now.</div> +<div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail= +_quote">On Thu, Mar 27, 2014 at 8:09 AM, Tamas Blummer <span dir=3D"ltr">&l= +t;<a href=3D"mailto:tamas@bitsofproof.com" target=3D"_blank">tamas@bitsofpr= +oof.com</a>></span> wrote:<br> +<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= +x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word">We had a= + similar meeting with Andreas Schildbach (Android Bitcoin Wallet), Jan Moll= +er,=C2=A0Andreas=C2=A0=C2=A0Petersson (Mycelium), Thomas V (Electrum), Tama= +s Blummer, Tamas Bartfai (Bits of Proof)<div> +at the Inside Bitcoin Conference in Berlin.</div><div><br></div><div>I reme= +mber that there were different opinions on how to use a hierarchy and it di= +d seem to me they could eventually be "standardized" for the reta= +il customer but definitelly not for corporate use,</div> +<div>where hierarchy will certainly map to organisational hierarchy or cost= + centres.<br><div><br></div><div> +A notable suggestion was to instead of building a directory of magic number= +s (like 0 for Bitcoin, 1 for Litecoin etc) use a hash of the word "Bit= +coin", "Litecoin", "Dogecoin", so collosion is unl= +ikely and</div> +<div>cetral directory is not needed.</div><div><br></div><div><span style= +=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-w= +ebkit-auto;font-style:normal;display:inline!important;font-weight:normal;fl= +oat:none;line-height:normal;text-transform:none;font-size:medium;white-spac= +e:normal;font-family:Helvetica;word-spacing:0px">Regards,</span><br style= +=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-w= +ebkit-auto;font-style:normal;font-weight:normal;line-height:normal;text-tra= +nsform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-= +spacing:0px"> +<br style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;text= +-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal= +;text-transform:none;font-size:medium;white-space:normal;font-family:Helvet= +ica;word-spacing:0px"> +<span style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;te= +xt-align:-webkit-auto;font-style:normal;display:inline!important;font-weigh= +t:normal;float:none;line-height:normal;text-transform:none;font-size:medium= +;white-space:normal;font-family:Helvetica;word-spacing:0px">Tamas Blummer</= +span><br style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal= +;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:n= +ormal;text-transform:none;font-size:medium;white-space:normal;font-family:H= +elvetica;word-spacing:0px"> +<span style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal;te= +xt-align:-webkit-auto;font-style:normal;display:inline!important;font-weigh= +t:normal;float:none;line-height:normal;text-transform:none;font-size:medium= +;white-space:normal;font-family:Helvetica;word-spacing:0px"><a href=3D"http= +://bitsofproof.com" target=3D"_blank">http://bitsofproof.com</a></span> +</div> +<br><div><div><div class=3D"h5"><div>On 26.03.2014, at 21:49, Mike Hearn &l= +t;<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&= +gt; wrote:</div><br></div></div><blockquote type=3D"cite"><div><div class= +=3D"h5"> +<div dir=3D"ltr">Myself, Thomas V (Electrum) and Marek (Trezor) got togethe= +r to make sure our BIP32 wallet structures would be compatible - and I disc= +overed that only I was planning to use the default structure.<div><br></div= +> + +<div>Because I'm hopeful that we can get a lot of interoperability betw= +een wallets with regards to importing 12-words paper wallets, we brainstorm= +ed to find a structure acceptable to everyone and ended up with:</div> +<div> +<br></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">= +=C2=A0 /m/cointype/reserved'/account'</span><span style=3D"font-fam= +ily:arial,sans-serif;font-size:13px">/change/n</span><br></div><div><span s= +tyle=3D"font-family:arial,sans-serif;font-size:13px"><br> + +</span></div><div><span style=3D"font-family:arial,sans-serif;font-size:13p= +x">The extra levels require some explanation:</span></div><div><ul><li><fon= +t face=3D"arial, sans-serif">cointype: =C2=A0This is zero for Bitcoin. This= + is here to support two things, one is supporting alt coins based off the s= +ame root seed. Right now nobody seemed very bothered about alt coins but so= +metimes feature requests do come in for this. Arguably there is no need and= + alt coins could just use the same keys as Bitcoin, but it may help avoid c= +onfusion if they don't.<br> + +<br>More usefully, cointype can distinguish between keys intended for thing= +s like multisig outputs, e.g. for watchdog services. This means if your wal= +let does not know about the extra protocol layers involved in this, it can = +still import the "raw" money and it will just ignore/not see the = +keys used in more complex transactions.<br> + +<br></font></li><li><font face=3D"arial, sans-serif">reserved is for "= +other stuff". I actually don't recall why we ended up with this. I= +t may have been intended to split out multisig outputs etc from cointype. M= +arek, Thomas?<br> + +<br></font></li><li><font face=3D"arial, sans-serif">account is for keeping= + essentially wallets-within-a-wallet to avoid mixing of coins. If you want = +that.<br><br></font></li><li><font face=3D"arial, sans-serif">change is 0 f= +or receiving addresses, 1 for change addresses.<br> + +<br></font></li><li><font face=3D"arial, sans-serif">n is the actual key in= +dex</font></li></ul><div><font face=3D"arial, sans-serif">For bitcoinj we&#= +39;re targeting a deliberately limited feature set for hdw v1 so I would ju= +st set the first three values all to zero and that is a perfectly fine way = +to be compatible.</font></div> + +</div><div><font face=3D"arial, sans-serif"><br></font></div><div><font fac= +e=3D"arial, sans-serif">The goal here is that the same seed can be written = +down once, and meet all the users needs, whilst still allowing some drift b= +etween what wallets support.</font></div> + +<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a= +rial, sans-serif">Pieter made the I think valid point that you can't re= +ally encode how keys are meant to be used into just an HDW hierarchy and no= +rmally you'd need some metadata as well. However, I feel interop betwee= +n wallets is more important than arriving at the most perfect possible arra= +ngement, which feels a little like bikeshedding, so I'm happy to just g= +o with the flow on this one.</font></div> + +<div><font face=3D"arial, sans-serif"><br></font></div></div></div></div><d= +iv class=3D""> +---------------------------------------------------------------------------= +---<br>_______________________________________________<br>Bitcoin-developme= +nt mailing list<br><a href=3D"mailto:Bitcoin-development@lists.sourceforge.= +net" target=3D"_blank">Bitcoin-development@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de= +velopment</a><br></div></blockquote></div><br></div></div></blockquote></di= +v> +<br></div> + +--089e0112c4bcc6ac0f04f59366da-- + + |