bitcoin-bips/Multisig Derivation Standard.mediawiki

<pre>
  BIP: Number not assigned
  Layer: Applications
  Title: Modern Hierarchy for Deterministic Multisignature Wallets
  Author: Robert Spigler <RobertSpigler@ProtonMail.ch>
  Comments-Summary: No comments
  Comments-URI:
  Status: Proposed
  Type: Standards Track
  Created: 2020-03-11
</pre>

===Copyright===

This BIP is licensed under the 2-clause BSD license.

==Abstract==

This BIP defines a sane hierarchy for deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on), purpose scheme described in 
BIP-0043 (BIP43 from now on), and multi-account hierarchy described in BIP-0044 (BIP44 from now on).

This BIP is a particular application of BIP43.

==Motivation==

With the increase of more user friendly (offline) multisignature wallets, and adoption of new technologies such as 
[https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor language] and [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki 
BIP-0174 (Partially Signed Bitcoin Transactions)] it is necessary to create a common derivation scheme that makes use of all new technologies.

There are many issues with the current standards. As background, BIP 44/49/84 specifies:

<pre>
m / purpose' / coin_type' / account' / change / address_index
</pre>

where the BIP43 <code>purpose'</code> path is separate for each script (P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively).  However, these per-script derivations 
are made redundant with descriptors, which describe a collection of output scripts.  Note also that these are single sig derivations (which souldn't be reused for 
multisig).

Standardization is needed for multisig derivation paths.  There are some in existence, but all have issues.  For example, BIP45 specifies:

<pre>
m / purpose' / cosigner_index / change / address_index
</pre>

Like BIP44/49/84, BIP45 unecessarily demands a single script type (here, P2SH).  In addition, BIP45 sets <code>cosigner_index</code> in order to sort the 
<code>purpose'</code> public keys of each cosigner.  This too is redundant, as descriptors can set the order of the public keys with <code>multi</code> or have 
them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67) with <code>sortedmulti</code>.  Sorting 
public keys between cosigners in order to create the full derivation path, prior to sending the key record to the coordinator to create the descriptor, merely adds 
additional unnecessary communication rounds.

There is an additional multisig derivation path in use "BIP"48 (there is no real standard), which specifies:

<pre>
m / purpose' / coin_type' / account' / script_type' / change / address_index
</pre>

Rather than having a separate BIP per script type after P2SH (BIP45), vendors decided to insert <code>script_type'</code> into the derivation path (where 
P2SH-P2WSH=1, P2WSH=2, Future_Script=3, etc). As described previously, this is unnecessary, as the descriptor sets the script.  While it attempts to reduce 
maintainence work by getting rid of new BIPs-per-script, it still requires maintaining an updated, redundant, script_type list.

The hierarchy proposed in this paper is quite comprehensive. It allows the handling of multiple accounts, external and internal chains per account, and millions 
of addresses per chain.

Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.

This paper was inspired from BIP44.

==Key sorting==

Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the <code>sortedmulti</code> function) so that all 
possible multisignature addresses/scripts are derived from deterministically sorted public keys.

==Path levels==

You should not be mixing keys and scripts. We define the following 5 levels in the BIP32 path:

<pre>
m / purpose' / coin_type' / account' / change / address_index
</pre>

<code>h</code> or <code>'</code> in the path indicates that BIP32 hardened derivation is used.

Each level has a special meaning, described in the chapters below.

===Purpose===

Purpose is a constant set to XY' following the BIP43 recommendation.
It indicates that the subtree of this node is used according to this specification.

Hardened derivation is used at this level.

===Coin type===

One master node (seed) can be used for multiple Bitcoin networks.
Sharing the same space for various networks has some disadvantages.

Avoiding reusing addresses across networks and improving privacy issues.

Coin type <code>0</code> for mainnet and <code>1</code> for testnet.

Hardened derivation is used at this level.

===Account===

This level splits the key space into independent user identities, following the BIP44 pattern, so the wallet never mixes the coins across different accounts.

Users can use these accounts to organize the funds in the same fashion as bank accounts; for donation purposes (where all addresses are considered public), for 
saving purposes, for common expenses, etc.

Accounts are numbered from index 0 in sequentially increasing manner.
This number is used as child index in BIP32 derivation.

Hardened derivation is used at this level.

===Change===

Constant 0 is used for external chain and constant 1 for internal chain (also known as change addresses). External chain is used for addresses that are meant to be 
visible outside of the wallet (e.g. for receiving payments). Internal chain is used for addresses which are not meant to be visible outside of the wallet and is 
used for return transaction change.

Public derivation is used at this level.

===Index===

Addresses are numbered from index 0 in sequentially increasing manner.
This number is used as child index in BIP32 derivation.

Public derivation is used at this level.

==Examples==

{|
|network
|account
|chain
|address
|path
|-
|mainnet
|first
|external
|first
|m / XY' / 0' / 0' / 0 / 0
|-
|mainnet
|first
|external
|second
|m / XY' / 0' / 0' / 0 / 1
|-
|mainnet
|first
|change
|first
|m / XY' / 0' / 0' / 1 / 0
|-
|mainnet
|first
|change
|second
|m / XY' / 0' / 0' / 1 / 1
|-
|mainnet
|second
|external
|first
|m / XY' / 0' / 1' / 0 / 0
|-
|mainnet
|second
|external
|second
|m / XY' / 0' / 1' / 0 / 1
|-
|testnet
|first
|external
|first
|m / XY' / 1' / 0' / 0 / 0
|-
|testnet
|first
|external
|second
|m / XY' / 1' / 0' / 0 / 1
|-
|testnet
|first
|change
|first
|m / XY' / 1' / 0' / 1 / 0
|-
|testnet
|first
|change
|second
|m / XY' / 1' / 0' / 1 / 1
|-
|testnet
|second
|external
|first
|m / XY' / 1' / 1' / 0 / 0
|-
|testnet
|second
|external
|second
|m / XY' / 1' / 1' / 0 / 1
|-
|testnet
|second
|change
|first
|m / XY' / 1' / 1' / 1 / 0
|-
|testnet
|second
|change
|second
|m / XY' / 1' / 1' / 1 / 1
|}

==Acknowledgement==


==References==

Original mailing list thread: TBD

* [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
* [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]
* [[bip-0044.mediawiki|BIP44 - Multi-Account Hierarchy for Deterministic Wallets]]
* [[https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md - Output Descriptors]]
* [[bip-0174.mediawiki|BIP174 - Partially Signed Bitcoin Transaction Format]]
* [[bip-0067.mediawiki|BIP67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting]]