From 675c3a8703d79e09807d6426c73f7c301c1d3eb7 Mon Sep 17 00:00:00 2001 From: Robert Spigler Date: Thu, 11 Mar 2021 03:11:51 -0500 Subject: [PATCH 01/27] Create Multisig Derivation Standard.mediawiki Draft --- Multisig Derivation Standard.mediawiki | 237 +++++++++++++++++++++++++ 1 file changed, 237 insertions(+) create mode 100644 Multisig Derivation Standard.mediawiki diff --git a/Multisig Derivation Standard.mediawiki b/Multisig Derivation Standard.mediawiki new file mode 100644 index 00000000..6d11c6ea --- /dev/null +++ b/Multisig Derivation Standard.mediawiki @@ -0,0 +1,237 @@ +
+  BIP: Number not assigned
+  Layer: Applications
+  Title: Modern Hierarchy for Deterministic Multisignature Wallets
+  Author: Robert Spigler 
+  Comments-Summary: No comments
+  Comments-URI:
+  Status: Proposed
+  Type: Standards Track
+  Created: 2020-03-11
+
+ +===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: + +
+m / purpose' / coin_type' / account' / change / address_index
+
+ +where the BIP43 purpose' 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: + +
+m / purpose' / cosigner_index / change / address_index
+
+ +Like BIP44/49/84, BIP45 unecessarily demands a single script type (here, P2SH). In addition, BIP45 sets cosigner_index in order to sort the +purpose' public keys of each cosigner. This too is redundant, as descriptors can set the order of the public keys with multi or have +them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67) with sortedmulti. 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: + +
+m / purpose' / coin_type' / account' / script_type' / change / address_index
+
+ +Rather than having a separate BIP per script type after P2SH (BIP45), vendors decided to insert script_type' 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 sortedmulti 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: + +
+m / purpose' / coin_type' / account' / change / address_index
+
+ +h or ' 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 0 for mainnet and 1 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]] From a067f9ca085e296d383399aa62e1752b09117523 Mon Sep 17 00:00:00 2001 From: Robert Spigler Date: Thu, 11 Mar 2021 16:17:51 -0500 Subject: [PATCH 02/27] Formatting --- Multisig Derivation Standard.mediawiki | 41 ++++++++------------------ 1 file changed, 13 insertions(+), 28 deletions(-) diff --git a/Multisig Derivation Standard.mediawiki b/Multisig Derivation Standard.mediawiki index 6d11c6ea..e44dcdc9 100644 --- a/Multisig Derivation Standard.mediawiki +++ b/Multisig Derivation Standard.mediawiki @@ -16,16 +16,13 @@ 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 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. +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: @@ -33,9 +30,7 @@ There are many issues with the current standards. As background, BIP 44/49/84 sp m / purpose' / coin_type' / account' / change / address_index -where the BIP43 purpose' 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). +where the BIP43 purpose' 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 shouldn'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: @@ -43,24 +38,17 @@ Standardization is needed for multisig derivation paths. There are some in exis m / purpose' / cosigner_index / change / address_index -Like BIP44/49/84, BIP45 unecessarily demands a single script type (here, P2SH). In addition, BIP45 sets cosigner_index in order to sort the -purpose' public keys of each cosigner. This too is redundant, as descriptors can set the order of the public keys with multi or have -them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67) with sortedmulti. 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. +Like BIP44/49/84, BIP45 unecessarily demands a single script type (here, P2SH). In addition, BIP45 sets cosigner_index in order to sort the purpose' public keys of each cosigner. This too is redundant, as descriptors can set the order of the public keys with multi or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with sortedmulti. 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: +The second multisignature "standard" in use is m/48', which specifies: 
 m / purpose' / coin_type' / account' / script_type' / change / address_index
-Rather than having a separate BIP per script type after P2SH (BIP45), vendors decided to insert script_type' 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. +Rather than having a separate BIP per script after P2SH (BIP45), vendors decided to insert script_type' 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. +The hierarchy proposed later in this paper solves these issues and 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. @@ -68,8 +56,7 @@ This paper was inspired from BIP44. ==Key sorting== -Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the sortedmulti function) so that all -possible multisignature addresses/scripts are derived from deterministically sorted public keys. +Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the sortedmulti function) so that all possible multisignature addresses/scripts are derived from deterministically sorted public keys. ==Path levels== @@ -95,7 +82,7 @@ Hardened derivation is used at this level. 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. +This level creates a separate subtree for every network, avoiding reusing addresses across networks and improving privacy issues. Coin type 0 for mainnet and 1 for testnet. @@ -105,8 +92,7 @@ Hardened derivation is used at this level. 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. +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. @@ -115,9 +101,7 @@ 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. +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. @@ -232,6 +216,7 @@ 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]] +* [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]] + From ef3a16eeec646da955591371127c103da33aa80a Mon Sep 17 00:00:00 2001 From: Robert Spigler Date: Fri, 12 Mar 2021 16:57:55 -0500 Subject: [PATCH 03/27] Update and rename Multisig Derivation Standard.mediawiki to Modern Derivation Standard.mediawiki Multisig and singlesig support --- ...ki => Modern Derivation Standard.mediawiki | 23 +++++++++++-------- 1 file changed, 14 insertions(+), 9 deletions(-) rename Multisig Derivation Standard.mediawiki => Modern Derivation Standard.mediawiki (72%) diff --git a/Multisig Derivation Standard.mediawiki b/Modern Derivation Standard.mediawiki similarity index 72% rename from Multisig Derivation Standard.mediawiki rename to Modern Derivation Standard.mediawiki index e44dcdc9..c8d5a844 100644 --- a/Multisig Derivation Standard.mediawiki +++ b/Modern Derivation Standard.mediawiki @@ -1,7 +1,7 @@ 
   BIP: Number not assigned
   Layer: Applications
-  Title: Modern Hierarchy for Deterministic Multisignature Wallets
+  Title: Signature and Script Independant Hierarchy for Deterministic Wallets
   Author: Robert Spigler 
   Comments-Summary: No comments
   Comments-URI:
@@ -16,13 +16,13 @@ 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 defines a sane hierarchy for deterministic 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.
+With the increase of adoption of new technologies such as [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor language] 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:
 
@@ -30,9 +30,9 @@ There are many issues with the current standards. As background, BIP 44/49/84 sp
 m / purpose' / coin_type' / account' / change / address_index
-where the BIP43 purpose' 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 shouldn't be reused for multisig). +where the BIP43 purpose' 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 BIPs are restricted for single sig wallets. This is unecessary, as descriptors handle whether the scripts are single-key or multi-key. -Standardization is needed for multisig derivation paths. There are some in existence, but all have issues. For example, BIP45 specifies: +Modification is also needed for multisig derivation paths. For example, BIP45 specifies: 
 m / purpose' / cosigner_index / change / address_index
