diff options
| author | Clark Moody <clark@clarkmoody.com> | 2018-04-25 09:35:57 -0500 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-04-25 14:36:31 +0000 |
| commit | 3d6ca3914a869c164a4ba8a1a46286973384270d (patch) | |
| tree | a97b0c895ecf5e20efa684945854b53292e6e491 | |
| parent | d0b3059c1d55c4a8576479cef9aa036f4cd0856e (diff) | |
| download | pi-bitcoindev-3d6ca3914a869c164a4ba8a1a46286973384270d.tar.gz pi-bitcoindev-3d6ca3914a869c164a4ba8a1a46286973384270d.zip | |
Re: [bitcoin-dev] Multi-signature and multi-coin HD wallet in one BIP32 derivation path (new BIP)
| -rw-r--r-- | 75/81d05ddc4e796f212608987ee30bf2a5d5804d | 344 |
1 files changed, 344 insertions, 0 deletions
diff --git a/75/81d05ddc4e796f212608987ee30bf2a5d5804d b/75/81d05ddc4e796f212608987ee30bf2a5d5804d new file mode 100644 index 000000000..d61926eb2 --- /dev/null +++ b/75/81d05ddc4e796f212608987ee30bf2a5d5804d @@ -0,0 +1,344 @@ +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 A4F5888D + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 25 Apr 2018 14:36:31 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-lf0-f44.google.com (mail-lf0-f44.google.com + [209.85.215.44]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6A5FB42D + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 25 Apr 2018 14:36:30 +0000 (UTC) +Received: by mail-lf0-f44.google.com with SMTP id u21-v6so24215005lfu.9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 25 Apr 2018 07:36:30 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; + h=mime-version:sender:in-reply-to:references:from:date:message-id + :subject:to; bh=6YCKCHyLh+ZRk+eJsnsiepWem6dwiLtwD5I8W0LSsxA=; + b=qlMoHjJ0bTdnLaG9XwUYfC70O5CLpMC4z9c/jhakMAWjbd1nreEBnJXQ72wncpA1EH + QXihsjZb3qSFpwp/t5mJ2XmiMatXAWlx/4D+FCNiWWv/jMLnWARopNmHT5I0yfLr/6eA + /yjU94rfTfFF475iEafpWykL+07bPe744KUlRigSnxr7WDXgJ/j9oHm1Xb2YO/FzM8wP + hpraxhseu0moNfCd1oShhxPNpIsaNEkLmYG7wnH4ZVgz8wq+fqNbeYQMIaQZX2uh8rWc + x2xN7YAiykdcIDvqS+SEELwJFhu50Frfw0rBSET3c0Wg5JyR3/FqN98SDXh5LbBDBZiz + jCMQ== +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=clarkmoody-com.20150623.gappssmtp.com; s=20150623; + h=mime-version:sender:in-reply-to:references:from:date:message-id + :subject:to; bh=6YCKCHyLh+ZRk+eJsnsiepWem6dwiLtwD5I8W0LSsxA=; + b=OQywjZCV4mxxX6wzt4MqW7H5E0iRP/sQeOlN558QiWKWap4Nedk4UovkXgISnn4nEl + G9kjsbO7jRz3FGYt6W31Ka5e9+C6JWR8eCSyT6GUOVZhmdKHdC378a0HcGdzJqtTYCLM + dD8nucN/LmlayM0c4YGyJkSrARRndc+afOU8PsuRybzrJVcIOc3ySM44oKp0MFQ9s1ie + O8jDKdho5vDlmW/28RUwDfCNXyX1l4+DJJ+zfLWcDu/K+L++fLCwPLUwMrAc708r2ygV + DjLCkKu0/JyN3pHKPVFqNyEhU6Oc3ZslcAlkalNf5J0/KXTtJPDi9Dqdgj62HDNzRx2I + DR3A== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20161025; + h=x-gm-message-state:mime-version:sender:in-reply-to:references:from + :date:message-id:subject:to; + bh=6YCKCHyLh+ZRk+eJsnsiepWem6dwiLtwD5I8W0LSsxA=; + b=Cgwb0hO+qoZCTTsmoSjyupy1FDZb2fNwjOs90LNSTjDP4huASXllMPYCeY3sjGBKH1 + t1mqzUYASGHp+W0GyVe7PGkWc6RTQ+e7A6Cx512BxgMXUJDFSnmsNa3WWkK8nQfFvFtO + 4req7GP1ujvPN1mCkZODojeMkUJf4CpI97sslz7uG3F7PmV9z+7/LfZ8VUfqQ1E23Hwt + kAy97la44EuK+PUFBStg/A6U/Mzjfk/X8otsDdeJFlpnu25xZree3Ouphf1WoHYqZuur + cQAXkoa4T9Ep8yGsg0yuUibthKvt6fcPkd9NGOovrX/rLgvAfU63YuNu8co0AHkmAINh + +k9g== +X-Gm-Message-State: ALQs6tAMjLjRq3E1sjREnAfD5EwOSK9pS1QyfpITW8rQ/uXoTOBn6qJL + K50vfVAhV7baXDhXLxVtmeYVxUlUHrX1m3f+wU5SOOQZ +X-Google-Smtp-Source: AB8JxZoEgxxlE9TSfc39GGCzXu4Tw94cuyLVVuGUUKbcqYXkHsADUcbH/gx6PafvzrnSeuZRrm6uOOdI9l/BfuG35ig= +X-Received: by 2002:a19:8f82:: with SMTP id + s2-v6mr15133094lfk.55.1524666988624; + Wed, 25 Apr 2018 07:36:28 -0700 (PDT) +MIME-Version: 1.0 +Sender: clarkmoody@gmail.com +Received: by 10.46.101.8 with HTTP; Wed, 25 Apr 2018 07:35:57 -0700 (PDT) +In-Reply-To: <HE1PR09MB026619CDFFBA6D995600EF18988F0@HE1PR09MB0266.eurprd09.prod.outlook.com> +References: <HE1PR09MB026619CDFFBA6D995600EF18988F0@HE1PR09MB0266.eurprd09.prod.outlook.com> +From: Clark Moody <clark@clarkmoody.com> +Date: Wed, 25 Apr 2018 09:35:57 -0500 +X-Google-Sender-Auth: BoQ2-9dNTwS2yW4DpANo6e7uCPk +Message-ID: <CAHGSxGt649Ok=jp0STnHkYvEhWSOTwMfh0oB+7jqY6MAmr4TKQ@mail.gmail.com> +To: Paul Brown <paul@345.systems>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="00000000000041ff05056aad327d" +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: Wed, 25 Apr 2018 14:40:33 +0000 +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: Wed, 25 Apr 2018 14:36:31 -0000 + +--00000000000041ff05056aad327d +Content-Type: text/plain; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +Thanks for the proposal, Paul. + +*> - What address format is expected when discovering balances and creating +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 the +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 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 +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 < +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/msg05188.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 +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> +> + +--00000000000041ff05056aad327d +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:rgb(0,0,0)">Thanks for the proposal, Paul.<= +/div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;fo= +nt-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" styl= +e=3D"font-family:tahoma,sans-serif;font-size:small;color:rgb(0,0,0)"><i>>= +;=C2=A0<span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font= +-size:12.8px">- What address format is expected when discovering balances a= +nd creating transactions?</span></i><br></div><div class=3D"gmail_default" = +style=3D"font-family:tahoma,sans-serif;font-size:small;color:rgb(0,0,0)"><i= +><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:= +12.8px;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:4= +00;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:no= +ne;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);te= +xt-decoration-style:initial;text-decoration-color:initial;float:none;displa= +y:inline"><br></span></i></div><div class=3D"gmail_default" style=3D""><spa= +n style=3D"font-size:12.8px"><span style=3D"color:rgb(0,0,0);font-family:ta= +homa,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:no= +rmal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-al= +ign:start;text-indent:0px;text-transform:none;white-space:normal;word-spaci= +ng:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text= +-decoration-color:initial;float:none;display:inline">Your solution does not= + solve your first bullet point, s</span>ince the xpub encoding looks no dif= +ferent than any other xpub (BIP 44, 45, 49, etc). At the least, you should = +propose new version bytes to change the "xpub" in the encoding to= + some other string.</span></div><div class=3D"gmail_default" style=3D"font-= +family:tahoma,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div c= +lass=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-size:sma= +ll;color:rgb(0,0,0)">Alternatively, I would suggest that you use the xpub s= +erialization format described in SLIP-0032 (<a href=3D"https://github.com/s= +atoshilabs/slips/blob/master/slip-0032.md">https://github.com/satoshilabs/s= +lips/blob/master/slip-0032.md</a>). It includes the derivation path within = +the xpub itself and uses Bech32 for encoding.</div><div class=3D"gmail_defa= +ult" style=3D"font-family:tahoma,sans-serif;font-size:small;color:rgb(0,0,0= +)"><br></div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-= +serif;font-size:small;color:rgb(0,0,0)">Given a normal xpub with no additio= +nal information, a wallet must scan the address space for the various forma= +ts. SLIP-0032 solves this bootstrapping problem and avoids the UX nightmare= + of users being required to know to which BIP number the xpub conforms.</di= +v><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-= +size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style= +=3D"font-family:tahoma,sans-serif;font-size:small;color:rgb(0,0,0)">Also, @= +luke-jr will give you a hard time to self-assigning a BIP number ;-)</div><= +div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-siz= +e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f= +ont-family:tahoma,sans-serif;font-size:small;color:rgb(0,0,0)">Thanks</div>= +</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div class=3D"gmail= +_signature" data-smartmail=3D"gmail_signature"><div><br></div><div><br></di= +v><div>-Clark</div><div></div></div></div> +<br><div class=3D"gmail_quote">On Wed, Apr 25, 2018 at 4:35 AM, Paul Brown = +via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.l= +inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org= +</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin= +:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> + + + + + +<div lang=3D"EN-GB" link=3D"#0563C1" vlink=3D"#954F72"> +<div class=3D"m_8836520283562771257WordSection1"> +<p class=3D"MsoNormal">Hi<u></u><u></u></p> +<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> +<p class=3D"MsoNormal">I have written a new BIP describing a BIP32 derivati= +on path that supports a single or multi-signature and multi-coin wallet fro= +m a single master seed.=C2=A0 It combines BIP44 and BIP45 and adds in a sel= +f-describing structure in the derivation + path for multiple multi-sig combinations within the single wallet along wi= +th an extended public key export file format for public key distribution be= +tween parties.=C2=A0 I can particularly see this being useful for multiple = +Lightning Network 2of2 accounts for different + payment channels.<u></u><u></u></p> +<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> +<p class=3D"MsoNormal">The BIP can be found here: <a href=3D"https://github= +.com/gluexchange/bip/blob/master/bip-0046.mediawiki" target=3D"_blank"> +https://github.com/<wbr>gluexchange/bip/blob/master/<wbr>bip-0046.mediawiki= +</a><u></u><u></u></p> +<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> +<p class=3D"MsoNormal">I appreciate that this might be re-hashing old groun= +d as BIP44 in particular has been widely adopted, however, BIP44 does leave= + itself open to a lot of interpretation from a wallet portability perspecti= +ve such as:<u></u><u></u></p> +<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> +<p class=3D"MsoNormal">- What address format is expected when discovering b= +alances and creating transactions?<u></u><u></u></p> +<p class=3D"MsoNormal">- Does the master seed represent a single-sig or mul= +ti-sig wallet?<u></u><u></u></p> +<p class=3D"MsoNormal">- If multi-sig, how many cosigners and what are thei= +r extended public keys (so that the wallet can generate the correctly forma= +tted redeem script with public keys in the right order)?<u></u><u></u></p> +<p class=3D"MsoNormal">- If multi-sig, how do you prevent collisions on the= + same address index (in a wallet that is occasionally connected)?<u></u><u>= +</u></p> +<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> +<p class=3D"MsoNormal">BIP45 solves the collision that occurs when the indi= +vidual parties in a multi-sig group each give out a new address from a wall= +et, where the wallet hasn=E2=80=99t been able to sync to mark the address a= +s =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 addre= +sses.=C2=A0 However, BIP45 drops the multi-coin support that BIP44 has.<u><= +/u><u></u></p> +<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> +<p class=3D"MsoNormal">This is a useful discussion on the problems of a col= +lision and the merits of separating cosigners in the derivation path: +<a href=3D"https://www.mail-archive.com/bitcoin-development@lists.sourcefor= +ge.net/msg05188.html" target=3D"_blank"> +https://www.mail-archive.com/<wbr>bitcoin-development@lists.<wbr>sourceforg= +e.net/msg05188.html</a><u></u><u></u></p> +<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> +<p class=3D"MsoNormal">For the purposes of the BIP text (and the example pa= +ths used to generate keys) I=E2=80=99ve temporarily assigned it the number = +46.=C2=A0 It looks like that is available and seemed somewhat appropriate g= +iven that it builds on the good work of BIP44 and + BIP45.<span class=3D"HOEnZb"><font color=3D"#888888"><u></u><u></u></font>= +</span></p><span class=3D"HOEnZb"><font color=3D"#888888"> +<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> +<p class=3D"MsoNormal">Paul Brown<u></u><u></u></p> +<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> +<p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p> +</font></span></div> +</div> + +<br>______________________________<wbr>_________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +<wbr>linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= +/mailman/listinfo/bitcoin-<wbr>dev</a><br> +<br></blockquote></div><br></div> + +--00000000000041ff05056aad327d-- + |