934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/6bcb38f2268cc411/bip-0045.mediawiki

2019-10-12T13:01:32Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/6bcb38f2268cc411/bip-0045.mediawiki

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0045.mediawiki

2019-09-24T17:58:34Z

Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0045.mediawiki

Show changes

934: Removing redundant parameter.

2015-12-29T13:49:20Z

Removing redundant parameter.

← Older revision		Revision as of 13:49, 29 December 2015
Line 12:		Line 12:
	</pre>		</pre>

	{{BipMoved\|bip-0044.mediawiki~~\|BIP 0044~~}}		{{BipMoved\|bip-0044.mediawiki}}

Spaz926: Created page with "{{bip}}

   BIP: 45   Title: Structure for Deterministic P2SH Multisignature Wallets   Authors: Manuel Araoz             Ryan X. Charles 
2015-05-20T23:41:38Z
Created page with "{{bip}}  <pre>   BIP: 45   Title: Structure for Deterministic P2SH Multisignature Wallets   Authors: Manuel Araoz <manu@bitpay.com>            Ryan X. Charles <ryan@bitpay.com..."
New page
{{bip}}



<pre>

  BIP: 45

  Title: Structure for Deterministic P2SH Multisignature Wallets

  Authors: Manuel Araoz <manu@bitpay.com>

           Ryan X. Charles <ryan@bitpay.com>

           Matias Alejo Garcia <matias@bitpay.com>

  Status: Draft

  Type: Standards Track

  Created: 2014-04-25

</pre>



{{BipMoved|bip-0044.mediawiki|BIP 0044}}

← Older revision		Revision as of 13:01, 12 October 2019
Line 20:		Line 20:
	This BIP defines a structure for hierarchical deterministic P2SH multi-party		This BIP defines a structure for hierarchical deterministic P2SH multi-party
	multi-signature wallets (HDPM wallets from now on) based on the algorithm		multi-signature wallets (HDPM wallets from now on) based on the algorithm
	described in BIP-0032 (BIP32 from now on) and purpose scheme described in		described in BIP-0032 (BIP32 from now on) and purpose scheme described in
	BIP-0043 (BIP43 from now on).		BIP-0043 (BIP43 from now on).
	This BIP is a particular application of BIP43.		This BIP is a particular application of BIP43.
Line 67:		Line 67:
	be determined independently by lexicographically sorting the purpose public		be determined independently by lexicographically sorting the purpose public
	keys of each cosigner. Each cosigner creates addresses on its own branch,		keys of each cosigner. Each cosigner creates addresses on its own branch,
	even though they have independent extended master public key, as explained		even though they have independent extended master public key, as explained
	in the "Address generation" section.		in the "Address generation" section.

Line 83:		Line 83:
	</pre>		</pre>

	it should use `m / 45 ' / 0 / *` for		it should use <code>m / 45 ' / 0 / *</code> for
	`039863fb5f07b667d9b1ca68773c6e6cdbcac0088ffba9af46f6f6acd153d44463`,		<code>039863fb5f07b667d9b1ca68773c6e6cdbcac0088ffba9af46f6f6acd153d44463</code>,
	`m / 45 ' / 1 / *` for		<code>m / 45 ' / 1 / *</code> for
	`03a473275a750a20b7b71ebeadfec83130c014da4b53f1c4743fcf342af6589a38`,		<code>03a473275a750a20b7b71ebeadfec83130c014da4b53f1c4743fcf342af6589a38</code>,
	and `m / 45 ' / 2 / *` for		and <code>m / 45 ' / 2 / *</code> for
	`03f76588e06c0d688617ef365d1e58a7f1aa84daa3801380b1e7f12acc9a69cd13`,		<code>03f76588e06c0d688617ef365d1e58a7f1aa84daa3801380b1e7f12acc9a69cd13</code>,
	as dictated by their lexicographical order.		as dictated by their lexicographical order.

Line 106:		Line 106:

	For example, if cosigner 2 wants to generate a change address, he would use		For example, if cosigner 2 wants to generate a change address, he would use
	`m / 45 ' / 2 / 1 / `, and `m / 45 ' / 2 / 0 / ` for a receive		<code>m / 45 ' / 2 / 1 / </code>, and <code>m / 45 ' / 2 / 0 / </code> for a receive
	address.		address.

Line 122:		Line 122:
	extended purpose' public key with the others, which is stored encrypted.		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		Each party can generate any of the other's derived public keys, but only
	his own private keys.		his own private keys.

	===Address Generation Procedure===		===Address Generation Procedure===
Line 141:		Line 141:
	Example: Cosigner #2 wants to receive a payment to the shared wallet. His last		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		used index on his own branch is 4. Then, the path for the next receive
	address is `m/45'/2/0/5`. He uses this same path in all of the cosigners		address is <code>m/45'/2/0/5</code>. 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		trees to generate a public key for each one, and from that he gets the new
	p2sh address.		p2sh address.
Line 148:		Line 148:
	n cosigners wants to create an outgoing payment, for which he'll need a change		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		address. He generates a new address using the same procedure as above, but
	using a separate index to track the used change addresses.		using a separate index to track the used change addresses.

	Example: Cosigner #5 wants to send a payment from the shared wallet, for which		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		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/45'/5/1/12`. He uses		11. Then, the path for the next change address is <code>m/45'/5/1/12</code>. He uses
	this same path in all of the cosigners trees to generate a public key for each		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.		one, and from that he gets the new p2sh address.
Line 167:		Line 167:
	proposal reaches m signatures, any cosigner can broadcast it to the network,		proposal reaches m signatures, any cosigner can broadcast it to the network,
	becoming final. The specifics of how this proposal is structured, and the		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.		protocol to accept or reject it, belong to another BIP, in my opinion.

	===Address discovery===		===Address discovery===
Line 175:		Line 175:

	# for each cosigner:		# for each cosigner:
	# derive the cosigner's node (`m / 45' / cosigner_index`)		# derive the cosigner's node (<code>m / 45' / cosigner_index</code>)
	# for both the external and internal chains on this node (`m / 45' / cosigner_index / 0` and `m / 45' / cosigner_index / 1`):		# for both the external and internal chains on this node (<code>m / 45' / cosigner_index / 0</code> and <code>m / 45' / cosigner_index / 1</code>):
	# scan addresses of the chain; respect the gap limit described below		# scan addresses of the chain; respect the gap limit described below

Line 186:		Line 186:
	===Address gap limit===		===Address gap limit===

	Address gap limit is currently set to 20. If the software hits 20 unused		Address gap limit is currently set to 20. If the software hits 20 unused
	addresses (no transactions associated with that address) in a row, it expects		addresses (no transactions associated with that address) in a row, it expects
	there are no used addresses beyond this point and stops searching the address chain.		there are no used addresses beyond this point and stops searching the address chain.
Line 202:		Line 202:
	two of them generating the same address and receiving simultaneous payments		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,		to it. The ideal case is that each address receives at most one payment,
	requested by the corresponding cosigner.		requested by the corresponding cosigner.

	==Examples==		==Examples==

BIP 0045 - Revision history

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/6bcb38f2268cc411/bip-0045.mediawiki

934: Update BIP text with latest version from https://github.com/bitcoin/bips/blob/b5723035e23896d0/bip-0045.mediawiki

934: Removing redundant parameter.