@@ -46,9 +46,9 @@ The second multisignature "standard" in use is m/48', which specifies:
 m / purpose' / coin_type' / account' / script_type' / change / address_index
-Rather than having a separate BIP per script after P2SH (BIP45), vendors decided to insert script_type' 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. +Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert script_type' 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 later in this paper solves these issues and is quite comprehensive. It allows the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain. +The hierarchy proposed later in this paper solves these issues and is quite comprehensive. It allows the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, regardless of the script or signature type. Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP. @@ -60,7 +60,9 @@ Any wallet that supports descriptors inherently supports deterministic key sorti ==Path levels== -You should not be mixing keys and scripts. We define the following 5 levels in the BIP32 path: +We should not be mixing keys and scripts in the same layer. The wallet should create extended private/public keys independent of the script or signature type, whereas the descriptor language tells wallets to watch (single or multi-sig) outputs with the specified public keys. + +We define the following 5 levels in the BIP32 path: 
 m / purpose' / coin_type' / account' / change / address_index
@@ -99,6 +101,10 @@ This number is used as child index in BIP32 derivation.
 
 Hardened derivation is used at this level.
 
+It is crucial that the index is increased for each new wallet joined or private/public keys created; for both privacy and cryptographic purposes.
+For example, in multisignature wallets, before sending a new key record to a coordinator, the wallet must increment the account' level.  Before creating it's own single signature wallet, the account' level must again be incremented.
+This prevents key reuse - across single signature and multisignature wallets, across ECDSA and Schnorr signatures, and inbetween the same wallet types.
+
 ===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.
@@ -217,6 +223,5 @@ Original mailing list thread: TBD
 * [[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]]
 

From c747ee9880866935da9f74cd15946be480666be1 Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Fri, 12 Mar 2021 17:32:50 -0500
Subject: [PATCH 04/27] Update Modern Derivation Standard.mediawiki

minor edit
---
 Modern Derivation Standard.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Modern Derivation Standard.mediawiki b/Modern Derivation Standard.mediawiki
index c8d5a844..5cf36654 100644
--- a/Modern Derivation Standard.mediawiki	
+++ b/Modern Derivation Standard.mediawiki	
@@ -101,7 +101,7 @@ This number is used as child index in BIP32 derivation.
 
 Hardened derivation is used at this level.
 
-It is crucial that the index is increased for each new wallet joined or private/public keys created; for both privacy and cryptographic purposes.
+It is crucial that this level is increased for each new wallet joined or private/public keys created; for both privacy and cryptographic purposes.
 For example, in multisignature wallets, before sending a new key record to a coordinator, the wallet must increment the account' level.  Before creating it's own single signature wallet, the account' level must again be incremented.
 This prevents key reuse - across single signature and multisignature wallets, across ECDSA and Schnorr signatures, and inbetween the same wallet types.
 

From deba2a75be9f8151f4d77d21ef517ad280cc1a61 Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Sun, 14 Mar 2021 16:02:45 -0400
Subject: [PATCH 05/27] Clarify testnets

---
 Modern Derivation Standard.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Modern Derivation Standard.mediawiki b/Modern Derivation Standard.mediawiki
index 5cf36654..61a4fefa 100644
--- a/Modern Derivation Standard.mediawiki	
+++ b/Modern Derivation Standard.mediawiki	
@@ -86,7 +86,7 @@ Sharing the same space for various networks has some disadvantages.
 
 This level creates a separate subtree for every network, avoiding reusing addresses across networks and improving privacy issues.
 
-Coin type 0 for mainnet and 1 for testnet.
+Coin type 0 for mainnet and 1 for testnets (testnet, regtest, and signet).
 
 Hardened derivation is used at this level.
 

From 8c346ca3ba5d82ee35a91c5bd9c803a758dd68f5 Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Thu, 18 Mar 2021 17:15:07 -0400
Subject: [PATCH 06/27] Revert to multisig only

---
 ...rministic Multisignature Wallets.mediawiki | 20 +++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)
 rename Modern Derivation Standard.mediawiki => Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki (80%)

diff --git a/Modern Derivation Standard.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
similarity index 80%
rename from Modern Derivation Standard.mediawiki
rename to Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 61a4fefa..0960fa94 100644
--- a/Modern Derivation Standard.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -1,7 +1,7 @@
 
   BIP: Number not assigned
   Layer: Applications
-  Title: Signature and Script Independant Hierarchy for Deterministic Wallets
+  Title: Modern Hierarchy for Deterministic Multisignature Wallets
   Author: Robert Spigler 
   Comments-Summary: No comments
   Comments-URI:
@@ -16,23 +16,23 @@ This BIP is licensed under the 2-clause BSD license.
 
 ==Abstract==
 
-This BIP defines a sane hierarchy for deterministic 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 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 adoption of new technologies such as [https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md the descriptor language] it is necessary to create a common derivation scheme that makes use of all new technologies.
+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:
+As background, BIP 44/49/84 specifies:
 
 
 m / purpose' / coin_type' / account' / change / address_index
 

 
-where the BIP43 purpose' 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 BIPs are restricted for single sig wallets. This is unecessary, as descriptors handle whether the scripts are single-key or multi-key.
+where the BIP43 purpose' 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 shouldn't be reused for multisig).
 
-Modification is also needed for multisig derivation paths.  For example, BIP45 specifies:
+Standardization is needed for multisig derivation paths.  There are some in existence, but all have issues.  For example, BIP45 specifies:
 
 
 m / purpose' / cosigner_index / change / address_index
@@ -48,7 +48,7 @@ m / purpose' / coin_type' / account' / script_type' / change / address_index
 
 Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert script_type' 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 later in this paper solves these issues and is quite comprehensive. It allows the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, regardless of the script or signature type.
+The structure proposed later in this paper solves these issues and is quite comprehensive. It allows the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, in a multi-party multisignature hierarchical deterministic wallet regardless of the script type.
 
 Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.
 
@@ -60,7 +60,7 @@ Any wallet that supports descriptors inherently supports deterministic key sorti
 
 ==Path levels==
 
-We should not be mixing keys and scripts in the same layer. The wallet should create extended private/public keys independent of the script or signature type, whereas the descriptor language tells wallets to watch (single or multi-sig) outputs with the specified public keys.
+We should not be mixing keys and scripts in the same layer. The wallet should create extended private/public keys independent of the script type, whereas the descriptor language tells wallets to watch the multisig outputs with the specified public keys.
 
 We define the following 5 levels in the BIP32 path:
 
@@ -102,8 +102,8 @@ This number is used as child index in BIP32 derivation.
 Hardened derivation is used at this level.
 
 It is crucial that this level is increased for each new wallet joined or private/public keys created; for both privacy and cryptographic purposes.
