diff options
| author | Allen Piscitello <allen.piscitello@gmail.com> | 2014-03-26 20:13:16 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-03-27 01:13:23 +0000 |
| commit | ca1b1322b4973baded5855d3b7c16c17a1ae41d5 (patch) | |
| tree | 25be402313b7bdb3cd1369a346ac0eb4d5aef36b | |
| parent | 03e76b141f13c81f5cd4b60718460770de3f4bf1 (diff) | |
| download | pi-bitcoindev-ca1b1322b4973baded5855d3b7c16c17a1ae41d5.tar.gz pi-bitcoindev-ca1b1322b4973baded5855d3b7c16c17a1ae41d5.zip | |
Re: [Bitcoin-development] New BIP32 structure
| -rw-r--r-- | 03/73edfd581ed28c6d38620358e67b5a774fe25a | 245 |
1 files changed, 245 insertions, 0 deletions
diff --git a/03/73edfd581ed28c6d38620358e67b5a774fe25a b/03/73edfd581ed28c6d38620358e67b5a774fe25a new file mode 100644 index 000000000..9d430935d --- /dev/null +++ b/03/73edfd581ed28c6d38620358e67b5a774fe25a @@ -0,0 +1,245 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <allen.piscitello@gmail.com>) id 1WSysl-0006a6-H3 + for bitcoin-development@lists.sourceforge.net; + Thu, 27 Mar 2014 01:13:23 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.160.172 as permitted sender) + client-ip=209.85.160.172; + envelope-from=allen.piscitello@gmail.com; + helo=mail-yk0-f172.google.com; +Received: from mail-yk0-f172.google.com ([209.85.160.172]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1WSysk-0006Dn-Bd + for bitcoin-development@lists.sourceforge.net; + Thu, 27 Mar 2014 01:13:23 +0000 +Received: by mail-yk0-f172.google.com with SMTP id 200so1619315ykr.31 + for <bitcoin-development@lists.sourceforge.net>; + Wed, 26 Mar 2014 18:13:16 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.236.54.198 with SMTP id i46mr54302213yhc.13.1395882796860; + Wed, 26 Mar 2014 18:13:16 -0700 (PDT) +Received: by 10.170.88.10 with HTTP; Wed, 26 Mar 2014 18:13:16 -0700 (PDT) +In-Reply-To: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com> +References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com> +Date: Wed, 26 Mar 2014 20:13:16 -0500 +Message-ID: <CAJfRnm7XCZ39t5E1DZvavgtgMPtPCc7RUDpLjgK73vtAEtxJ9w@mail.gmail.com> +From: Allen Piscitello <allen.piscitello@gmail.com> +To: Mike Hearn <mike@plan99.net> +Content-Type: multipart/alternative; boundary=bcaec50b4aae414aeb04f58c4a55 +X-Spam-Score: -0.6 (/) +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 + (allen.piscitello[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 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: 1WSysk-0006Dn-Bd +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 01:13:23 -0000 + +--bcaec50b4aae414aeb04f58c4a55 +Content-Type: text/plain; charset=ISO-8859-1 + +For every branch (say multiple accounts), how would a new wallet be able to +know how many sequence items to scan? It seems like not only do you need +to have standard rules for the hierarchy, but how the usage can be +detected. The other scanning seems pretty straightforward. For accounts, +it seems like you could have a situation where you want to initially set up +10 different accounts, but only account #10 gets any transactions. If a +new wallet was trying to scan with this seed, it would have to know to keep +scanning each account until it found the account. The user would have to +be responsible for knowing how many accounts there are, or some rules would +need to be in place to not allow creating accounts until earlier accounts +can be proven to have existed in the blockchain. Or I am missing something. + +-Allen + +On Wed, Mar 26, 2014 at 3:49 PM, 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 +> +> + +--bcaec50b4aae414aeb04f58c4a55 +Content-Type: text/html; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_extra">For every branch (say multiple = +accounts), how would a new wallet be able to know how many sequence items t= +o scan? =A0It seems like not only do you need to have standard rules for th= +e hierarchy, but how the usage can be detected. =A0The other scanning seems= + pretty straightforward. =A0For accounts, it seems like you could have a si= +tuation where you want to initially set up 10 different accounts, but only = +account #10 gets any transactions. =A0If a new wallet was trying to scan wi= +th this seed, it would have to know to keep scanning each account until it = +found the account. =A0The user would have to be responsible for knowing how= + many accounts there are, or some rules would need to be in place to not al= +low creating accounts until earlier accounts can be proven to have existed = +in the blockchain. =A0Or I am missing something.</div> +<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">-Allen</div= +><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Mar 26, = +2014 at 3:49 PM, Mike Hearn <span dir=3D"ltr"><<a href=3D"mailto:mike@pl= +an99.net" target=3D"_blank">mike@plan99.net</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 dir=3D"ltr">Myself, Thomas V (Electrum)= + and Marek (Trezor) got together to make sure our BIP32 wallet structures w= +ould be compatible - and I discovered that only I was planning to use the d= +efault 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">= +=A0 /m/cointype/reserved'/account'</span><span style=3D"font-family= +:arial,sans-serif;font-size:13px">/change/n</span><br></div><div><span styl= +e=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: =A0This 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 somet= +imes feature requests do come in for this. Arguably there is no need and al= +t coins could just use the same keys as Bitcoin, but it may help avoid conf= +usion 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> +<br>-----------------------------------------------------------------------= +-------<br> +<br>_______________________________________________<br> +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla= +nk">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> +<br></blockquote></div><br></div></div> + +--bcaec50b4aae414aeb04f58c4a55-- + + |