diff options
| author | slush <slush@centrum.cz> | 2014-04-08 17:41:06 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-04-08 15:41:44 +0000 |
| commit | a322fd99ef32a2f19fd749df32c42b9212231128 (patch) | |
| tree | af70ffa73ba2f18e78fd7b5c9f44686cc4eb2bff | |
| parent | 65167c2e52f1eb6dde4e3d047d314be6f9ba51b3 (diff) | |
| download | pi-bitcoindev-a322fd99ef32a2f19fd749df32c42b9212231128.tar.gz pi-bitcoindev-a322fd99ef32a2f19fd749df32c42b9212231128.zip | |
Re: [Bitcoin-development] New BIP32 structure
| -rw-r--r-- | 2e/ed11018df3af965efb6f9db6ddd8f7ae422378 | 202 |
1 files changed, 202 insertions, 0 deletions
diff --git a/2e/ed11018df3af965efb6f9db6ddd8f7ae422378 b/2e/ed11018df3af965efb6f9db6ddd8f7ae422378 new file mode 100644 index 000000000..2ad2e9a96 --- /dev/null +++ b/2e/ed11018df3af965efb6f9db6ddd8f7ae422378 @@ -0,0 +1,202 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <marek@palatinus.cz>) id 1WXY9g-0007R4-AZ + for bitcoin-development@lists.sourceforge.net; + Tue, 08 Apr 2014 15:41:44 +0000 +X-ACL-Warn: +Received: from mail-ve0-f171.google.com ([209.85.128.171]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1WXY9e-0000Ti-L2 + for bitcoin-development@lists.sourceforge.net; + Tue, 08 Apr 2014 15:41:44 +0000 +Received: by mail-ve0-f171.google.com with SMTP id jy13so955285veb.30 + for <bitcoin-development@lists.sourceforge.net>; + Tue, 08 Apr 2014 08:41:37 -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=Zavy6+2L0X6DQ642w5+JkrrOJIEB80Rza8y1EqaS6rI=; + b=G9FGsVvtS2s2srGuvCAaNWhv/iRW53PuBAuPAHOG3XTrFh8WwMXF+wEhHpG+Ba8Pqi + VBRLSMXAbWxQ45Rn7p2Ku1wQDo+kcwImoMASRWO8I8dIQSpdlE8jl9TX3I1zKdFwpBXX + qFDpdOc9yEA5lB+RODpvIveg1aO1yhL6WFUd1PLaBAPdyf8DJ4uaucYV523T5Qm9YTCz + m+OMNFjg7in8aZ+o4cmSVyS4md92Jk5f+frpBRt73GgwXof1PNX9LLsRMp3D2OC2V4UY + bry/nKiqig2GEJFikNVa7+yyN1geLv0lsz+JkWGf2aopgzoZlPxaUEutNnoTO2ZwHRy/ + Pllg== +X-Gm-Message-State: ALoCoQnrjzFvQjrDlk75rOjWya/4eAYzLL9n3YVWFX2vpS0YGK0TOCcVYZxMzO24FeyZOo5HyasK +X-Received: by 10.220.163.3 with SMTP id y3mr3802278vcx.7.1396971697048; Tue, + 08 Apr 2014 08:41:37 -0700 (PDT) +MIME-Version: 1.0 +Sender: marek@palatinus.cz +Received: by 10.58.234.100 with HTTP; Tue, 8 Apr 2014 08:41:06 -0700 (PDT) +In-Reply-To: <CAPg+sBguSQ8dk1xXKinX+ez4BmdM3sz-huruuhD6NCTsp0kRBQ@mail.gmail.com> +References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com> + <F2C8C044-EF92-4CCE-9235-28CA7FCE3526@bitsofproof.com> + <CAJHLa0PPAsBLgsy0vgPpUp=UzeR_fWUEzFb5+xtmODEk4MGPVQ@mail.gmail.com> + <CAJfRnm7V6fgcj=TMfa2ZTYWOKtE5aoUT1xnVtKUSyriB=6cagQ@mail.gmail.com> + <CAPg+sBjwf1TcK1CGKVKFzYbV-78j8t-pav7=PEgG7Yqi6-yE7A@mail.gmail.com> + <53344FF8.7030204@gk2.sk> + <CAPg+sBhbx5vy_hewAkFPaiXHzSMNH0qLhEYGjPmQMjR5StP-tw@mail.gmail.com> + <CAJna-Hi0JnrF2_rUx0rGkdnsuCoaD01e3Gobpn+QqbL=D1Uivg@mail.gmail.com> + <CAJna-HirtsGLfAhfUf9dAYEGWo6g=o=eAU187c2pdW8vDFGkPw@mail.gmail.com> + <CAPg+sBg8wDH9yTUoyhRbuzVtbD8hGxya8tOnV4pMToHy3gLrzw@mail.gmail.com> + <CAJna-HiN_1KQmpDJFFX6mGvM63RC0xwXxvfuorpihnzYf4=fsQ@mail.gmail.com> + <CAJna-HgfpyHX_0AHwt1Hkj0qhD_-xOcpxsZ9KXq=7CPgwse1hA@mail.gmail.com> + <CAPg+sBguSQ8dk1xXKinX+ez4BmdM3sz-huruuhD6NCTsp0kRBQ@mail.gmail.com> +From: slush <slush@centrum.cz> +Date: Tue, 8 Apr 2014 17:41:06 +0200 +X-Google-Sender-Auth: 8IMv6LNUTGoYvXABfYyzRm6HRIc +Message-ID: <CAJna-Hib6umrkG0pAQzQvsyBMxOU6P675TURsVuWSU_ci9+X_A@mail.gmail.com> +To: Pieter Wuille <pieter.wuille@gmail.com> +Content-Type: multipart/alternative; boundary=001a1133da66c3a21604f689d1b8 +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) + 1.0 HTML_MESSAGE BODY: HTML included in message +X-Headers-End: 1WXY9e-0000Ti-L2 +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: Tue, 08 Apr 2014 15:41:44 -0000 + +--001a1133da66c3a21604f689d1b8 +Content-Type: text/plain; charset=ISO-8859-1 + +On Tue, Apr 8, 2014 at 3:53 PM, Pieter Wuille <pieter.wuille@gmail.com>wrote: + +> I see the cause of our disagreement now. +> +> You actually want to share a single BIP32 tree across different +> currency types, but do it in a way that guarantees that they never use +> the same keys. +> +> I would have expected that different chains would use independent +> chains, and have serializations encode which chain they belong to. +> +> Let me offer an alternative suggestion, which is compatible with the +> original default BIP32 structure: +> * You can use one seed across different chains, but the master nodes +> are separate. +> * To derive the master node from the seed, the key string "Bitcoin +> seed" is replaced by something chain-specific. +> + +I've discussed the solution of "Litecoin seed" in BIP32 HMAC with Litecoin +devs already, and after long discussion we've concluded that it is +generally bad idea. + +When changing "Bitcoin seed" constant to something different, same +*entropy* will produce different *master node*. That's actually the +opposite what's requested, because xprv serialization format stores *node*, +not *entropy*. By changing HMAC constant, you still won't be able to store +one node and derive wallets for multiple coins at same time. + + + +> * Every encoded node (including master nodes) has a chain-specific +> serialization magic. +> +This is in practice almost the same as your suggestion, except that +> the m/cointype' in m/cointype'/account'/change/n is replaced by +> different masters. The only disadvantage I see is that you do not have +> a way to encode the "super master" that is the parent of all +> chain-specific masters. You can - and with the same security +> properties - encode the seed, though. +> +> +Actually I don't understand why there's such disagreement about "cointype" +level here, what it breaks? I see it as the cleanest solution so far. It is +forward and backward compatible, does need any special extension to bip32 +(to be strict, bip32 says "Bitcoin seed", so client using "Litecoin seed" +cannot be "bip32 compatible"). + +Of course, the problem of "cointype" can be solved in zillion ways, but +still using cointype in bip32 path seem to be the most elegant way so far, +because it fullfill all requirements for single backup, for separating +pubkeys and for handling all coins by one master... + +Marek + +--001a1133da66c3a21604f689d1b8 +Content-Type: text/html; charset=ISO-8859-1 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div><br></div><div class=3D"gmail_extra"><div class=3D"gm= +ail_quote">On Tue, Apr 8, 2014 at 3:53 PM, Pieter Wuille <span dir=3D"ltr">= +<<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wui= +lle@gmail.com</a>></span> wrote:<br> + +<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= +left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p= +adding-left:1ex">I see the cause of our disagreement now.<br> +<br> +You actually want to share a single BIP32 tree across different<br> +currency types, but do it in a way that guarantees that they never use<br> +the same keys.<br> +<br> +I would have expected that different chains would use independent<br> +chains, and have serializations encode which chain they belong to.<br> +<br> +Let me offer an alternative suggestion, which is compatible with the<br> +original default BIP32 structure:<br> +* You can use one seed across different chains, but the master nodes<br> +are separate.<br> +* To derive the master node from the seed, the key string "Bitcoin<br> +seed" is replaced by something chain-specific.<br></blockquote><div><b= +r></div>I've discussed the solution of "Litecoin seed" in BIP= +32 HMAC with Litecoin devs already, and after long discussion we've con= +cluded that it is generally bad idea.<div> + +<br></div><div>When changing "Bitcoin seed" constant to something= + different, same *entropy* will produce different *master node*. That's= + actually the opposite what's requested, because xprv serialization for= +mat stores *node*, not *entropy*. By changing HMAC constant, you still won&= +#39;t be able to store one node and derive wallets for multiple coins at sa= +me time.</div> + +<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar= +gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2= +04);border-left-style:solid;padding-left:1ex"> +* Every encoded node (including master nodes) has a chain-specific<br> +serialization magic.<br></blockquote><blockquote class=3D"gmail_quote" styl= +e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2= +04,204,204);border-left-style:solid;padding-left:1ex"> +This is in practice almost the same as your suggestion, except that<br> +the m/cointype' in m/cointype'/account'/change/n is replaced by= +<br> +different masters. The only disadvantage I see is that you do not have<br> +a way to encode the "super master" that is the parent of all<br> +chain-specific masters. You can - and with the same security<br> +properties - encode the seed, though.<br> +<span class=3D""><font color=3D"#888888"><br></font></span></blockquote><di= +v><br></div><div>Actually I don't understand why there's such disag= +reement about "cointype" level here, what it breaks? I see it as = +the cleanest solution so far. It is forward and backward compatible, does n= +eed any special extension to bip32 (to be strict, bip32 says "Bitcoin = +seed", so client using "Litecoin seed" cannot be "bip32= + compatible").</div> + +<div><br></div><div>Of course, the problem of "cointype" can be s= +olved in zillion ways, but still using cointype in bip32 path seem to be th= +e most elegant way so far, because it fullfill all requirements for single = +backup, for separating pubkeys and for handling all coins by one master...<= +/div> + +<div><br></div><div>Marek</div><div><br></div></div></div></div> + +--001a1133da66c3a21604f689d1b8-- + + |