Apply suggestions from code review

Co-authored-by: Jon Atack <[email protected]>

bip-0360.mediawiki

@@ -44,7 +44,7 @@ The vulnerability of existing Bitcoin addresses is investigated in
 and-the-bitcoin-blockchain.html this Deloitte report]. The report estimates that in 2020 approximately 25% of the
 Bitcoin supply is held within addresses vulnerable to quantum attack. As of the time of writing, that number is now
 closer to 20%. Independently, Bitcoin developer Pieter Wuille [https://x.com/pwuille/status/1108085284862713856 reasons]
-even more might be vulnerable.
+even more addresses might be vulnerable, representing 5M to 10M bitcoin.
 
 Ordinarily, when a transaction is signed, the public key is explicitly stated in the input script. This means that the
 public key is exposed on the blockchain when the transaction is spent, making it vulnerable to quantum attack until
@@ -62,7 +62,7 @@ would be one performed on keys in the mempool, which is seen as much more diffic
 requires more sophisticated CRQCs.<ref name="short-range">
 In the paper
 [https://arxiv.org/pdf/2306.08585 How to compute a 256-bit elliptic curve private key with only 50 million Toffoli gates]
-the authors estimate that CRQC with 28 million superconducting physical qubits would take 8.3 seconds to calculate a
+the authors estimate that a CRQC with 28 million superconducting physical qubits would take 8.3 seconds to calculate a
 256-bit key, while a CRQC with 6.9 million physical qubits would take 58 seconds. This implies that a CRQC with 4x as
 many qubits would be roughly 7 times faster.
 </ref>
@@ -105,12 +105,12 @@ quantum attack:
 It should be noted that Taproot outputs are vulnerable in that they encode a 32-byte x-only public key, from which a
 full public key can be reconstructed.
 
-If an extended public key’s (xPub’s) parent private key of is recovered by CRQC, the attacker also recovers
+If the parent private key of an extended public key (xpub) is recovered by a CRQC, the attacker also recovers
 the entire extended private key, whether it uses hardened or unhardened derivation.
 
 ==== Long Range and Short Range Quantum Attacks ====
 
-Long Range Quantum Attack is an attack in which the public key has been exposed on the blockchain for an extended
+A Long Range Quantum Attack is an attack in which the public key has been exposed on the blockchain for an extended
 period of time, giving an attacker ample opportunity to break the cryptography. This affects:
 
 * P2PK outputs (Satoshi's coins, CPU miners, starts with 04)
@@ -119,8 +119,8 @@ period of time, giving an attacker ample opportunity to break the cryptography.
 * Extended public keys, commonly known as "xpubs"
 * Wallet descriptors
 
-Short Range Quantum Attack is an attack that must be executed quickly while a transaction is still in the mempool,
-before it gets mined into a block. This affects:
+A Short Range Quantum Attack is an attack that must be executed quickly while a transaction is still in the mempool,
+before it is mined into a block. This affects:
 
 * Any transaction in the mempool (except for P2QRH)
 
@@ -148,7 +148,7 @@ upgraded by 2030, with browsers and operating systems fully upgraded by 2033. Ac
 Cryptography is planned to be disallowed within the US federal government after 2035. An exception is made for hybrid
 cryptography, which is the use of ECC and post-quantum algorithms together.
 
-Although CRQCs could pose a threat to the signatures used in Bitcoin, a smaller threat is to Bitcoin's hash algorithms.
+Although the main threat posed by CRQCs is to the signatures used in Bitcoin, a smaller threat is to Bitcoin's hash algorithms.
 In particular, while a CRQC could use [https://en.wikipedia.org/wiki/Grover's_algorithm Grover's algorithm] to gain a
 quadratic speedup on brute-force attacks on the hash functions used in Bitcoin, a significantly more powerful CRQC is
 needed for these attacks to meaningfully impact Bitcoin. For instance, a preimage attack on HASH160 <ref name="hash160">
@@ -242,7 +242,7 @@ its argument. For example:
 
 This function allows wallets to manage P2QRH addresses and outputs while accommodating multiple public keys of varying
 lengths, such as in multisig schemes, while keeping the public keys hidden until the time of spending. At a minimum,
-there should be two public keys in a P2QRH output, one that makes use of classical cryptography and one that makes use
+there should be two public keys in a P2QRH output: one key that makes use of classical cryptography, and one that makes use
 of a PQC algorithm chosen within the wallet.
 
 === Address Format ===
@@ -265,12 +265,12 @@ Where:
 
 * <code>OP_PUSHNUM_3</code> (<code>0x03</code>) indicates SegWit version 3.
 * <nowiki><hash></nowiki> is the 32-byte HASH256 of the merkle root of a tree of public key hashes, as defined in the
-Hash Computation section.
+Hash Computation section below.
 
 === Output Mechanics ===
 
 To prevent storage of arbitrary data using P2QRH (QuBit) outputs,
-the witness stack for inputs spending segwit v3 outputs is limited to the fixed-size signatures necessary for spending the
+the witness stack for inputs spending SegWit v3 outputs is limited to the fixed-size signatures necessary for spending the
 output, and the output must be spendable to be considered valid within node consensus. A fixed signature size will also
 be helpful to disambiguate between signature types without an additional version byte, as SQIsign signatures are
 substantially smaller than FALCON signatures. Consequently, the correct signature algorithm can be inferred through
@@ -387,7 +387,7 @@ Supported PQC algorithms and their NIST Level V parameters:
 
 Implementations must reject public keys and signatures that do not match expected lengths for supported algorithms.
 
-If there a new algorithm is added, and one of the byte sizes overlaps, then an additional byte should be prepended to the
+If a new algorithm is added, and one of the byte sizes overlaps, then an additional byte should be prepended to the
 new algorithm's public key length that indicates the specific algorithm used.
 
 === Script Validation ===
@@ -567,7 +567,7 @@ might be possible to implement Isogeny Schnorr signatures.
 
 Signature verification speed as it compares to Schnorr or ECDSA isn't seen as high a consideration as signature size
 due to block space being the primary fee constraint. As a P2QRH implementation materializes, a benchmark will be added
-for performance comparison. Fortunately, SQIsign signatures are substantially faster to verify than it is to generate
+for performance comparison. Fortunately, SQIsign signatures are substantially faster to verify than they are to generate
 keys or to sign, which is a major consideration when a transaction need only be signed once, or a handful of times with
 PSBT, compared to being verified simultaneously on tens of thousands of nodes. Key generation may need to be cached in
 BIP-32 Hierarchical Deterministic wallets.