summaryrefslogtreecommitdiff
path: root/bip-0087.mediawiki
diff options
context:
space:
mode:
authorAlexander Cyon <alex.cyon@gmail.com>2024-05-28 19:25:46 +0200
committerAlexander Cyon <alex.cyon@gmail.com>2024-05-28 19:25:46 +0200
commit1eefea0456d661b4c51f3a40b7262d6a99161edd (patch)
tree4f84740d22e4220a8c0488e1932d6ee8b3841547 /bip-0087.mediawiki
parente2f7481a132e1c5863f5ffcbff009964d7c2af20 (diff)
downloadbips-1eefea0456d661b4c51f3a40b7262d6a99161edd.tar.xz
Fix typos on 17 files.
Diffstat (limited to 'bip-0087.mediawiki')
-rw-r--r--bip-0087.mediawiki2
1 files changed, 1 insertions, 1 deletions
diff --git a/bip-0087.mediawiki b/bip-0087.mediawiki
index 308e852..920bd3c 100644
--- a/bip-0087.mediawiki
+++ b/bip-0087.mediawiki
@@ -48,7 +48,7 @@ The second multisignature "standard" in use is m/48', which specifies:
m / purpose' / coin_type' / account' / script_type' / change / address_index
</pre>
-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.
+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 maintenance 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.</ref>.