path: root/e0/1ca8b0a1d6e04f92758ccaae48128b479b2bcf

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <manuelaraoz@gmail.com>) id 1WdobN-0003hI-7D
	for bitcoin-development@lists.sourceforge.net;
	Fri, 25 Apr 2014 22:28:13 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.51 as permitted sender)
	client-ip=209.85.192.51; envelope-from=manuelaraoz@gmail.com;
	helo=mail-qg0-f51.google.com; 
Received: from mail-qg0-f51.google.com ([209.85.192.51])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WdobL-0001Zb-Ff
	for bitcoin-development@lists.sourceforge.net;
	Fri, 25 Apr 2014 22:28:13 +0000
Received: by mail-qg0-f51.google.com with SMTP id f51so4687554qge.24
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 25 Apr 2014 15:28:06 -0700 (PDT)
X-Received: by 10.224.26.71 with SMTP id d7mr15279757qac.29.1398464885898;
	Fri, 25 Apr 2014 15:28:05 -0700 (PDT)
MIME-Version: 1.0
Sender: manuelaraoz@gmail.com
Received: by 10.224.20.9 with HTTP; Fri, 25 Apr 2014 15:27:45 -0700 (PDT)
From: Manuel Araoz <manu@bitpay.com>
Date: Fri, 25 Apr 2014 19:27:45 -0300
X-Google-Sender-Auth: 0dwh0kcfJa2x7TpdGboHKWFzzWU
Message-ID: <CABQSq2Q98K5zbUbQAqSE4OYez2QuOaWTt+9n5iZmSR2boynf_Q@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/alternative; boundary=089e0149c510c1463b04f7e57a32
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
	(manuelaraoz[at]gmail.com)
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [209.85.192.51 listed in list.dnswl.org]
	-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: 1WdobL-0001Zb-Ff
Subject: [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: Fri, 25 Apr 2014 22:28:13 -0000

--089e0149c510c1463b04f7e57a32
Content-Type: text/plain; charset=ISO-8859-1

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

--089e0149c510c1463b04f7e57a32
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi, I&#39;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.=A0We&#39;ve been following the discussion regarding standar=
dizing the structure for branches both on this list and on github (<a href=
=3D"https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki" target=
=3D"_blank">1</a>, <a href=3D"https://github.com/bitcoin/bips/blob/master/b=
ip-0039.mediawiki" target=3D"_blank">2</a>, <a href=3D"https://github.com/b=
itcoin/bips/blob/master/bip-0043.mediawiki" target=3D"_blank">3</a>, <a hre=
f=3D"https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki" target=
=3D"_blank">4</a>, <a href=3D"https://github.com/bitcoin/bips/pull/52" targ=
et=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 a=
pproach to that, to get feedback and see if we can arrive to a new standard=
 (and possibly a new BIP)</div>



<div><br></div><div>These are our assumptions:=A0</div><div>=A0- N parties =
want to share an m-of-n wallet.</div><div>=A0- Each party must generate the=
ir master private keys independently.</div><div>=A0- Use multisig P2SH for =
all addresses.</div>


<div>=A0- Use BIP32 to derive public keys, then create a multisig script, a=
nd use the P2SH address for that.</div><div>=A0- The address generation pro=
cess should not require communicating with other parties. (Thus, all partie=
s must be able to generate all public keys)</div>


<div>=A0- Transaction creation + signing requires communication between par=
ties, of course.</div><div><br></div><div>---------------------------------=
----------------</div><div><br></div><div>Following BIP43, we&#39;re be usi=
ng:</div>


<div><pre style=3D"font-family:Consolas,&#39;Liberation Mono&#39;,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&#39; / *</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,&#39;Liberation Mon=
o&#39;,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&#39; / 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>:=A0Addresses are numbered from i=
ndex 0 in sequentially increasing manner. We&#39;re currently syncing the m=
ax used index for each branch between all parties when they connect, but we=
&#39;re open to considering removing the index sync and doing the more eleg=
ant used-address discovery via a gap limit, <a href=3D"https://github.com/b=
itcoin/bips/blob/master/bip-0044.mediawiki#address-gap-limit" target=3D"_bl=
ank">as discussed in BIP44</a>. We feel 20 might be too low though.=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&#39; public key with the others, which is stored encrypted. Each party=
 can generate any of the other&#39;s derived public keys, but only his own =
private keys.=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.=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&#39;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.=A0</div>


<div><i><br>Example:=A0</i>Cosigner #5 wants to send a payment from the sha=
red wallet, for which he&#39;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 a=
ddress.</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=
&#39; 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.=A0</div>


<div><br></div><div><b>Final comments:</b></div><div>- We&#39;re currently =
lexicographically sorting the public keys for each address separately. We&#=
39;ve read Mike Belshe&#39;s comments about sorting the master public keys =
and then using the same order for all derived addresses, but we couldn&#39;=
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&#39;)</div>


</div><div>- The reason for using separate branches for each cosigner is we=
 don&#39;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.=A0</div>

<div><br></div><div><br></div><div>Thoughts?<br>Manuel</div></div>

--089e0149c510c1463b04f7e57a32--