From ba9f775ef6680cc8834e0787c92edd73705cb803 Mon Sep 17 00:00:00 2001 From: Robert Spigler Date: Mon, 22 Mar 2021 01:01:55 -0400 Subject: [PATCH] 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 8748762f73..68eeae0101 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.