diff options
| author | Mike Hearn <mike@plan99.net> | 2014-04-26 11:43:23 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2014-04-26 09:43:30 +0000 |
| commit | 53c21e17682e796408b5ac9786c6682af0d7b8ea (patch) | |
| tree | 674f6f75fc6bc7f1584388746e5927ec8e50b03b | |
| parent | cfa720f306767f590f6c0aa2187e75d1fec4ccc7 (diff) | |
| download | pi-bitcoindev-53c21e17682e796408b5ac9786c6682af0d7b8ea.tar.gz pi-bitcoindev-53c21e17682e796408b5ac9786c6682af0d7b8ea.zip | |
Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets
| -rw-r--r-- | 07/1d99c218674b034e8d949c6f99cdaf26efccb6 | 413 |
1 files changed, 413 insertions, 0 deletions
diff --git a/07/1d99c218674b034e8d949c6f99cdaf26efccb6 b/07/1d99c218674b034e8d949c6f99cdaf26efccb6 new file mode 100644 index 000000000..eb5a6826c --- /dev/null +++ b/07/1d99c218674b034e8d949c6f99cdaf26efccb6 @@ -0,0 +1,413 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + 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 1Wdz8s-0006rB-MA + for bitcoin-development@lists.sourceforge.net; + Sat, 26 Apr 2014 09:43:30 +0000 +Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.214.175 as permitted sender) + client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com; + helo=mail-ob0-f175.google.com; +Received: from mail-ob0-f175.google.com ([209.85.214.175]) + by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Wdz8q-0001B7-UW + for bitcoin-development@lists.sourceforge.net; + Sat, 26 Apr 2014 09:43:30 +0000 +Received: by mail-ob0-f175.google.com with SMTP id wp4so5343665obc.34 + for <bitcoin-development@lists.sourceforge.net>; + Sat, 26 Apr 2014 02:43:23 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.60.62.34 with SMTP id v2mr11418108oer.37.1398505403570; Sat, + 26 Apr 2014 02:43:23 -0700 (PDT) +Sender: mh.in.england@gmail.com +Received: by 10.76.96.180 with HTTP; Sat, 26 Apr 2014 02:43:23 -0700 (PDT) +In-Reply-To: <CABQSq2Q98K5zbUbQAqSE4OYez2QuOaWTt+9n5iZmSR2boynf_Q@mail.gmail.com> +References: <CABQSq2Q98K5zbUbQAqSE4OYez2QuOaWTt+9n5iZmSR2boynf_Q@mail.gmail.com> +Date: Sat, 26 Apr 2014 11:43:23 +0200 +X-Google-Sender-Auth: WiY3Rdgrn015a2zKodeYrxpLvik +Message-ID: <CANEZrP3EGNsOgHm0P6fiU1P7OSgTd=pBYooPBrLQGMKPT9b8Qg@mail.gmail.com> +From: Mike Hearn <mike@plan99.net> +To: Manuel Araoz <manu@bitpay.com> +Content-Type: multipart/alternative; boundary=089e0141a7cacbe04904f7eee9a8 +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: 1Wdz8q-0001B7-UW +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] New BIP32 structure for P2SH multisig + wallets +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: Sat, 26 Apr 2014 09:43:30 -0000 + +--089e0141a7cacbe04904f7eee9a8 +Content-Type: text/plain; charset=UTF-8 + +I'm not sure I understand why you need any special structure for this at +all. The way I'd do it is just use regular HD wallets for everyone, of the +regular form, and then swap the watching keys. Why do people need to be +given a cosigner index at all, given that they all have unique root keys +anyway? + + +On Sat, Apr 26, 2014 at 12:27 AM, Manuel Araoz <manu@bitpay.com> wrote: + +> Hi, I'm part of the team building copay <https://github.com/bitpay/copay>, +> a multisignature P2SH HD wallet. We've been following the discussion +> regarding standardizing the structure for branches both on this list and on +> github (1 <https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki>, +> 2 <https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki>, 3<https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki>, +> 4 <https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki>, 5<https://github.com/bitcoin/bips/pull/52>). +> Soon, we realized the assumptions in the discussions were not true for a +> multisig hd wallet, so we wanted to share our current approach to that, to +> get feedback and see if we can arrive to a new standard (and possibly a new +> BIP) +> +> These are our assumptions: +> - N parties want to share an m-of-n wallet. +> - Each party must generate their master private keys independently. +> - Use multisig P2SH for all addresses. +> - Use BIP32 to derive public keys, then create a multisig script, and use +> the P2SH address for that. +> - The address generation process should not require communicating with +> other parties. (Thus, all parties must be able to generate all public keys) +> - Transaction creation + signing requires communication between parties, +> of course. +> +> ------------------------------------------------- +> +> Following BIP43, we're be using: +> +> +> m / purpose' / * +> +> where *purpose* is the hardened derivation scheme based on the new BIP +> number. +> We then define the following levels: +> +> +> m / purpose' / cosigner_index / change / address_index +> +> Each level has a special meaning detailed below: +> +> *cosigner_index* <http://en.wikipedia.org/wiki/Co-signing>: the index of +> the party creating this address. The indices can be determined +> independently by lexicographically sorting the master public keys of each +> cosigner. +> +> *change*: 0 for change, 1 for receive address. +> +> *address_index*: Addresses are numbered from index 0 in sequentially +> increasing manner. We're currently syncing the max used index for each +> branch between all parties when they connect, but we're open to considering +> removing the index sync and doing the more elegant used-address discovery +> via a gap limit, as discussed in BIP44<https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#address-gap-limit>. +> We feel 20 might be too low though. +> +> *Wallet high-level description:* +> Each party generates their own extended master keypair and shares the +> extended purpose' public key with the others, which is stored encrypted. +> Each party can generate any of the other's derived public keys, but only +> his own private keys. +> +> *General address generation procedure:* +> When generating an address, each party can independently generate the N +> needed public keys. They do this by deriving the public key in each of the +> different trees, but using the same path. They can then generate the +> multisig script and the corresponding p2sh address. In this way, each path +> corresponds to an address, but the public keys for that address come from +> different trees. +> +> *Receive address case:* +> Each cosigner generates addresses only on his own branch. One of the n +> cosigners wants to receive a payment, and the others are offline. He knows +> the last used index in his own branch, because only he generates addresses +> there. Thus, he can generate the public keys for all of the others using +> the next index, and calculate the needed script for the address. +> +> *Example: *Cosigner #2 wants to receive a payment to the shared wallet. +> His last used index on his own branch is 4. Then, the path for the next +> receive address is m/$purpose/2/1/5. He uses this same path in all of the +> cosigners trees to generate a public key for each one, and from that he +> gets the new p2sh address. +> +> *Change address case:* +> Again, each cosigner generates addresses only on his own branch. One of +> the n cosigners wants to create an outgoing payment, for which he'll need a +> change address. He generates a new address using the same procedure as +> above, but using a separate index to track the used change addresses. +> +> *Example: *Cosigner #5 wants to send a payment from the shared wallet, +> for which he'll need a change address. His last used change index on his +> own branch is 11. Then, the path for the next change address is +> m/$purpose/5/0/12. He uses this same path in all of the cosigners trees to +> generate a public key for each one, and from that he gets the new p2sh +> address. +> +> +> *Transaction creation and signing:* +> When creating a transaction, first one of the parties creates a +> Transaction Proposal. This is a transaction that spends some output stored +> in any of the p2sh multisig addresses (corresponding to any of the +> copayers' branches). This proposal is sent to the other parties, who decide +> if they want to sign. If they approve the proposal, they can generate their +> needed private key for that specific address (using the same path that +> generated the public key in that address, but deriving the private key +> instead), and sign it. Once the proposal reaches m signatures, any cosigner +> can broadcast it to the network, becoming final. The specifics of how this +> proposal is structured, and the protocol to accept or reject it, belong to +> another BIP, in my opinion. +> +> *Final comments:* +> - We're currently lexicographically sorting the public keys for each +> address separately. We've read Mike Belshe's comments about sorting the +> master public keys and then using the same order for all derived addresses, +> but we couldn't think of any benefits of doing that (I mean, the benefits +> of knowing whose public key is which). +> - We originally thought we would need a non-hardened version of purpose +> for the path, because we needed every party to be able to generate all the +> public keys of the others. With the proposed path, is it true that the +> cosigners will be able to generate them, by knowing the extended purpose +> public key for each copayer? (m/purpose') +> - The reason for using separate branches for each cosigner is we don't +> want two of them generating the same address and receiving simultaneous +> payments to it. The ideal case is that each address receives at most one +> payment, requested by the corresponding cosigner. +> +> +> Thoughts? +> Manuel +> +> +> ------------------------------------------------------------------------------ +> Start Your Social Network Today - Download eXo Platform +> Build your Enterprise Intranet with eXo Platform Software +> Java Based Open Source Intranet - Social, Extensible, Cloud Ready +> Get Started Now And Turn Your Intranet Into A Collaboration Platform +> http://p.sf.net/sfu/ExoPlatform +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +> +> + +--089e0141a7cacbe04904f7eee9a8 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">I'm not sure I understand why you need any special str= +ucture for this at all. The way I'd do it is just use regular HD wallet= +s for everyone, of the regular form, and then swap the watching keys. Why d= +o people need to be given a cosigner index at all, given that they all have= + unique root keys anyway?</div> +<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat, Apr 2= +6, 2014 at 12:27 AM, Manuel Araoz <span dir=3D"ltr"><<a href=3D"mailto:m= +anu@bitpay.com" target=3D"_blank">manu@bitpay.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 dir=3D"ltr"><div>Hi, I'm part of the team building <a href=3D"http= +s://github.com/bitpay/copay" target=3D"_blank">copay</a>, a multisignature = +P2SH HD wallet.=C2=A0We've been following the discussion regarding stan= +dardizing the structure for branches both on this list and on github (<a hr= +ef=3D"https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki" targe= +t=3D"_blank">1</a>, <a href=3D"https://github.com/bitcoin/bips/blob/master/= +bip-0039.mediawiki" target=3D"_blank">2</a>, <a href=3D"https://github.com/= +bitcoin/bips/blob/master/bip-0043.mediawiki" target=3D"_blank">3</a>, <a hr= +ef=3D"https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki" targe= +t=3D"_blank">4</a>, <a href=3D"https://github.com/bitcoin/bips/pull/52" tar= +get=3D"_blank">5</a>). Soon, we realized the assumptions in the discussions= + were not true for a multisig hd wallet, so we wanted to share our current = +approach to that, to get feedback and see if we can arrive to a new standar= +d (and possibly a new BIP)</div> + + + + +<div><br></div><div>These are our assumptions:=C2=A0</div><div>=C2=A0- N pa= +rties want to share an m-of-n wallet.</div><div>=C2=A0- Each party must gen= +erate their master private keys independently.</div><div>=C2=A0- Use multis= +ig P2SH for all addresses.</div> + + + +<div>=C2=A0- Use BIP32 to derive public keys, then create a multisig script= +, and use the P2SH address for that.</div><div>=C2=A0- The address generati= +on process should not require communicating with other parties. (Thus, all = +parties must be able to generate all public keys)</div> + + + +<div>=C2=A0- Transaction creation + signing requires communication between = +parties, of course.</div><div><br></div><div>------------------------------= +-------------------</div><div><br></div><div>Following BIP43, we're be = +using:</div> + + + +<div><pre style=3D"font-family:Consolas,'Liberation Mono',Courier,m= +onospace;font-size:13px;margin-top:15px;margin-bottom:15px;background-color= +:rgb(248,248,248);border:1px solid rgb(221,221,221);line-height:19px;overfl= +ow:auto;padding:6px 10px;border-top-left-radius:3px;border-top-right-radius= +:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-wrap= +:normal;color:rgb(51,51,51)"> + +m / purpose' / *</pre></div>where <i>purpose</i> is the hardened deriva= +tion scheme based on the new BIP number.<br><div>We then define the followi= +ng levels:</div><div><pre style=3D"font-family:Consolas,'Liberation Mon= +o',Courier,monospace;font-size:13px;margin-top:15px;margin-bottom:15px;= +background-color:rgb(248,248,248);border:1px solid rgb(221,221,221);line-he= +ight:19px;overflow:auto;padding:6px 10px;border-top-left-radius:3px;border-= +top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radi= +us:3px;word-wrap:normal;color:rgb(51,51,51)"> + +m / purpose' / cosigner_index / change / address_index</pre></div><div>= +Each level has a special meaning detailed below:</div><div><br></div><div><= +a href=3D"http://en.wikipedia.org/wiki/Co-signing" target=3D"_blank"><i>cos= +igner_index</i></a>: the index of the party creating this address. The indi= +ces can be determined independently by lexicographically sorting the master= + public keys of each cosigner.</div> + + + +<div><br></div><div><i>change</i>: 0 for change, 1 for receive address.</di= +v><div><br></div><div><i>address_index</i>:=C2=A0Addresses are numbered fro= +m index 0 in sequentially increasing manner. We're currently syncing th= +e max used index for each branch between all parties when they connect, but= + we're open to considering removing the index sync and doing the more e= +legant used-address discovery via a gap limit, <a href=3D"https://github.co= +m/bitcoin/bips/blob/master/bip-0044.mediawiki#address-gap-limit" target=3D"= +_blank">as discussed in BIP44</a>. We feel 20 might be too low though.=C2= +=A0</div> + + + +<div><br></div><div><b>Wallet high-level description:</b></div><div>Each pa= +rty generates their own extended master keypair and shares the extended pur= +pose' public key with the others, which is stored encrypted. Each party= + can generate any of the other's derived public keys, but only his own = +private keys.=C2=A0</div> + + + +<div><br><div><b>General address generation procedure:</b></div><div>When g= +enerating an address, each party can independently generate the N needed pu= +blic keys. They do this by deriving the public key in each of the different= + trees, but using the same path. They can then generate the multisig script= + and the corresponding p2sh address. In this way, each path corresponds to = +an address, but the public keys for that address come from different trees.= +</div> + + + +<div><br></div><div><b>Receive address case:</b></div><div>Each cosigner ge= +nerates addresses only on his own branch. One of the n cosigners wants to r= +eceive a payment, and the others are offline. He knows the last used index = +in his own branch, because only he generates addresses there. Thus, he can = +generate the public keys for all of the others using the next index, and ca= +lculate the needed script for the address.=C2=A0</div> + + + +<div><br></div><div><i>Example: </i>Cosigner #2 wants to receive a payment = +to the shared wallet. His last used index on his own branch is 4. Then, the= + path for the next receive address is m/$purpose/2/1/5. He uses this same p= +ath in all of the cosigners trees to generate a public key for each one, an= +d from that he gets the new p2sh address.</div> + + + +<div><br></div><div><b>Change address case:</b></div><div>Again, each cosig= +ner generates addresses only on his own branch. One of the n cosigners want= +s to create an outgoing payment, for which he'll need a change address.= + He generates a new address using the same procedure as above, but using a = +separate index to track the used change addresses.=C2=A0</div> + + + +<div><i><br>Example:=C2=A0</i>Cosigner #5 wants to send a payment from the = +shared wallet, for which he'll need a change address. His last used cha= +nge index on his own branch is 11. Then, the path for the next change addre= +ss is m/$purpose/5/0/12. He uses this same path in all of the cosigners tre= +es to generate a public key for each one, and from that he gets the new p2s= +h address.</div> + + + +<div><br></div><div><br></div><div><b>Transaction creation and signing:</b>= +</div><div>When creating a transaction, first one of the parties creates a = +Transaction Proposal. This is a transaction that spends some output stored = +in any of the p2sh multisig addresses (corresponding to any of the copayers= +' branches). This proposal is sent to the other parties, who decide if = +they want to sign. If they approve the proposal, they can generate their ne= +eded private key for that specific address (using the same path that genera= +ted the public key in that address, but deriving the private key instead), = +and sign it. Once the proposal reaches m signatures, any cosigner can broad= +cast it to the network, becoming final. The specifics of how this proposal = +is structured, and the protocol to accept or reject it, belong to another B= +IP, in my opinion.=C2=A0</div> + + + +<div><br></div><div><b>Final comments:</b></div><div>- We're currently = +lexicographically sorting the public keys for each address separately. We&#= +39;ve read Mike Belshe's comments about sorting the master public keys = +and then using the same order for all derived addresses, but we couldn'= +t think of any benefits of doing that (I mean, the benefits of knowing whos= +e public key is which).</div> + + +<div>- We originally thought we would need a non-hardened version of purpos= +e for the path, because we needed every party to be able to generate all th= +e public keys of the others. With the proposed path, is it true that the co= +signers will be able to generate them, by knowing the extended purpose publ= +ic key for each copayer? (m/purpose')</div> + + + +</div><div>- The reason for using separate branches for each cosigner is we= + don't want two of them generating the same address and receiving simul= +taneous payments to it. The ideal case is that each address receives at mos= +t one payment, requested by the corresponding cosigner.=C2=A0</div> + + +<div><br></div><div><br></div><div>Thoughts?<span class=3D"HOEnZb"><font co= +lor=3D"#888888"><br>Manuel</font></span></div></div> +<br>-----------------------------------------------------------------------= +-------<br> +Start Your Social Network Today - Download eXo Platform<br> +Build your Enterprise Intranet with eXo Platform Software<br> +Java Based Open Source Intranet - Social, Extensible, Cloud Ready<br> +Get Started Now And Turn Your Intranet Into A Collaboration Platform<br> +<a href=3D"http://p.sf.net/sfu/ExoPlatform" target=3D"_blank">http://p.sf.n= +et/sfu/ExoPlatform</a><br>_______________________________________________<b= +r> +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= +pment@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> + +--089e0141a7cacbe04904f7eee9a8-- + + |