Collect and curate various minor fixups from Jul/Aug/Sept

bip-0010.mediawiki

@@ -95,7 +95,7 @@ In this transaction, there are two inputs, one of 150 BTC and the other of 12 BT
 
 The style of communication is taken directly from PGP/GPG, which uses blocks of ASCII like this to communicate encrypted messages and signatures.  This serialization is compact, and will be interpreted the same in all character encodings.  It can be copied inline into an email, or saved in a text file.  The advantage over the analogous PGP encoding is that there are some human readable elements to it, for users that wish to examine the TxDP packet manually, instead of requiring a program to parse the core elements of the TxDP.
 
-A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line.  If that is the last signature required, they can broadcast it themselves.  Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP.  However, even without the programmatic support, a user could manually combine them by copying the appropriate _TXSIGS_ lines between serializations, though it is not the recommended method for combining TxDPs.
+A party receiving this TxDP can simply add their signature to the appropriate _TXINPUT_ line.  If that is the last signature required, they can broadcast it themselves.  Any software that implements this standard should be able to combine multiple TxDPs into a single TxDP.  However, even without the programmatic support, a user could manually combine them by copying the appropriate _SIG_ lines between serializations, though it is not the recommended method for combining TxDPs.
 
 == Reference Implementation ==
 

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-0119/simulation.py

@@ -11,7 +11,7 @@
 AVG_INTERVAL = 10*60
 TXNS_PER_SEC = 0.5*MAX_BLOCK_SIZE/AVG_TX/AVG_INTERVAL
 MAX_MEMPOOL = MAX_BLOCK_SIZE * 100
-COMPRESSABLE = 0.05
+COMPRESSIBLE = 0.05
 
 
 
@@ -59,7 +59,7 @@ def compressed(rate_multiplier = 1):
             block_time = np.random.exponential(AVG_INTERVAL)
             total_time[i] = block_time
             txns = np.random.poisson(rate_multiplier*get_rate(phase)*block_time)
-            postponed = txns * COMPRESSABLE
+            postponed = txns * COMPRESSIBLE
             weight = (txns-postponed)*AVG_TX + backlog
             secondary_backlog += postponed*133 + postponed*34 # Total extra work
             if weight > MAX_BLOCK_SIZE:
@@ -88,7 +88,7 @@ def make_patch_spines_invisible(ax):
     compressed_txs2, unspendable2, blocktimes_c2 = compressed(2)
 
     fig, host = plt.subplots()
-    host.set_title("Transaction Compression Performance with %d%% Adoption During Spike"%(100*COMPRESSABLE))
+    host.set_title("Transaction Compression Performance with %d%% Adoption During Spike"%(100*COMPRESSIBLE))
     fig.subplots_adjust(right=0.75)
     par1 = host.twinx()
     par2 = host.twinx()

bip-0327/reference.py

@@ -4,7 +4,7 @@
 # be used in production environments. The code is vulnerable to timing attacks,
 # for example.
 
-from typing import Any, List, Optional, Tuple, NewType, NamedTuple
+from typing import List, Optional, Tuple, NewType, NamedTuple
 import hashlib
 import secrets
 import time

bip-0330/minisketch.py

@@ -1,5 +1,7 @@
 #!/usr/bin/env python3
 
+import random
+
 ######## ENCODING and DECODING ########
 
 FIELD_BITS = 32
@@ -31,8 +33,6 @@ def sketch(shortids, capacity):
 
 ######## DECODING only ########
 
-import random
-
 def inv(x):
     """Compute 1/x in GF(2^FIELD_BITS)"""
     t = x
@@ -154,4 +154,3 @@ def decode(sketch):
         else:
             sums.append(odd_sums[(i+1)//2])
     return find_roots(list(reversed(berlekamp_massey(sums))))
-

bip-0340/reference.py

@@ -1,6 +1,5 @@
 from typing import Tuple, Optional, Any
 import hashlib
-import binascii
 
 # Set DEBUG to True to get a detailed debug output including
 # intermediate values during key generation, signing, and

bip-0352/bitcoin_utils.py

@@ -33,7 +33,7 @@ def deser_txid(txid: str):
 
 def deser_compact_size(f: BytesIO):
     view = f.getbuffer()
-    nbytes = view.nbytes;
+    nbytes = view.nbytes
     view.release()
     if (nbytes == 0):
         return 0 # end of stream

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

scripts/buildtable.pl

@@ -199,7 +199,8 @@
 				die "First Comments-URI must be exactly \"$first_comments_uri\" in $fn" unless $val eq $first_comments_uri;
 			}
 		} elsif (exists $DateField{$field}) {
-			die "Invalid date format in $fn" unless $val =~ /^20\d{2}\-(?:0\d|1[012])\-(?:[012]\d|30|31)$/;
+			# Enforce date format 20XX-MM-DD, where XX is 00-99, MM is 01-12 and DD is 01-31
+			die "Invalid date format in $fn" unless $val =~ /^20\d{2}\-(?:0[1-9]|1[0-2])\-(?:0[1-9]|[12]\d|30|31)$/;
 		} elsif (exists $EmailField{$field}) {
 			$val =~ m/^(\S[^<@>]*\S) \<[^@>]*\@[\w.]+\.\w+\>$/ or die "Malformed $field line in $fn";
 		} elsif (not exists $MiscField{$field}) {

scripts/link-format-chk.sh

@@ -8,7 +8,7 @@
 
 ECODE=0
 for fname in *.mediawiki; do
-    GRES=$(grep -n '](http' $fname)
+    GRES=$(grep -n '](http' "$fname")
     if [ "$GRES" != "" ]; then
         if [ $ECODE -eq 0 ]; then
             >&2 echo "Github Mediawiki format writes link as [URL text], not as [text](url):"