diff options
| author | Clark Moody <clark@clarkmoody.com> | 2018-05-04 00:09:38 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-05-04 00:10:07 +0000 |
| commit | a1f9c40def38a7275157ea8c0d37aacfc66a7121 (patch) | |
| tree | 2739601084f099cfda5dbfa7d308751c424f6f9d | |
| parent | d658b98edf51f6c4bf0c48a8b4c6d18e3081265f (diff) | |
| download | pi-bitcoindev-a1f9c40def38a7275157ea8c0d37aacfc66a7121.tar.gz pi-bitcoindev-a1f9c40def38a7275157ea8c0d37aacfc66a7121.zip | |
Re: [bitcoin-dev] Multi-signature and multi-coin HD wallet in one BIP32 derivation path (new BIP)
| -rw-r--r-- | 00/da8f6cd14fea71b3b2938db81ad3d892af803c | 432 |
1 files changed, 432 insertions, 0 deletions
diff --git a/00/da8f6cd14fea71b3b2938db81ad3d892af803c b/00/da8f6cd14fea71b3b2938db81ad3d892af803c new file mode 100644 index 000000000..93cd62402 --- /dev/null +++ b/00/da8f6cd14fea71b3b2938db81ad3d892af803c @@ -0,0 +1,432 @@ +Return-Path: <clarkmoody@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id F38337A8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 4 May 2018 00:10:07 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com + [209.85.215.41]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 55E88F8 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 4 May 2018 00:10:06 +0000 (UTC) +Received: by mail-lf0-f41.google.com with SMTP id w8-v6so28519589lfe.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 03 May 2018 17:10:06 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=clarkmoody-com.20150623.gappssmtp.com; s=20150623; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=PGLP8Ggve77an7B+/3UJs8G3FM9O47KEWUjVdatcjPQ=; + b=eYAyMAH+GQJgo0UBwgRCvyN1B07MKzcgrwVw22yALSkBPiGHrUkgyH4ipUOgmkPAD7 + Ix2HazPIowwMzVNEyaTJjscWceTZOhBUe6t2+/ATfGJT7DA5MiHHzl2k7g3zGXB7/egW + J/zBLbV5ZQx7HHEmffJ1RL9wjhqlu58W1KggwVu4PakoxjmN3lEkwY6uKOmevppxyaqZ + D1uA8rjCnglx2KGFb7TITVRXY/EsBtXTtlXeUUegGlW6izcyhvglMJgYa2t3RDltLSUO + bUc7YemtaXNfg4V1pGBdYbvLN2vzT26i94o/vr9o6PsMM5cKVOJ9bHh/Y3YThffbZRxQ + +emw== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=PGLP8Ggve77an7B+/3UJs8G3FM9O47KEWUjVdatcjPQ=; + b=LUIqCqNrA+dwZ4lWMBdYg3i0vvJBbMUjiLhRJh3YPVfRYxn5NTaVVwlebl//Rg2g5Z + 0gszaxv09rpzqRBjgnUy/L9CMBjmFqAB6E8U1VY8K91HvVQdv6YX7yN16KiFX2ziynyY + LiCDYue8HnSmhb0ZM0qBxMfR+58zLWPMkpSMBYwqn/jjMSEQYCfcJ6dX4QDufLiQFjrw + TnNEMpcbBh9y71/jX8mFwmxePHM0v/YKpdpc2iOd6NeF3tQuUOxEK4THGJldbTftUgwf + YY/w4coKPXZGWDftKzqM8cVmIj5gGSOdSNg7uShe0M20PlULoHUycZMx/VK1cB5FGG1Z + AUgQ== +X-Gm-Message-State: ALQs6tAj5SRuUEzmyxGMqYrEWXdT8QQgqkWNJTjjEJ5r+xQQdbEeSBzS + fTp53Kymb3FMph258dyXbWsGcs7YeiYIqrAyjtQ= +X-Google-Smtp-Source: AB8JxZrAQASlLkHUBlfFJInEQv09IbAQVK7+VQs8jRXlphf8Fzcd0eliZ+m+Ccpwmsb6aME+vZquYF876g8aB8SlJF0= +X-Received: by 2002:a2e:2c01:: with SMTP id + s1-v6mr3466626ljs.120.1525392604551; + Thu, 03 May 2018 17:10:04 -0700 (PDT) +MIME-Version: 1.0 +References: <HE1PR09MB026619CDFFBA6D995600EF18988F0@HE1PR09MB0266.eurprd09.prod.outlook.com> + <CAHGSxGt649Ok=jp0STnHkYvEhWSOTwMfh0oB+7jqY6MAmr4TKQ@mail.gmail.com> + <HE1PR09MB0266CE6FDFE63FD368AD8E20988E0@HE1PR09MB0266.eurprd09.prod.outlook.com> +In-Reply-To: <HE1PR09MB0266CE6FDFE63FD368AD8E20988E0@HE1PR09MB0266.eurprd09.prod.outlook.com> +From: Clark Moody <clark@clarkmoody.com> +Date: Fri, 04 May 2018 00:09:38 +0000 +Message-ID: <CAHGSxGsyQ7=NdE6x7c+cfJY=3tVCNpTuy971xvqFT7SQ70PrAQ@mail.gmail.com> +To: Paul Brown <paul@345.systems> +Content-Type: multipart/alternative; boundary="000000000000565e2e056b562464" +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, + RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Fri, 04 May 2018 11:37:07 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Multi-signature and multi-coin HD wallet in one + BIP32 derivation path (new BIP) +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Fri, 04 May 2018 00:10:08 -0000 + +--000000000000565e2e056b562464 +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Paul, + +The current BIP-49 / 84 use the purpose field of the derivation path to spe= +cify +the address format. + +=E2=80=8BI think sticking with the one-BIP-one-format method works. Otherwi= +se, you +would need to modify this proposed BIP each time a new format comes along. +In that case, existing wallets that claim BIP-XXXX compliance will be +incomplete. + + +-Clark + +On Thu, Apr 26, 2018 at 9:05 AM, Paul Brown <paul@345.systems> wrote: + +> Hi +> +> I realised after I sent my previous response that the encoding was wrong +> and that my smiley face at the end of the BIP number comment got turned +> into a ? and the tongue in cheek context was lost :-( +> +> Anyway, back onto subject. I've been thinking some more on the SLIP-0032 +> adoption in this proposal and specifically the address format to use when +> generating addresses. +> +> My proposal states bech32 serialized addresses (P2WPKH or P2WSH), however= +, +> I wonder whether there is some merit in extending the derivation path wit= +h +> an additional level below coin type to represent the address format, with +> the value determined by the context of the coin type value in the +> derivation path (0x00 for P2WPKH bech32, 0x01 for P2PKH base58 if coin ty= +pe +> is Bitcoin, 0x00 for Ethereum account format if coin type is Ether, etc). +> A separate spec similar to SLIP-0044 could be created that defines the li= +st +> of address formats and the derivation path values. +> +> When importing root master seeds or distributing the xpub's for each +> cosigner to each party the discovery process in the proposal would need +> extending to try each address format in turn to determine whether there i= +s +> a 'hit' when checking balances. It does mean that the import process is +> slower however the additional flexibility of supporting multiple address +> formats possibly outweighs this. I'm just thinking that having a rule to +> follow during discovery, particularly where non-Bitcoin coins are +> concerned, is more explicit than leaving it open to the wallet implemente= +r +> to figure out (for altcoins, what address format to use?). +> +> It also means that future address formats are supported as they are simpl= +y +> added to the new spec list for the coin type (can be done by anyone, +> similar to the way SLIP-0044 works now) - it doesn't require a new BIP to +> support. For example, if address format was a derivation level in BIP44, +> would BIP49 and BIP84 be needed? +> +> I'm somewhat musing out loud here, but I like the idea of being able to +> mostly self-discover as much as possible and reducing or eliminating the +> need for proprietary metadata attached to the wallet. +> +> Cheers +> Paul +> +> From: clarkmoody@gmail.com <clarkmoody@gmail.com> On Behalf Of Clark Mood= +y +> Sent: 25 April 2018 15:36 +> To: Paul Brown <paul@345.systems>; Bitcoin Protocol Discussion < +> bitcoin-dev@lists.linuxfoundation.org> +> Subject: Re: [bitcoin-dev] Multi-signature and multi-coin HD wallet in on= +e +> BIP32 derivation path (new BIP) +> +> Thanks for the proposal, Paul. +> +> > - What address format is expected when discovering balances and creatin= +g +> transactions? +> +> Your solution does not solve your first bullet point, since the xpub +> encoding looks no different than any other xpub (BIP 44, 45, 49, etc). At +> the least, you should propose new version bytes to change the "xpub" in t= +he +> encoding to some other string. +> +> Alternatively, I would suggest that you use the xpub serialization format +> described in SLIP-0032 ( +> https://github.com/satoshilabs/slips/blob/master/slip-0032.md). It +> includes the derivation path within the xpub itself and uses Bech32 for +> encoding. +> +> Given a normal xpub with no additional information, a wallet must scan th= +e +> address space for the various formats. SLIP-0032 solves this bootstrappin= +g +> problem and avoids the UX nightmare of users being required to know to +> which BIP number the xpub conforms. +> +> Also, @luke-jr will give you a hard time to self-assigning a BIP number ;= +-) +> +> Thanks +> +> +> +> +> -Clark +> +> On Wed, Apr 25, 2018 at 4:35 AM, Paul Brown via bitcoin-dev <mailto: +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> Hi +> +> I have written a new BIP describing a BIP32 derivation path that supports +> a single or multi-signature and multi-coin wallet from a single master +> seed. It combines BIP44 and BIP45 and adds in a self-describing structur= +e +> in the derivation path for multiple multi-sig combinations within the +> single wallet along with an extended public key export file format for +> public key distribution between parties. I can particularly see this bei= +ng +> useful for multiple Lightning Network 2of2 accounts for different payment +> channels. +> +> The BIP can be found here: +> https://github.com/gluexchange/bip/blob/master/bip-0046.mediawiki +> +> I appreciate that this might be re-hashing old ground as BIP44 in +> particular has been widely adopted, however, BIP44 does leave itself open +> to a lot of interpretation from a wallet portability perspective such as: +> +> - What address format is expected when discovering balances and creating +> transactions? +> - Does the master seed represent a single-sig or multi-sig wallet? +> - If multi-sig, how many cosigners and what are their extended public key= +s +> (so that the wallet can generate the correctly formatted redeem script wi= +th +> public keys in the right order)? +> - If multi-sig, how do you prevent collisions on the same address index +> (in a wallet that is occasionally connected)? +> +> BIP45 solves the collision that occurs when the individual parties in a +> multi-sig group each give out a new address from a wallet, where the wall= +et +> hasn=E2=80=99t been able to sync to mark the address as =E2=80=98used=E2= +=80=99 (this could happen +> if they gave out addresses independently at the same time). It uses a +> cosigner index in the derivation path so that each party has their own pa= +th +> to their addresses. However, BIP45 drops the multi-coin support that BIP= +44 +> has. +> +> This is a useful discussion on the problems of a collision and the merits +> of separating cosigners in the derivation path: +> https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/ms= +g05188.html +> +> For the purposes of the BIP text (and the example paths used to generate +> keys) I=E2=80=99ve temporarily assigned it the number 46. It looks like = +that is +> available and seemed somewhat appropriate given that it builds on the goo= +d +> work of BIP44 and BIP45. +> +> Paul Brown +> +> +> +> _______________________________________________ +> bitcoin-dev mailing list +> mailto:bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +> + +--000000000000565e2e056b562464 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:tahoma,s= +ans-serif;font-size:small;color:#000000">Paul,</div><div class=3D"gmail_def= +ault" style=3D"font-family:tahoma,sans-serif;font-size:small;color:#000000"= +><br></div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-se= +rif;font-size:small;color:#000000">The current BIP-49 / 84 use the purpose = +field of the derivation path to=C2=A0<span style=3D"color:rgb(0,0,0);font-f= +amily:tahoma,sans-serif;font-size:small;font-style:normal;font-variant-liga= +tures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal= +;text-align:start;text-indent:0px;text-transform:none;white-space:normal;wo= +rd-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:init= +ial;text-decoration-color:initial;float:none;display:inline">specify the ad= +dress format</span>.</div><div class=3D"gmail_extra"><br clear=3D"all"><div= +><div class=3D"m_8866112210612112144gmail_signature" data-smartmail=3D"gmai= +l_signature"><div><div class=3D"gmail_default" style=3D"font-family:tahoma,= +sans-serif;font-size:small;color:rgb(0,0,0)">=E2=80=8BI think sticking with= + the one-BIP-one-format method works. Otherwise, you would need to modify t= +his proposed BIP each time a new format comes along. In that case, existing= + wallets that claim BIP-XXXX compliance will be incomplete.</div><br></div>= +<div><br></div><div>-Clark</div><div></div></div></div> +<br><div class=3D"gmail_quote">On Thu, Apr 26, 2018 at 9:05 AM, Paul Brown = +<span dir=3D"ltr"><<a href=3D"mailto:paul@345.systems" target=3D"_blank"= +>paul@345.systems</a>></span> wrote:<br><blockquote class=3D"gmail_quote= +" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">H= +i<br> +<br> +I realised after I sent my previous response that the encoding was wrong an= +d that my smiley face at the end of the BIP number comment got turned into = +a ? and the tongue in cheek context was lost :-(<br> +<br> +Anyway, back onto subject.=C2=A0 I've been thinking some more on the SL= +IP-0032 adoption in this proposal and specifically the address format to us= +e when generating addresses.<br> +<br> +My proposal states bech32 serialized addresses (P2WPKH or P2WSH), however, = +I wonder whether there is some merit in extending the derivation path with = +an additional level below coin type to represent the address format, with t= +he value determined by the context of the coin type value in the derivation= + path (0x00 for P2WPKH bech32, 0x01 for P2PKH base58 if coin type is Bitcoi= +n, 0x00 for Ethereum account format if coin type is Ether, etc).=C2=A0 A se= +parate spec similar to SLIP-0044 could be created that defines the list of = +address formats and the derivation path values.<br> +<br> +When importing root master seeds or distributing the xpub's for each co= +signer to each party the discovery process in the proposal would need exten= +ding to try each address format in turn to determine whether there is a = +9;hit' when checking balances.=C2=A0 It does mean that the import proce= +ss is slower however the additional flexibility of supporting multiple addr= +ess formats possibly outweighs this.=C2=A0 I'm just thinking that havin= +g a rule to follow during discovery, particularly where non-Bitcoin coins a= +re concerned, is more explicit than leaving it open to the wallet implement= +er to figure out (for altcoins, what address format to use?).<br> +<br> +It also means that future address formats are supported as they are simply = +added to the new spec list for the coin type (can be done by anyone, simila= +r to the way SLIP-0044 works now) - it doesn't require a new BIP to sup= +port.=C2=A0 For example, if address format was a derivation level in BIP44,= + would BIP49 and BIP84 be needed?<br> +<br> +I'm somewhat musing out loud here, but I like the idea of being able to= + mostly self-discover as much as possible and reducing or eliminating the n= +eed for proprietary metadata attached to the wallet.<br> +<br> +Cheers<br> +<span>Paul<br> +<br> +From: <a href=3D"mailto:clarkmoody@gmail.com" target=3D"_blank">clarkmoody@= +gmail.com</a> <<a href=3D"mailto:clarkmoody@gmail.com" target=3D"_blank"= +>clarkmoody@gmail.com</a>> On Behalf Of Clark Moody<br> +Sent: 25 April 2018 15:36<br> +To: Paul Brown <paul@345.systems>; Bitcoin Protocol Discussion <<a= + href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi= +tcoin-dev@lists.linuxfoundation.org</a>><br> +Subject: Re: [bitcoin-dev] Multi-signature and multi-coin HD wallet in one = +BIP32 derivation path (new BIP)<br> +<br> +</span><span>Thanks for the proposal, Paul.<br> +<br> +>=C2=A0- What address format is expected when discovering balances and c= +reating transactions?<br> +<br> +Your solution does not solve your first bullet point, since the xpub encodi= +ng looks no different than any other xpub (BIP 44, 45, 49, etc). At the lea= +st, you should propose new version bytes to change the "xpub" in = +the encoding to some other string.<br> +<br> +Alternatively, I would suggest that you use the xpub serialization format d= +escribed in SLIP-0032 (<a href=3D"https://github.com/satoshilabs/slips/blob= +/master/slip-0032.md" rel=3D"noreferrer" target=3D"_blank">https://github.c= +om/satoshilabs/slips/blob/master/slip-0032.md</a>). It includes the derivat= +ion path within the xpub itself and uses Bech32 for encoding.<br> +<br> +Given a normal xpub with no additional information, a wallet must scan the = +address space for the various formats. SLIP-0032 solves this bootstrapping = +problem and avoids the UX nightmare of users being required to know to whic= +h BIP number the xpub conforms.<br> +<br> +Also, @luke-jr will give you a hard time to self-assigning a BIP number ;-)= +<br> +<br> +Thanks<br> +<br> +<br> +<br> +<br> +-Clark<br> +<br> +</span><span>On Wed, Apr 25, 2018 at 4:35 AM, Paul Brown via bitcoin-dev &l= +t;mailto:<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D= +"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br> +Hi<br> +=C2=A0<br> +I have written a new BIP describing a BIP32 derivation path that supports a= + single or multi-signature and multi-coin wallet from a single master seed.= +=C2=A0 It combines BIP44 and BIP45 and adds in a self-describing structure = +in the derivation path for multiple multi-sig combinations within the singl= +e wallet along with an extended public key export file format for public ke= +y distribution between parties.=C2=A0 I can particularly see this being use= +ful for multiple Lightning Network 2of2 accounts for different payment chan= +nels.<br> +=C2=A0<br> +The BIP can be found here: <a href=3D"https://github.com/gluexchange/bip/bl= +ob/master/bip-0046.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://= +github.com/gluexchange/bip/blob/master/bip-0046.mediawiki</a><br> +=C2=A0<br> +I appreciate that this might be re-hashing old ground as BIP44 in particula= +r has been widely adopted, however, BIP44 does leave itself open to a lot o= +f interpretation from a wallet portability perspective such as:<br> +=C2=A0<br> +- What address format is expected when discovering balances and creating tr= +ansactions?<br> +- Does the master seed represent a single-sig or multi-sig wallet?<br> +- If multi-sig, how many cosigners and what are their extended public keys = +(so that the wallet can generate the correctly formatted redeem script with= + public keys in the right order)?<br> +- If multi-sig, how do you prevent collisions on the same address index (in= + a wallet that is occasionally connected)?<br> +=C2=A0<br> +BIP45 solves the collision that occurs when the individual parties in a mul= +ti-sig group each give out a new address from a wallet, where the wallet ha= +sn=E2=80=99t been able to sync to mark the address as =E2=80=98used=E2=80= +=99 (this could happen if they gave out addresses independently at the same= + time).=C2=A0 It uses a cosigner index in the derivation path so that each = +party has their own path to their addresses.=C2=A0 However, BIP45 drops the= + multi-coin support that BIP44 has.<br> +=C2=A0<br> +This is a useful discussion on the problems of a collision and the merits o= +f separating cosigners in the derivation path: <a href=3D"https://www.mail-= +archive.com/bitcoin-development@lists.sourceforge.net/msg05188.html" rel=3D= +"noreferrer" target=3D"_blank">https://www.mail-archive.com/bitcoin-develop= +ment@lists.sourceforge.net/msg05188.html</a><br> +=C2=A0<br> +For the purposes of the BIP text (and the example paths used to generate ke= +ys) I=E2=80=99ve temporarily assigned it the number 46.=C2=A0 It looks like= + that is available and seemed somewhat appropriate given that it builds on = +the good work of BIP44 and BIP45.<br> +=C2=A0<br> +Paul Brown<br> +=C2=A0<br> +=C2=A0<br> +<br> +_______________________________________________<br> +bitcoin-dev mailing list<br> +</span>mailto:<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targ= +et=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +<br> +</blockquote></div><br></div></div> + +--000000000000565e2e056b562464-- + |