Minor edits, + backwards compatibility

Author: Robert Spigler

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 <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 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.
+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.</ref>.
 
 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:
 
 <code>wsh(sortedmulti(2,[xfpForA/XY'/0'/0']XpubA/**,[xfpForB/XY'/0'/0']XpubB/**))</code>
 
@@ -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 <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===
 
 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 <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.
 
 ==Rationale==