Update Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki

Some minor fixes, address gap fixes, backup clarification

1 files changed, 15 insertions, 9 deletions

diff --git a/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki b/Modern Hierarchy for Deterministic Multisignature Wallets.mediawiki
index 0bf6734..391b88a 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
 </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.
+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.
 
 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 <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, <code>script_type</code> 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 <ref>'''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.</ref>.
+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 <ref>'''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.</ref>.
 
 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:
-<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/*,[xfpForB/XY'/0'/0']XpubB/*))#Checksum</code>
+The multisig descriptors or descriptor template that is generated from the cosigners' combined key records should be used to generate and discover addresses. 
 
-# Derive the external chain node of this account (constant = 0)
-# Scan addresses of the external chain; respect the gap limit described below
+For example:
+
+The following descriptor template and derivation path:
+<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/**,[xfpForB/XY'/0'/0']XpubB/**))</code>
+<code>/0/*,/1/*</code>
 
-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.
+Expands to the two concrete descriptors:
+<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/0/*,[xfpForB/XY'/0'/0']XpubB/0/*))#Checksum</code>
+<code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/1/*,[xfpForB/XY'/0'/0']XpubB/1/*))#Checksum</code>
+
+# Scan addresses of the external chain; respect the gap limit described below
 
-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 <code>M</code> seeds in any <code>M</code> of <code>N</code> 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==