-For example, in multisignature wallets, before sending a new key record to a coordinator, the wallet must increment the account' level.  Before creating it's own single signature wallet, the account' level must again be incremented.
-This prevents key reuse - across single signature and multisignature wallets, across ECDSA and Schnorr signatures, and inbetween the same wallet types.
+For example, before sending a new key record to a coordinator, the wallet must increment the account' level.
+This prevents key reuse - across ECDSA and Schnorr signatures, across different script types, and inbetween the same wallet types.
 
 ===Change===
 

From b4af07c8a7f10fb28e6c5233d603310cc9db072f Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Thu, 18 Mar 2021 17:16:15 -0400
Subject: [PATCH 07/27] Add PSBT and ML reference

---
 ...ierarchy for Deterministic Multisignature Wallets.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 0960fa94..8ac2888e 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -217,11 +217,12 @@ Public derivation is used at this level.
 
 ==References==
 
-Original mailing list thread: TBD
+Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018630.html
 
 * [[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]]
 

From f4cea61a4edec51c72a965861c0cb63553adf68c Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Thu, 18 Mar 2021 18:00:39 -0400
Subject: [PATCH 08/27] Clarifications

---
 ...rarchy for Deterministic Multisignature Wallets.mediawiki | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 8ac2888e..e69f9cf7 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -30,9 +30,10 @@ As background, BIP 44/49/84 specifies:
 m / purpose' / coin_type' / account' / change / address_index
 

 
-where the BIP43 purpose' 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 shouldn't be reused for multisig).
+where the BIP43 purpose' path is separate for each script (P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively).  Having a script-per-derivation for single sig wallets allows for easy backup and restore, with just the private key information.
 
-Standardization is needed for multisig derivation paths.  There are some in existence, but all have issues.  For example, BIP45 specifies:
+Multisignature wallets need more information to backup and restore, and these per-script derivations are made redundant with descriptors, which describe a collection of output scripts.
+A modern standardization is needed for multisig derivation paths.  There are some in existence, but all have issues.  For example, BIP45 specifies:
 
 
 m / purpose' / cosigner_index / change / address_index

From 73dce7aafce941969ce96da5fe3e64084b3705e6 Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Mon, 22 Mar 2021 00:59:46 -0400
Subject: [PATCH 09/27] BIP2 compliance.  Add rationale, addresss discovery,
 etc.

