Fix typos on 17 files.

Author: Sajjon

bip-0015.mediawiki

@@ -208,7 +208,7 @@ NameResolutionService::~NameResolutionService()
 
 void NameResolutionService::ExplodeHandle(const string& strHandle, string& strNickname, string& strDomain)
 {
-    // split address at @ furthrest to the right
+    // split address at @ furthest to the right
     size_t nPosAtsym = strHandle.rfind('@');
     strNickname = strHandle.substr(0, nPosAtsym);
     strDomain = strHandle.substr(nPosAtsym + 1, strHandle.size());

bip-0047.mediawiki

@@ -275,7 +275,7 @@ Normal operation of a payment code-enabled wallet can be performed by an SPV cli
 
 Recovering a wallet from a seed, however, does require access to a fully-indexed blockchain.
 
-The required data may be obtained from copy of the blockchain under the control of the user, or via a publicly-queriable blockchain explorer.
+The required data may be obtained from copy of the blockchain under the control of the user, or via a publicly-queryable blockchain explorer.
 
 When querying a public blockchain explorer, wallets SHOULD connect to the explorer through Tor (or equivalent) and SHOULD avoid grouping queries in a manner that associates ephemeral addresses with each other.
 

bip-0049.mediawiki

@@ -92,10 +92,10 @@ This BIP is not backwards compatible by design as described under [[#considerati
   // Account 0, first receiving private key = m/49'/1'/0'/0/0
   account0recvPrivateKey = cULrpoZGXiuC19Uhvykx7NugygA3k86b3hmdCeyvHYQZSxojGyXJ
   account0recvPrivateKeyHex = 0xc9bdb49cfbaedca21c4b1f3a7803c34636b1d7dc55a717132443fc3f4c5867e8
-  account0recvPublickKeyHex = 0x03a1af804ac108a8a51782198c2d034b28bf90c8803f5a53f76276fa69a4eae77f
+  account0recvPublicKeyHex = 0x03a1af804ac108a8a51782198c2d034b28bf90c8803f5a53f76276fa69a4eae77f
 
   // Address derivation
-  keyhash = HASH160(account0recvPublickKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3
+  keyhash = HASH160(account0recvPublicKeyHex) = 0x38971f73930f6c141d977ac4fd4a727c854935b3
   scriptSig = <0 <keyhash>> = 0x001438971f73930f6c141d977ac4fd4a727c854935b3
   addressBytes = HASH160(scriptSig) = 0x336caa13e08b96080a32b5d818d59b4ab3b36742
 

bip-0085.mediawiki

@@ -364,7 +364,7 @@ This specification relies on BIP32 but is agnostic to how the BIP32 root key is
 
 ==Discussion==
 
-The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (''k'') be compromized. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also, from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This is done out of an abundance of caution, in order to ward off unwanted side effects should ''k'' be used for a dual purpose, including as a nonce ''hash(k)'', where undesirable and unforeseen interactions could occur.
+The reason for running the derived key through HMAC-SHA512 and truncating the result as necessary is to prevent leakage of the parent tree should the derived key (''k'') be compromised. While the specification requires the use of hardended key derivation which would prevent this, we cannot enforce hardened derivation, so this method ensures the derived entropy is hardened. Also, from a semantic point of view, since the purpose is to derive entropy and not a private key, we are required to transform the child key. This is done out of an abundance of caution, in order to ward off unwanted side effects should ''k'' be used for a dual purpose, including as a nonce ''hash(k)'', where undesirable and unforeseen interactions could occur.
 
 ==Acknowledgements==
 

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>.
 

bip-0088.mediawiki

@@ -41,7 +41,7 @@ addresses differently than the one they used before.
 The problem is common enough to warrant the creation of a dedicated website
 ([https://walletsrecovery.org/ walletsrecovery.org]) that tracks paths used by different wallets.
 
-At the time of writing, this website has used their own format to succintly describe multiple
+At the time of writing, this website has used their own format to succinctly describe multiple
 derivation paths. As far as author knows, it was the only publicitly used format to describe
 path templates before introduction of this BIP. The format was not specified anywhere beside
 the main page of the website. It used <code>|</code> to denote alternative derivation indexes
@@ -52,7 +52,7 @@ an ad-hoc format only intended for illustration. In contrast to this ad-hoc form
 described in this BIP is intended for unambigouos parsing by software, and to be easily read by humans
 at the same time. Humans can visually detect the 'templated' parts of the path more easily than the use
 of <code>|</code> in the template could allow. Wider range of paths can be defined in a single template more
-succintly and unambiguously.
+succinctly and unambiguously.
 
 ===Intended use and advantages===
 
@@ -71,7 +71,7 @@ into using well-known paths, or convince other vendors to support their custom p
 scales poorly.
 
 A flexible approach proposed in this document is to define a standard notation for "BIP32 path templates"
-that succintly describes the constraints to impose on the derivation path.
+that succinctly describes the constraints to impose on the derivation path.
 
 Wide support for these path templates will increase interoperability and flexibility of solutions,
 and will allow vendors and individual developers to easily define their own custom restrictions.
@@ -89,7 +89,7 @@ installation of malicious or incorrect profiles, though.
 
 ==Specification==
 
-The format for the template was chosen to make it easy to read, convenient and visually unambigous. 
+The format for the template was chosen to make it easy to read, convenient and visually unambiguous. 
 
 Template starts with optional prefix <code>m/</code>, and then one or more sections delimited by the slash character (<code>/</code>).
 

bip-0098.mediawiki

@@ -241,16 +241,16 @@ Disallowing a node with two SKIP branches eliminates what would otherwise be a s
 
 The number of hashing operations required to verify a proof is one less than the number of hashes (SKIP and VERIFY combined),
 and is exactly equal to the number of inner nodes serialized as the beginning of the proof as N.
-The variable-length integer encoding has the property that serialized integers, sorted lexigraphically, will also be sorted numerically.
-Since the first serialized item is the number of inner nodes, sorting proofs lexigraphically has the effect of sorting the proofs by the amount of work required to verify.
+The variable-length integer encoding has the property that serialized integers, sorted lexicographically, will also be sorted numerically.
+Since the first serialized item is the number of inner nodes, sorting proofs lexicographically has the effect of sorting the proofs by the amount of work required to verify.
 
 The number of hashes required as input for verification of a proof is N+1 minus the number of SKIP hashes,
 and can be quickly calculated without parsing the tree structure.
 
-The coding and packing rules for the serialized tree structure were also chosen to make lexigraphical comparison useful (or at least not meaningless).
+The coding and packing rules for the serialized tree structure were also chosen to make lexicographical comparison useful (or at least not meaningless).
 If we consider a fully-expanded tree (no SKIP hashes, all VERIFY) to be encoding a list of elements in the order traversed depth-first from left-to-right,
 then we can extract proofs for subsets of the list by SKIP'ing the hashes of missing values and recursively pruning any resulting SKIP,SKIP nodes.
-Lexigraphically comparing the resulting serialized tree structures is the same as lexigraphically comparing lists of indices from the original list verified by the derived proof.
+Lexicographically comparing the resulting serialized tree structures is the same as lexicographically comparing lists of indices from the original list verified by the derived proof.
 
 Because the number of inner nodes and the number of SKIP hashes is extractible from the tree structure,
 both variable-length integers in the proof are redundant and could have been omitted.

bip-0119.mediawiki

@@ -193,7 +193,7 @@ Deployment could be done via BIP 9 VersionBits deployed through Speedy Trial.
 The Bitcoin Core reference implementation includes the below parameters,
 configured to match Speedy Trial, as that is the current activation mechanism
 implemented in Bitcoin Core. Should another method become favored by the wider
-Bitcoin comminity, that might be used instead.
+Bitcoin community, that might be used instead.
 
 The start time and bit in the implementation are currently set to bit 5 and
 NEVER_ACTIVE/NO_TIMEOUT, but this is subject to change while the BIP is a draft.
@@ -314,7 +314,7 @@ We treat the number of inputs as a `uint32_t` because Bitcoin's consensus decodi
 to `MAX_SIZE=33554432` and that is larger than `uint16_t` and smaller than `uint32_t`. 32 bits is also
 friendly for manipulation using Bitcoin's current math opcodes, should `OP_CAT` be added. Note that
 the max inputs in a block is further restricted by the block size to around 25,000, which would fit
-into a `uint16_t`, but that is an uneccessary abstraction leak.
+into a `uint16_t`, but that is an unnecessary abstraction leak.
 
 =====Committing to the Sequences Hash=====
 
@@ -362,7 +362,7 @@ scripts cannot be spent at the same index, which implies that they cannot be spe
 This makes it safer to design wallet vault contracts without half-spend vulnerabilities.
 
 Committing to the current index doesn't prevent one from expressing a CHECKTEMPLATEVERIFY which can
-be spent at multiple indicies. In current script, the CHECKTEMPLATEVERIFY operation can be wrapped
+be spent at multiple indices. In current script, the CHECKTEMPLATEVERIFY operation can be wrapped
 in an OP_IF for each index (or Tapscript branches in the future). If OP_CAT or OP_SHA256STREAM are
 added to Bitcoin, the index may simply be passed in by the witness before hashing.
 
@@ -476,7 +476,7 @@ An example of a script that could experience an DoS issue without caching is:
 
     <H> CTV CTV CTV... CTV
 
-Such a script would cause the intepreter to compute hashes (supposing N CTV's) over O(N*T) data.
+Such a script would cause the interpreter to compute hashes (supposing N CTV's) over O(N*T) data.
 If the scriptSigs non-nullity is not cached, then the O(T) transaction could be scanned over O(N)
 times as well (although cheaper than hashing, still a DoS). As such, CTV caches hashes and computations
 over all variable length fields in a transaction.
@@ -616,7 +616,7 @@ sponsors might be considered.
 
 An opcode which verifies the exact amount that is being spent in the
 transaction, the amount paid as fees, or made available in a given output could
-be used to make safer OP_CHECKTEMPLATEVERIFY addressses. For instance, if the
+be used to make safer OP_CHECKTEMPLATEVERIFY addresses. For instance, if the
 OP_CHECKTEMPLATEVERIFY program P expects exactly S satoshis, sending S-1
 satoshis would result in a frozen UTXO and sending S+n satoshis would result in
 n satoshis being paid to fee. A range check could restrict the program to only

bip-0137.mediawiki

@@ -15,7 +15,7 @@
 
 This document describes a signature format for signing messages with Bitcoin private keys.
 
-The specification is intended to describe the standard for signatures of messages that can be signed and verfied between different clients that exist in the field today. Note: that a new signature format has been defined which has a number of advantages over this BIP, but to be backwards compatible with existing implementations this BIP will be useful. See BIP 322 [1] for full details on the new signature scheme.
+The specification is intended to describe the standard for signatures of messages that can be signed and verified between different clients that exist in the field today. Note: that a new signature format has been defined which has a number of advantages over this BIP, but to be backwards compatible with existing implementations this BIP will be useful. See BIP 322 [1] for full details on the new signature scheme.
 
 One of the key problems in this area is that there are several different types of Bitcoin addresses and without introducing specific standards it is unclear which type of address format is being used. See [2]. This BIP will attempt to address these issues and define a clear and concise format for Bitcoin signatures.
 

bip-0140.mediawiki

@@ -62,7 +62,7 @@ This is the standard ''m-of-n'' script defined in [https://github.com/bitcoin/bi
 The existing <code>OP_CHECKMULTISIG</code> and <code>OP_CHECKMULTISIGVERIFY</code> have a bug<ref>[[https://bitcoin.org/en/developer-guide#multisig|Developer Documentation - Multisig]]</ref> that pops one argument too many from the stack. This bug is not reproduced in the implementation of OP_CHECKSIGEX, so the canonical solution of pushing a dummy value onto the stack is not necessary.
 
 The normalization is achieved by normalizing the transaction before computing the signaturehash, i.e., the hash that is signed.
-The transaction must be normalized by replacing all transaction IDs in the inputs by their normalized variants and stripping the signature scripts. The normalized transction IDs are computed as described in the previous section. This normalization step is performed both when creating the signatures as well as when checking the signatures.
+The transaction must be normalized by replacing all transaction IDs in the inputs by their normalized variants and stripping the signature scripts. The normalized transaction IDs are computed as described in the previous section. This normalization step is performed both when creating the signatures as well as when checking the signatures.
 
 === Tracking Normalized Transaction IDs ===