BIPs 16, 388, 443: typo and editorial fixups

Co-authored-by: futreall <86553580+futreall@users.noreply.github.com>

bip-0016.mediawiki

@@ -58,7 +58,7 @@ Examples:
 +3 signature operations:
     {2 [pubkey1] [pubkey2] [pubkey3] 3 OP_CHECKMULTISIG}
 
-+22 signature operations
++22 signature operations:
     {OP_CHECKSIG OP_IF OP_CHECKSIGVERIFY OP_ELSE OP_CHECKMULTISIGVERIFY OP_ENDIF}
 
 ==Rationale==
@@ -74,7 +74,7 @@ The signature operation counting rules are intended to be easy and quick to impl
 There is a 1-confirmation attack on old implementations, but it is expensive and difficult in practice. The attack is:
 
 # Attacker creates a pay-to-script-hash transaction that is valid as seen by old software, but invalid for new implementation, and sends themselves some coins using it.
-# Attacker also creates a standard transaction that spends the pay-to-script transaction, and pays the victim who is running old software.
+# Attacker also creates a standard transaction that spends the pay-to-script-hash transaction, and pays the victim who is running old software.
 # Attacker mines a block that contains both transactions.
 
 If the victim accepts the 1-confirmation payment, then the attacker wins because both transactions will be invalidated when the rest of the network overwrites the attacker's invalid block.
@@ -116,4 +116,5 @@ https://gist.github.com/gavinandresen/3966071
 * [[bip-0016/qa.mediawiki|Quality Assurance test checklist]]
 
 == References ==
-<references>
+
+<references/>

bip-0388.mediawiki

@@ -35,7 +35,7 @@ This BIP is licensed under the BSD 2-clause license.
 
 Unfortunately, descriptors are not a perfect match for the typical usage of hardware signing devices (often also called ''hardware wallets''). Most of them have some of the following limitations when compared to a general-purpose machine running Bitcoin Core:
 
-* they are embedded devices with limited RAM, and computational power;
+* they are embedded devices with limited RAM and computational power;
 * they cannot import additional private keys (that is, they can only sign with keys derived from a single seed via [[bip-0032.mediawiki|BIP-32]]);
 * they have limited storage, or they might not have persistent storage at all (''stateless design'').
 
@@ -74,7 +74,7 @@ It is out of scope for this document to guarantee that users do not reuse extend
 
 ==== UX issues ====
 
-Miniscript (and taproot trees) allow substantially more complex spending policies. It is a challenge to ensure that the user can practically verify such spending policies per the screen.
+Miniscript (and taproot trees) allow substantially more complex spending policies. It is a challenge to ensure that the user can practically verify such spending policies on the screen.
 
 We set two fundamental design goals:
 * Minimize the amount of information that is shown on screen - so that the user can actually validate it.
@@ -124,7 +124,7 @@ This section formally defines wallet policies, and how they relate to output scr
 
 === Formal definition ===
 
-A ''wallet policy'' is composed by a ''wallet descriptor template'', together with a vector of ''key information items''.
+A ''wallet policy'' is composed of a ''wallet descriptor template'', together with a vector of ''key information items''.
 
 ==== Wallet descriptor template ====
 
@@ -309,7 +309,7 @@ The following descriptor templates are invalid:
 * <tt>sh(multi(1,@0/**,@0/**))</tt>: Repeated keys with the same path expression
 * <tt>sh(multi(1,@0/<0;1>/*,@0/<1;2>/*))</tt>: Non-disjoint multipath expressions (<tt>@0/1/*</tt> appears twice)
 * <tt>sh(multi(1,@0/**,xpub6AHA9hZDN11k2ijHMeS5QqHx2KP9aMBRhTDqANMnwVtdyw2TDYRmF8PjpvwUFcL1Et8Hj59S3gTSMcUQ5gAqTz3Wd8EsMTmF3DChhqPQBnU/<0;1>/*))</tt>: Expression with a non-KP key present
-* <tt>pkh(@0/<0;1;2>/*)</tt>: Solved cardinality > 2
+* <tt>pkh(@0/<0;1;2>/*)</tt>: Allowed cardinality > 2
 * <tt>tr(musig(@0/**,@1/**))</tt>: Derivation before aggregation is not allowed in wallet policies (despite being allowed in [[bip-0390.mediawiki|BIP-390]])
 
 Remark: some of the examples of invalid descriptor templates may be valid via optional extensions.

bip-0443.mediawiki

@@ -176,7 +176,7 @@ If the <code><data></code> is non-empty, then the additive tweak for the data is
 
 In the following, the ''current input'' is the input whose script is being executed.
 
-The following value of the <code><mode></code> are defined:
+The following values of the <code><mode></code> are defined:
 * <code>CCV_MODE_CHECK_INPUT = -1</code>: Check an input's script; no amount check.
 * <code>CCV_MODE_CHECK_OUTPUT = 0</code>: Check an output's script; preserve the (possibly residual) amount.
 * <code>CCV_MODE_CHECK_OUTPUT_IGNORE_AMOUNT = 1</code>: Check an output's script; ignore amounts.
@@ -252,7 +252,7 @@ This is executed at the beginning of the evaluation of each input's script. It i
 the full amount of the current input.
 
 <source lang="python">
-  residual_input_amount = input[this_input_index].amount
+  residual_input_amount = inputs[this_input_index].amount
 </source>
 
 ==== <code>OP_CHECKCONTRACTVERIFY</code> evaluation ====