---
 ...rministic Multisignature Wallets.mediawiki | 53 ++++++++++++++++---
 1 file changed, 46 insertions(+), 7 deletions(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index e69f9cf7..8748762f 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -8,18 +8,19 @@
   Status: Proposed
   Type: Standards Track
   Created: 2020-03-11
+  License: BSD-2-Clause
 

 
-===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.
 
+==Copyright==
+
+This BIP is licensed under the 2-clause BSD license.
+
 ==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.
@@ -49,17 +50,19 @@ m / purpose' / coin_type' / account' / script_type' / change / address_index
 
 Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert script_type' 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 structure proposed later in this paper solves these issues and is quite comprehensive. It allows the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, in a multi-party multisignature hierarchical deterministic wallet regardless of the script type.
+The structure proposed later in this paper solves these issues and is quite comprehensive. It allows the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, in a multi-party multisignature hierarchical deterministic wallet regardless of the script type **Why propose this structure only for multisignature wallets?** Currently, single-sig wallets are able to restore funds using just the master private key data (in the format of BIP39 usually).  Even if the user doesn't recall the derivation used, the wallet implementation can iterate through common schemes (BIP44/49/84).  With this proposed hierarchy, the user would either have to now backup additional data (the descriptor), or the wallet would have to attempt all script types for every account level when restoring.  Because of this, even though the descriptor language handles the signature type just like it does the script type, it is best to restrict this script-agnostic hierarchy to multisignature wallets only. Co-signers in multisignature wallets need to backup all other cosigner public keys anyway in order to restore, so the descriptor provides this information with the benefit of key origin information and error detection..
 
 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==
+==Specification==
+
+===Key sorting===
 
 Any wallet that supports descriptors inherently supports deterministic key sorting as per BIP67 (through the sortedmulti function) so that all possible multisignature addresses/scripts are derived from deterministically sorted public keys.
 
-==Path levels==
+===Path levels===
 
 We should not be mixing keys and scripts in the same layer. The wallet should create extended private/public keys independent of the script type, whereas the descriptor language tells wallets to watch the multisig outputs with the specified public keys.
 
@@ -119,6 +122,37 @@ This number is used as child index in BIP32 derivation.
 
 Public derivation is used at this level.
 
+==Address Discovery==
+
+The multisig descriptor that is generated from the cosigners combined key records should be used to generate and discover addresses. For example:
+wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/*,[xfpForB/XY'/0'/0']XpubB/*))#Checksum
+
+# Derive the wallet's first account's node (index = 0)
+# Derive the external chain node of this account (index = 0)
+# Scan addresses of the external chain; respect the gap limit described below
+# If there are some transactions, increase the account index and go to step 2
+# If no transactions are found on the external chain, continue to search the following account indexes in compliance with the account gap limit described below.
+
+Please note that the algorithm works with the transaction history, not account
+balances, so you can have an account with 0 total coins and the algorithm will
+still continue with discovery.
+
+The wallet implementation should scan the accounts and addresses following the parent descriptor string.
+
+===Address Gap Limit===
+
+Address gap limit is currently set to 20. If the software hits 20 unused addresses in a row, it expects there are no used addresses beyond this point and stops searching the address chain. We scan just the external chains, because internal chains receive only coins that come from the associated external chains.
+
+Wallet software should warn when the user is trying to exceed the gap limit on an external chain by generating a new address.
+
+===Account Gap Limit===
+
+Account gap limit is currently set to 5.  When the software hits an account that contains 20 unused addresses in a row, it will search the the next 4 accounts (while obeying the address gap limit), before stoping discovery.  If any transactions are found during this process, discovery is restarted (after finding 20 unused addresses) on the next account index, and the account gap limit is reset.  Only when the address gap limit is found consecutively for the account gap limit is discovery stopped.
+
+==Rationale==
+
+
+
 ==Examples==
 
 {|
@@ -213,8 +247,13 @@ Public derivation is used at this level.
 |m / XY' / 1' / 1' / 1 / 1
 |}
 
+==Reference Implementation==
+
+None at the moment.
+
 ==Acknowledgement==
 
+Special thanks to SomberNight, Craig Raw, David Harding, Jochen Hoenicke, and others for their feedback on the specification.
 
 ==References==
 

From ba9f775ef6680cc8834e0787c92edd73705cb803 Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Mon, 22 Mar 2021 01:01:55 -0400
Subject: [PATCH 10/27] Formatting

---
 ...Hierarchy for Deterministic Multisignature Wallets.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 8748762f..68eeae01 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -50,7 +50,7 @@ m / purpose' / coin_type' / account' / script_type' / change / address_index
 
 Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert script_type' 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 structure proposed later in this paper solves these issues and is quite comprehensive. It allows the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, in a multi-party multisignature hierarchical deterministic wallet regardless of the script type **Why propose this structure only for multisignature wallets?** Currently, single-sig wallets are able to restore funds using just the master private key data (in the format of BIP39 usually).  Even if the user doesn't recall the derivation used, the wallet implementation can iterate through common schemes (BIP44/49/84).  With this proposed hierarchy, the user would either have to now backup additional data (the descriptor), or the wallet would have to attempt all script types for every account level when restoring.  Because of this, even though the descriptor language handles the signature type just like it does the script type, it is best to restrict this script-agnostic hierarchy to multisignature wallets only. Co-signers in multisignature wallets need to backup all other cosigner public keys anyway in order to restore, so the descriptor provides this information with the benefit of key origin information and error detection..
+The structure proposed later in this paper solves these issues and is quite comprehensive. It allows the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, in a multi-party multisignature hierarchical deterministic wallet regardless of the script type '''Why propose this structure only for multisignature wallets?''' Currently, single-sig wallets are able to restore funds using just the master private key data (in the format of BIP39 usually).  Even if the user doesn't recall the derivation used, the wallet implementation can iterate through common schemes (BIP44/49/84).  With this proposed hierarchy, the user would either have to now backup additional data (the descriptor), or the wallet would have to attempt all script types for every account level when restoring.  Because of this, even though the descriptor language handles the signature type just like it does the script type, it is best to restrict this script-agnostic hierarchy to multisignature wallets only. Co-signers in multisignature wallets need to backup all other cosigner public keys anyway in order to restore, so the descriptor provides this information with the benefit of key origin information and error detection..
 
 Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.
 

From 453d3282659e7fab9fbcfab9e8c09b0c16c861d4 Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Mon, 22 Mar 2021 01:27:52 -0400
Subject: [PATCH 11/27] Grammar/formatting

---
 ...or Deterministic Multisignature Wallets.mediawiki | 12 +++++-------
 1 file changed, 5 insertions(+), 7 deletions(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 68eeae01..b0c8f262 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -124,18 +124,16 @@ Public derivation is used at this level.
 
 ==Address Discovery==
 
-The multisig descriptor that is generated from the cosigners combined key records should be used to generate and discover addresses. For example:
+The multisig descriptor that is generated from the cosigners' combined key records should be used to generate and discover addresses. For example:
 wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/*,[xfpForB/XY'/0'/0']XpubB/*))#Checksum
 
 # Derive the wallet's first account's node (index = 0)
 # Derive the external chain node of this account (index = 0)
 # Scan addresses of the external chain; respect the gap limit described below
-# If there are some transactions, increase the account index and go to step 2
-# If no transactions are found on the external chain, continue to search the following account indexes in compliance with the account gap limit described below.
+# If there are some transactions, increase the account index and go to Step 2
+# If no transactions are found on the external chain, continue to search the following account indices in compliance with the account gap limit described below.
 
-Please note that the algorithm works with the transaction history, not account
-balances, so you can have an account with 0 total coins and the algorithm will
-still continue with discovery.
+Please note that the algorithm works with the transaction history, not account balances, so you can have an account with 0 total coins and the algorithm will still continue with discovery.
 
 The wallet implementation should scan the accounts and addresses following the parent descriptor string.
 
@@ -147,7 +145,7 @@ Wallet software should warn when the user is trying to exceed the gap limit on a
 
 ===Account Gap Limit===
 
-Account gap limit is currently set to 5.  When the software hits an account that contains 20 unused addresses in a row, it will search the the next 4 accounts (while obeying the address gap limit), before stoping discovery.  If any transactions are found during this process, discovery is restarted (after finding 20 unused addresses) on the next account index, and the account gap limit is reset.  Only when the address gap limit is found consecutively for the account gap limit is discovery stopped.
+Account gap limit is currently set to 5.  When the software hits an account that contains 20 unused addresses in a row, it will search the next 4 accounts (while obeying the address gap limit), before stopping discovery.  If any transactions are found during this process, discovery is restarted (after finding 20 unused addresses) on the next account index, and the account gap limit is reset.  Only when the address gap limit is found consecutively for the account gap limit is discovery stopped.
 
 ==Rationale==
 

From b1c2b5c67106196c2c02cc7fca33d6d63bbbe33f Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Mon, 22 Mar 2021 15:27:20 -0400
Subject: [PATCH 12/27] Fix errors

---
 ...rministic Multisignature Wallets.mediawiki | 23 +++++++------------
 1 file changed, 8 insertions(+), 15 deletions(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index b0c8f262..2d1ea5ab 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -23,7 +23,7 @@ This BIP is licensed under the 2-clause BSD license.
 
 ==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.
+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.
 
 As background, BIP 44/49/84 specifies:
 
@@ -33,7 +33,7 @@ m / purpose' / coin_type' / account' / change / address_index
 
 where the BIP43 purpose' path is separate for each script (P2PKH, P2WPKH-in-P2SH, and P2WPKH respectively).  Having a script-per-derivation for single sig wallets allows for easy backup and restore, with just the private key information.
 
-Multisignature wallets need more information to backup and restore, and these per-script derivations are made redundant with descriptors, which describe a collection of output scripts.
+Multisignature wallets need more information to backup and restore (such as all cosigner public keys), and these per-script derivations are made redundant with descriptors, which provide that information (while also specifying a collection of output scripts).
 A modern standardization is needed for multisig derivation paths.  There are some in existence, but all have issues.  For example, BIP45 specifies:
 
 
@@ -100,7 +100,7 @@ This level splits the key space into independent user identities, following the
 
 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.
+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.
@@ -111,13 +111,13 @@ This prevents key reuse - across ECDSA and Schnorr signatures, across different
 
 ===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.
+Constant  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.
+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.
@@ -127,15 +127,12 @@ Public derivation is used at this level.
 The multisig descriptor that is generated from the cosigners' combined key records should be used to generate and discover addresses. For example:
 wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/*,[xfpForB/XY'/0'/0']XpubB/*))#Checksum
 
-# Derive the wallet's first account's node (index = 0)
-# Derive the external chain node of this account (index = 0)
+# Derive the external chain node of this account (constant = 0)
 # Scan addresses of the external chain; respect the gap limit described below
-# If there are some transactions, increase the account index and go to Step 2
-# If no transactions are found on the external chain, continue to search the following account indices in compliance with the account gap limit described below.
 
-Please note that the algorithm works with the transaction history, not account balances, so you can have an account with 0 total coins and the algorithm will still continue with discovery.
+Please note that the algorithm works with the transaction history, not account balances, so you can have an address with 0 total coins and the algorithm will still continue with discovery.
 
-The wallet implementation should scan the accounts and addresses following the parent descriptor string.
+The wallet implementation should scan the addresses following the parent descriptor string.
 
 ===Address Gap Limit===
 
@@ -143,10 +140,6 @@ Address gap limit is currently set to 20. If the software hits 20 unused address
 
 Wallet software should warn when the user is trying to exceed the gap limit on an external chain by generating a new address.
 
-===Account Gap Limit===
-
-Account gap limit is currently set to 5.  When the software hits an account that contains 20 unused addresses in a row, it will search the next 4 accounts (while obeying the address gap limit), before stopping discovery.  If any transactions are found during this process, discovery is restarted (after finding 20 unused addresses) on the next account index, and the account gap limit is reset.  Only when the address gap limit is found consecutively for the account gap limit is discovery stopped.
-
 ==Rationale==
 
 

From c7cd5e990b82c9f788afa9239fd1495fbd0ef066 Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Mon, 22 Mar 2021 15:34:18 -0400
Subject: [PATCH 13/27] Formatting

---
 ...Hierarchy for Deterministic Multisignature Wallets.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 2d1ea5ab..0bf6734e 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -111,7 +111,7 @@ This prevents key reuse - across ECDSA and Schnorr signatures, across different
 
 ===Change===
 
-Constant  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.
+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.
 

From d95aa3329d87c1081d0f3ffdd1179f96ead44bdc Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Mon, 19 Apr 2021 18:03:24 -0400
Subject: [PATCH 14/27] Update Modern Hierarchy for Deterministic
 Multisignature Wallets.mediawiki

Some minor fixes, address gap fixes, backup clarification
---
 ...rministic Multisignature Wallets.mediawiki | 24 ++++++++++++-------
 1 file changed, 15 insertions(+), 9 deletions(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 0bf6734e..391b88a2 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -40,7 +40,7 @@ A modern standardization is needed for multisig derivation paths.  There are som
 m / purpose' / cosigner_index / change / address_index
 

 
-Like BIP44/49/84, BIP45 unecessarily demands a single script type (here, P2SH).  In addition, BIP45 sets cosigner_index in order to sort the purpose' public keys of each cosigner.  This too is redundant, as descriptors can set the order of the public keys with multi or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with sortedmulti.  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.
+BIP45 unecessarily demands a single script type (here, P2SH).  In addition, BIP45 sets cosigner_index in order to sort the purpose' public keys of each cosigner.  This too is redundant, as descriptors can set the order of the public keys with multi or have them sorted lexicographically (as described in [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP67]) with sortedmulti.  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.
 
 The second multisignature "standard" in use is m/48', which specifies:
 
@@ -50,7 +50,7 @@ m / purpose' / coin_type' / account' / script_type' / change / address_index
 
 Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert script_type' 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 structure proposed later in this paper solves these issues and is quite comprehensive. It allows the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, in a multi-party multisignature hierarchical deterministic wallet regardless of the script type '''Why propose this structure only for multisignature wallets?''' Currently, single-sig wallets are able to restore funds using just the master private key data (in the format of BIP39 usually).  Even if the user doesn't recall the derivation used, the wallet implementation can iterate through common schemes (BIP44/49/84).  With this proposed hierarchy, the user would either have to now backup additional data (the descriptor), or the wallet would have to attempt all script types for every account level when restoring.  Because of this, even though the descriptor language handles the signature type just like it does the script type, it is best to restrict this script-agnostic hierarchy to multisignature wallets only. Co-signers in multisignature wallets need to backup all other cosigner public keys anyway in order to restore, so the descriptor provides this information with the benefit of key origin information and error detection..
+The structure proposed later in this paper solves these issues and is quite comprehensive. It allows for the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, in a multi-party, multisignature, hierarchical deterministic wallet regardless of the script type '''Why propose this structure only for multisignature wallets?''' Currently, single-sig wallets are able to restore funds using just the master private key data (in the format of BIP39 usually).  Even if the user doesn't recall the derivation used, the wallet implementation can iterate through common schemes (BIP44/49/84).  With this proposed hierarchy, the user would either have to now backup additional data (the descriptor), or the wallet would have to attempt all script types for every account level when restoring.  Because of this, even though the descriptor language handles the signature type just like it does the script type, it is best to restrict this script-agnostic hierarchy to multisignature wallets only. Co-signers in multisignature wallets need to backup all other cosigner public keys anyway in order to restore, so the descriptor provides this information with the benefit of key origin information and error detection..
 
 Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.
 
@@ -124,15 +124,21 @@ Public derivation is used at this level.
 
 ==Address Discovery==
 
-The multisig descriptor that is generated from the cosigners' combined key records should be used to generate and discover addresses. For example:
-wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/*,[xfpForB/XY'/0'/0']XpubB/*))#Checksum
+The multisig descriptors or descriptor template that is generated from the cosigners' combined key records should be used to generate and discover addresses. 
+
+For example:
+
+The following descriptor template and derivation path:
+wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/**,[xfpForB/XY'/0'/0']XpubB/**))
+/0/*,/1/*
+
+Expands to the two concrete descriptors:
+wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/0/*,[xfpForB/XY'/0'/0']XpubB/0/*))#Checksum
+wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))#Checksum
 
-# Derive the external chain node of this account (constant = 0)
 # Scan addresses of the external chain; respect the gap limit described below
 
-Please note that the algorithm works with the transaction history, not account balances, so you can have an address with 0 total coins and the algorithm will still continue with discovery.
-
-The wallet implementation should scan the addresses following the parent descriptor string.
+Note: This therefore necessitates that multisig wallets backup their private key information and their descriptor, in order to properly restore at a later time.  This shouldn't be a user burden, since (to much user surprise), all cosigner public keys need to be supplied in addition to M seeds in any M of N multisig restore operation. The descriptor provides this information in a standardized format, with key origin information and error detection.
 
 ===Address Gap Limit===
 
@@ -244,7 +250,7 @@ None at the moment.
 
 ==Acknowledgement==
 
-Special thanks to SomberNight, Craig Raw, David Harding, Jochen Hoenicke, and others for their feedback on the specification.
+Special thanks to SomberNight, Craig Raw, David Harding, Jochen Hoenicke, Sjors Provoost, and others for their feedback on the specification.
 
 ==References==
 

From 25bacdc21d897e289d2d12640b702f83bca59905 Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Mon, 19 Apr 2021 18:08:52 -0400
Subject: [PATCH 15/27] Update Modern Hierarchy for Deterministic
 Multisignature Wallets.mediawiki

Fix formatting
---
 ...erarchy for Deterministic Multisignature Wallets.mediawiki | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 391b88a2..6be0a65d 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -129,14 +129,16 @@ The multisig descriptors or descriptor template that is generated from the cosig
 For example:
 
 The following descriptor template and derivation path:
+
 wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/**,[xfpForB/XY'/0'/0']XpubB/**))
 /0/*,/1/*
 
 Expands to the two concrete descriptors:
+
 wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/0/*,[xfpForB/XY'/0'/0']XpubB/0/*))#Checksum
 wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))#Checksum
 
-# Scan addresses of the external chain; respect the gap limit described below
+To discover addresses, scan addresses of the external chain; respect the gap limit described below
 
 Note: This therefore necessitates that multisig wallets backup their private key information and their descriptor, in order to properly restore at a later time.  This shouldn't be a user burden, since (to much user surprise), all cosigner public keys need to be supplied in addition to M seeds in any M of N multisig restore operation. The descriptor provides this information in a standardized format, with key origin information and error detection.
 

From f18ddfbfa5d44a3f4432844c34b6d954a6a022b7 Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Mon, 19 Apr 2021 18:09:59 -0400
Subject: [PATCH 16/27] Update Modern Hierarchy for Deterministic
 Multisignature Wallets.mediawiki

Formatting
---
 ...Hierarchy for Deterministic Multisignature Wallets.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 6be0a65d..2783cea5 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -131,11 +131,13 @@ For example:
 The following descriptor template and derivation path:
 
 wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/**,[xfpForB/XY'/0'/0']XpubB/**))
+
 /0/*,/1/*
 
 Expands to the two concrete descriptors:
 
 wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/0/*,[xfpForB/XY'/0'/0']XpubB/0/*))#Checksum
+
 wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))#Checksum
 
 To discover addresses, scan addresses of the external chain; respect the gap limit described below

From ccc8af43b076de2e4ad669ccd58dead4684c6ed2 Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Wed, 21 Apr 2021 15:13:23 -0400
Subject: [PATCH 17/27] Address Discovery Fixes

---
 ...erarchy for Deterministic Multisignature Wallets.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 2783cea5..b6079336 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -140,13 +140,13 @@ Expands to the two concrete descriptors:
 
 wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))#Checksum
 
-To discover addresses, scan addresses of the external chain; respect the gap limit described below
+To discover addresses, import both the receiving and change descriptors; respect the gap limit described below.
 
 Note: This therefore necessitates that multisig wallets backup their private key information and their descriptor, in order to properly restore at a later time.  This shouldn't be a user burden, since (to much user surprise), all cosigner public keys need to be supplied in addition to M seeds in any M of N multisig restore operation. The descriptor provides this information in a standardized format, with key origin information and error detection.
 
 ===Address Gap Limit===
 
-Address gap limit is currently set to 20. If the software hits 20 unused addresses in a row, it expects there are no used addresses beyond this point and stops searching the address chain. We scan just the external chains, because internal chains receive only coins that come from the associated external chains.
+Address gap limit is currently set to 20. If the software hits 20 unused addresses in a row, it expects there are no used addresses beyond this point and stops searching the address chain.
 
 Wallet software should warn when the user is trying to exceed the gap limit on an external chain by generating a new address.
 

From 7ae9e025e809a870c1d1c9077c2ebc4515734365 Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Sun, 25 Apr 2021 23:52:46 -0400
Subject: [PATCH 18/27] Minor edits, + backwards compatibility

---
 ...eterministic Multisignature Wallets.mediawiki | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index b6079336..ff3ca9ab 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -50,9 +50,7 @@ m / purpose' / coin_type' / account' / script_type' / change / address_index
 
 Rather than following in BIP 44/49/84's path and having a separate BIP per script after P2SH (BIP45), vendors decided to insert script_type' 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 structure proposed later in this paper solves these issues and is quite comprehensive. It allows for the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, in a multi-party, multisignature, hierarchical deterministic wallet regardless of the script type '''Why propose this structure only for multisignature wallets?''' Currently, single-sig wallets are able to restore funds using just the master private key data (in the format of BIP39 usually).  Even if the user doesn't recall the derivation used, the wallet implementation can iterate through common schemes (BIP44/49/84).  With this proposed hierarchy, the user would either have to now backup additional data (the descriptor), or the wallet would have to attempt all script types for every account level when restoring.  Because of this, even though the descriptor language handles the signature type just like it does the script type, it is best to restrict this script-agnostic hierarchy to multisignature wallets only. Co-signers in multisignature wallets need to backup all other cosigner public keys anyway in order to restore, so the descriptor provides this information with the benefit of key origin information and error detection..
-
-Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.
+The structure proposed later in this paper solves these issues and is quite comprehensive. It allows for the handling of multiple accounts, external and internal chains per account, and millions of addresses per chain, in a multi-party, multisignature, hierarchical deterministic wallet regardless of the script type '''Why propose this structure only for multisignature wallets?''' Currently, single-sig wallets are able to restore funds using just the master private key data (in the format of BIP39 usually).  Even if the user doesn't recall the derivation used, the wallet implementation can iterate through common schemes (BIP44/49/84).  With this proposed hierarchy, the user would either have to now backup additional data (the descriptor), or the wallet would have to attempt all script types for every account level when restoring.  Because of this, even though the descriptor language handles the signature type just like it does the script type, it is best to restrict this script-agnostic hierarchy to multisignature wallets only..
 
 This paper was inspired from BIP44.
 
@@ -128,7 +126,7 @@ The multisig descriptors or descriptor template that is generated from the cosig
 
 For example:
 
-The following descriptor template and derivation path:
+The following descriptor template and derivation path restrictions:
 
 wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/**,[xfpForB/XY'/0'/0']XpubB/**))
 
@@ -142,13 +140,17 @@ Expands to the two concrete descriptors:
 
 To discover addresses, import both the receiving and change descriptors; respect the gap limit described below.
 
-Note: This therefore necessitates that multisig wallets backup their private key information and their descriptor, in order to properly restore at a later time.  This shouldn't be a user burden, since (to much user surprise), all cosigner public keys need to be supplied in addition to M seeds in any M of N multisig restore operation. The descriptor provides this information in a standardized format, with key origin information and error detection.
-
 ===Address Gap Limit===
 
 Address gap limit is currently set to 20. If the software hits 20 unused addresses in a row, it expects there are no used addresses beyond this point and stops searching the address chain.
 
-Wallet software should warn when the user is trying to exceed the gap limit on an external chain by generating a new address.
+Wallet software should warn when the user is trying to exceed the gap limit on an external descriptor by generating multiple unused addresses.
+
+==Backwards Compatibility==
+
+Any script that is supported by descriptors (and the specific wallet implementation) is compatible with this BIP.
+
+As wallets complying with this BIP are descriptor wallets, this therefore necessitates that the cosigners backup their private key information and the descriptor, in order to properly restore at a later time.  This shouldn't be a user burden, since (to much user surprise), all cosigner public keys need to be supplied in addition to M seeds in any M of N multisig restore operation. The descriptor provides this information in a standardized format, with key origin information and error detection.
 
 ==Rationale==
 

From 653b965f15c1d3bb9aad654488402c69588fd61d Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Mon, 26 Apr 2021 14:55:39 -0400
Subject: [PATCH 19/27] Add BSMS reference and key origin info

---
 ... for Deterministic Multisignature Wallets.mediawiki | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index ff3ca9ab..88dd46fa 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -122,7 +122,9 @@ Public derivation is used at this level.
 
 ==Address Discovery==
 
-The multisig descriptors or descriptor template that is generated from the cosigners' combined key records should be used to generate and discover addresses. 
+The multisig descriptors or descriptor template that is generated from the cosigners' combined key records should be used to generate and discover addresses.
+
+Please see BIP__ (Bitcoin Secure Multisig Setup) for an introduction on descriptor templates.  [Waiting for merge of BSMS to link here].  The descriptor or descriptor template should contain the key origin information for maximum compatibility with BIP-0174.
 
 For example:
 
@@ -134,9 +136,9 @@ The following descriptor template and derivation path restrictions:
 
 Expands to the two concrete descriptors:
 
-wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/0/*,[xfpForB/XY'/0'/0']XpubB/0/*))#Checksum
+wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/0/*,[xfpForB/XY'/0'/0']XpubB/0/*))
 
-wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))#Checksum
+wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))
 
 To discover addresses, import both the receiving and change descriptors; respect the gap limit described below.
 
@@ -268,4 +270,4 @@ Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoi
 * [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]]
-
+* Bitcoin Secure Multisig Setup [Waiting For Merge]

From cd223ea64aa9305e5cca214a71e3972813b70de6 Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Fri, 14 May 2021 23:36:00 -0400
Subject: [PATCH 20/27] BIP 87 assigned

---
 ...archy for Deterministic Multisignature Wallets.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
 rename Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki => BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki (98%)

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
similarity index 98%
rename from Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
rename to BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 88dd46fa..f9be499d 100644
--- a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
+++ b/BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki	
@@ -1,10 +1,10 @@
 
-  BIP: Number not assigned
+  BIP: 87
   Layer: Applications
   Title: Modern Hierarchy for Deterministic Multisignature Wallets
   Author: Robert Spigler 
-  Comments-Summary: No comments
-  Comments-URI:
+  Comments-Summary: No comments yet.
+  Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0087
   Status: Proposed
   Type: Standards Track
   Created: 2020-03-11

From 10e4bc6668ec4fdc0e6959da043b0f8e354c4da7 Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Fri, 14 May 2021 23:49:08 -0400
Subject: [PATCH 21/27] Update README.mediawiki

---
 README.mediawiki | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/README.mediawiki b/README.mediawiki
index 5ab74997..34cf7404 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -435,6 +435,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Informational
 | Draft
 |- style="background-color: #cfffcf"
+| [[bip-0087.mediawiki|87]]
+| Applications
+| Modern Hierarchy for Deterministic Multisignature Wallets
+| Robert Spigler
+| Standard
+| Proposed
+|-
 | [[bip-0090.mediawiki|90]]
 |
 | Buried Deployments

From 7e10290920a8e609f1fed52b1c953a8fe7e6ad41 Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Fri, 14 May 2021 23:55:43 -0400
Subject: [PATCH 22/27] Rename BIP 87: Modern Hierarchy for Deterministic
 Multisignature Wallets.mediawiki to bip-0087.mediawiki

---
 ...inistic Multisignature Wallets.mediawiki => bip-0087.mediawiki | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki => bip-0087.mediawiki (100%)

diff --git a/BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/bip-0087.mediawiki
similarity index 100%
rename from BIP 87: Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
rename to bip-0087.mediawiki

From 9c40c18dbe8e01da8a9f1786fe845f5aed70fa06 Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Sat, 15 May 2021 00:55:41 -0400
Subject: [PATCH 23/27] Link to merged BSMS, update examples

---
 bip-0087.mediawiki | 33 +++++++++++++++++----------------
 1 file changed, 17 insertions(+), 16 deletions(-)

diff --git a/bip-0087.mediawiki b/bip-0087.mediawiki
index f9be499d..53f2849e 100644
--- a/bip-0087.mediawiki
+++ b/bip-0087.mediawiki
@@ -1,7 +1,7 @@
 
   BIP: 87
   Layer: Applications
-  Title: Modern Hierarchy for Deterministic Multisignature Wallets
+  Title: Hierarchy for Deterministic Multisig Wallets
   Author: Robert Spigler 
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0087
@@ -124,7 +124,8 @@ Public derivation is used at this level.
 
 The multisig descriptors or descriptor template that is generated from the cosigners' combined key records should be used to generate and discover addresses.
 
-Please see BIP__ (Bitcoin Secure Multisig Setup) for an introduction on descriptor templates.  [Waiting for merge of BSMS to link here].  The descriptor or descriptor template should contain the key origin information for maximum compatibility with BIP-0174.
+Please see [https://github.com/bitcoin/bips/blob/master/bip-0129.mediawiki BIP-0129 (Bitcoin Secure Multisig Setup)] for an introduction on descriptor templates.
+The descriptor or descriptor template should contain the key origin information for maximum compatibility with BIP-0174.
 
 For example:
 
@@ -171,43 +172,43 @@ As wallets complying with this BIP are descriptor wallets, this therefore necess
 |first
 |external
 |first
-|m / XY' / 0' / 0' / 0 / 0
+|m / 87' / 0' / 0' / 0 / 0
 |-
 |mainnet
 |first
 |external
 |second
-|m / XY' / 0' / 0' / 0 / 1
+|m / 87' / 0' / 0' / 0 / 1
 |-
 |mainnet
 |first
 |change
 |first
-|m / XY' / 0' / 0' / 1 / 0
+|m / 87' / 0' / 0' / 1 / 0
 |-
 |mainnet
 |first
 |change
 |second
-|m / XY' / 0' / 0' / 1 / 1
+|m / 87' / 0' / 0' / 1 / 1
 |-
 |mainnet
 |second
 |external
 |first
-|m / XY' / 0' / 1' / 0 / 0
+|m / 87' / 0' / 1' / 0 / 0
 |-
 |mainnet
 |second
 |external
 |second
-|m / XY' / 0' / 1' / 0 / 1
+|m / 87' / 0' / 1' / 0 / 1
 |-
 |testnet
 |first
 |external
 |first
-|m / XY' / 1' / 0' / 0 / 0
+|m / 87' / 1' / 0' / 0 / 0
 |-
 |testnet
 |first
@@ -219,37 +220,37 @@ As wallets complying with this BIP are descriptor wallets, this therefore necess
 |first
 |change
 |first
-|m / XY' / 1' / 0' / 1 / 0
+|m / 87' / 1' / 0' / 1 / 0
 |-
 |testnet
 |first
 |change
 |second
-|m / XY' / 1' / 0' / 1 / 1
+|m / 87' / 1' / 0' / 1 / 1
 |-
 |testnet
 |second
 |external
 |first
-|m / XY' / 1' / 1' / 0 / 0
+|m / 87' / 1' / 1' / 0 / 0
 |-
 |testnet
 |second
 |external
 |second
-|m / XY' / 1' / 1' / 0 / 1
+|m / 87' / 1' / 1' / 0 / 1
 |-
 |testnet
 |second
 |change
 |first
-|m / XY' / 1' / 1' / 1 / 0
+|m / 87' / 1' / 1' / 1 / 0
 |-
 |testnet
 |second
 |change
 |second
-|m / XY' / 1' / 1' / 1 / 1
+|m / 87' / 1' / 1' / 1 / 1
 |}
 
 ==Reference Implementation==
@@ -270,4 +271,4 @@ Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoi
 * [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]]
-* Bitcoin Secure Multisig Setup [Waiting For Merge]
+* [[bip-0129.mediawiki|BIP129 - Bitcoin Secure Multisig Setup (BSMS)]]

From 7663693310cc3a42aacc8e8406480ab47cd35a62 Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Sat, 15 May 2021 00:57:54 -0400
Subject: [PATCH 24/27] Change name for CI

---
 README.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.mediawiki b/README.mediawiki
index 3d4abfef..dba93f31 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -437,7 +437,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 |- style="background-color: #cfffcf"
 | [[bip-0087.mediawiki|87]]
 | Applications
-| Modern Hierarchy for Deterministic Multisignature Wallets
+| Hierarchy for Deterministic Multisig Wallets
 | Robert Spigler
 | Standard
 | Proposed

From d502f681b8f796c7c9e5523be16f855aa58797ab Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Sat, 15 May 2021 01:15:09 -0400
Subject: [PATCH 25/27] Minor edits and links

---
 bip-0087.mediawiki | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/bip-0087.mediawiki b/bip-0087.mediawiki
index 53f2849e..57d5efeb 100644
--- a/bip-0087.mediawiki
+++ b/bip-0087.mediawiki
@@ -76,7 +76,7 @@ Each level has a special meaning, described in the chapters below.
 
 ===Purpose===
 
-Purpose is a constant set to XY' following the BIP43 recommendation.
+Purpose is a constant set to 87' 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.
@@ -131,15 +131,15 @@ For example:
 
 The following descriptor template and derivation path restrictions:
 
-wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/**,[xfpForB/XY'/0'/0']XpubB/**))
+wsh(sortedmulti(2,[xfpForA/87'/0'/0']XpubA/**,[xfpForB/87'/0'/0']XpubB/**))
 
 /0/*,/1/*
 
 Expands to the two concrete descriptors:
 
-wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/0/*,[xfpForB/XY'/0'/0']XpubB/0/*))
+wsh(sortedmulti(2,[xfpForA/87'/0'/0']XpubA/0/*,[xfpForB/87'/0'/0']XpubB/0/*))
 
-wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))
+wsh(sortedmulti(2,[xfpForA/87'/0'/0']XpubA/1/*,[xfpForB/87'/0'/0']XpubB/1/*))
 
 To discover addresses, import both the receiving and change descriptors; respect the gap limit described below.
 
@@ -214,7 +214,7 @@ As wallets complying with this BIP are descriptor wallets, this therefore necess
 |first
 |external
 |second
-|m / XY' / 1' / 0' / 0 / 1
+|m / 87' / 1' / 0' / 0 / 1
 |-
 |testnet
 |first
@@ -265,10 +265,10 @@ Special thanks to SomberNight, Craig Raw, David Harding, Jochen Hoenicke, Sjors
 
 Original mailing list thread: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018630.html
 
-* [[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/bips/blob/master/bip-0032.mediawiki BIP-0032 (Hierarchical Deterministic Wallets)]
+* [https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki BIP-0043 (Purpose Field for Deterministic Wallets)]
+* [https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki BIP-0044 (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]]
-* [[bip-0129.mediawiki|BIP129 - Bitcoin Secure Multisig Setup (BSMS)]]
+* [https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki BIP-0174 (Partially Signed Bitcoin Transaction Format)]
+* [https://github.com/bitcoin/bips/blob/master/bip-0067.mediawiki BIP-0067 (Deterministic Pay-to-script-hash multi-signature addresses through public key sorting)]
+* [https://github.com/bitcoin/bips/blob/master/bip-0129.mediawiki BIP-0129 (Bitcoin Secure Multisig Setup)]

From 2371906f0268c4edfc9859d2204a8d2bbf1351dc Mon Sep 17 00:00:00 2001
From: Robert Spigler 
Date: Sat, 15 May 2021 01:22:45 -0400
Subject: [PATCH 26/27] Minor edit

---
 bip-0087.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-0087.mediawiki b/bip-0087.mediawiki
index 57d5efeb..d270027e 100644
--- a/bip-0087.mediawiki
+++ b/bip-0087.mediawiki
@@ -76,7 +76,7 @@ Each level has a special meaning, described in the chapters below.
 
 ===Purpose===
 
-Purpose is a constant set to 87' following the BIP43 recommendation.
+Purpose is a constant set to 87' 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.

From eb7ab7ab414710bb8a57c78deca69cdaa51839db Mon Sep 17 00:00:00 2001
From: Luke Dashjr 
Date: Mon, 17 May 2021 23:28:17 +0000
Subject: [PATCH 27/27] README: Fix colours for BIPs 87 & 90

---
 README.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.mediawiki b/README.mediawiki
index dba93f31..a3956c0c 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -434,14 +434,14 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Ethan Kosakovsky
 | Informational
 | Draft
-|- style="background-color: #cfffcf"
+|- style="background-color: #ffffcf"
 | [[bip-0087.mediawiki|87]]
 | Applications
 | Hierarchy for Deterministic Multisig Wallets
 | Robert Spigler
 | Standard
 | Proposed
-|-
+|- style="background-color: #cfffcf"
 | [[bip-0090.mediawiki|90]]
 |
 | Buried Deployments