diff --git a/bip-p2qrh.mediawiki b/bip-p2qrh.mediawiki
index 45f6427b24..8b9e0ba46d 100644
--- a/bip-p2qrh.mediawiki
+++ b/bip-p2qrh.mediawiki
@@ -10,6 +10,8 @@
   Created: 2024-06-08
 </pre>
 
+__TOC__
+
 == Introduction ==
 
 === Abstract ===
@@ -116,10 +118,11 @@ occurs when the public key is known well in advance. Short-range attacks require
 Should quantum advantage manifest, a convention is proposed in spending the full 65-byte P2PK key used by the coinbase
 output in Block 1 back to itself. It is proposed to call the address in Block 1 the
 [https://mempool.space/address/0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f81
-41781e62294721166bf621e73a82cbf2342c858ee Canary address] since it can only be spent from by others (assuming Satoshi's
-continued absence) if secp256k1 is broken. Should the Canary coins move, that will signal that reliance on secp256k1 is
-presently vulnerable. Without the Canary, or an address like it, there may be some doubt as to whether the coins were
-moved with keys belonging to the original owner.
+41781e62294721166bf621e73a82cbf2342c858ee
+Canary address] since it can only be spent from by others (assuming Satoshi's continued absence) if secp256k1 is
+broken. Should the Canary coins move, that will signal that reliance on secp256k1 is presently vulnerable. Without the
+Canary, or an address like it, there may be some doubt as to whether the coins were moved with keys belonging to the
+original owner.
 
 As an interesting aside, coinbase outputs to P2PK keys go as far as block 200,000, so there are 1,723,848 coins that
 are vulnerable from the first epoch at the time of writing in P2PK outputs alone. Since the majority of these have a
@@ -143,9 +146,9 @@ Although CRQCs could pose a threat to the signatures used in Bitcoin, a smaller
 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">Used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes.</ref> using
-Grover's algorithm would require at least 10<sup>24</sup> quantum operations. As for Grover's application to mining,
-see [https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques’ post on this].
+name="hash160">Used by P2PKH, P2SH, and P2WPKH addresses, though not P2WSH because it uses 256-bit hashes.</ref>
+using Grover's algorithm would require at least 10^24 quantum operations. As for Grover's application to mining, see
+[https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques’ post on this].
 
 === Rationale ===
 
@@ -240,7 +243,11 @@ are used for P2WPKH and P2TR outputs, respectively.
 The <code>qrh()</code> function takes the HASH256 of the concatenated HASH256 of the quantum-resistant public keys as
 its argument. For example:
 
-<code>qrh(HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ...))</code>
+<code>
+<nowiki>
+qrh(HASH256(HASH256(pubkey1) <nowiki>||</nowiki> HASH256(pubkey2) <nowiki>||</nowiki> ...))
+</nowiki>
+</code>
 
 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.
@@ -260,7 +267,9 @@ Example P2QRH address:
 The <code>scriptPubKey</code> for a P2QRH output is:
 
 <pre>
+<nowiki>
 OP_PUSHNUM_3 OP_PUSHBYTES_32 <hash>
+</nowiki>
 </pre>
 
 Where:
@@ -271,7 +280,7 @@ Where:
 ==== Hash Computation ====
 
 <pre>
-hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN))
+hash = HASH256(HASH256(pubkey1) <nowiki>||</nowiki> HASH256(pubkey2) <nowiki>||</nowiki> ... <nowiki>||</nowiki> HASH256(pubkeyN))
 </pre>
 
 This construction creates a cryptographic commitment to multiple public keys.
@@ -343,7 +352,9 @@ To spend a P2QRH output, the following conditions must be met:
 1. The <code>scriptPubKey</code> must be of the form:
 
 <pre>
+<nowiki>
 OP_PUSHNUM_3 <32-byte hash>
+</nowiki>
 </pre>
 
 2. The attestation must include:
@@ -388,13 +399,17 @@ Signature verification is as follows:
 * Compute <code>hashed_pubkeys</code> by concatenating the <code>HASH256</code> of each provided public key:
 
 <pre>
-  hashed_pubkeys = HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN)
+<nowiki>
+  hashed_pubkeys = HASH256(pubkey1) &#124;&#124; HASH256(pubkey2) &#124;&#124; ... &#124;&#124; HASH256(pubkeyN)
+</nowiki>
 </pre>
 
 * Compute <code>computed_hash</code>:
 
 <pre>
+<nowiki>
   computed_hash = HASH256(hashed_pubkeys)
+</nowiki>
 </pre>
 
 * Compare the resulting hash to <code><hash></code>. If they do not match, the script fails.
@@ -408,6 +423,7 @@ Signature verification is as follows:
 Signing for a single input using both FALCON-1024 and secp256k1 Schnorr:
 
 <pre>
+<nowiki>
 [num_pubkeys]: 0x02
 
 Pubkey 1:
@@ -427,6 +443,7 @@ Signature 1:
 Signature 2:
   [signature_length]: 0x40 (64 bytes)
   [signature]: signature_secp256k1
+</nowiki>
 </pre>
 
 Note: This contrasts with multisig inputs, where the attestation structure repeats for each public key and signature.
@@ -486,8 +503,8 @@ bytes || 64 bytes || Hash-based cryptography
 | [https://eprint.iacr.org/2011/484.pdf XMSS]<ref name="xmss">XMSS, which is based on Winternitz, uses a value of 108
 for its most compact signature size, with only a 4.6x (2.34/0.51) increase in verification time. Signing and key
 generation are not considered a significant factor because they are not distributed throughout the entire Bitcoin
-network, which take place only inside of wallets one time.</ref> || 2011 || 15,384 bytes || 13,568 bytes || Hash-based
-cryptography (Winternitz OTS)
+network, which take place only inside of wallets one time.</ref> || 2011 || 15,384 bytes || 13,568 bytes ||
+Hash-based cryptography (Winternitz OTS)
 |-
 | [https://pq-crystals.org/dilithium/ CRYSTALS-Dilithium (FIPS 204 - ML-DSA)] || 2017 || 4,595 bytes || 2,592 bytes ||
 Lattice cryptography
@@ -504,8 +521,8 @@ Lattice cryptography
 | [https://eprint.iacr.org/2024/760.pdf SQIsign2D-West] || 2024 || 294 bytes || 130 bytes || Supersingular Elliptic
 Curve Isogeny
 |-
-| [https://eprint.iacr.org/2023/436.pdf SQIsignHD] || 2023 || 109 bytes (NIST Level I) || Not provided || Supersingular
-Elliptic Curve Isogeny
+| [https://eprint.iacr.org/2023/436.pdf SQIsignHD] || 2023 || 109 bytes (NIST Level I) || Not provided ||
+Supersingular Elliptic Curve Isogeny
 |}
 
 As shown, supersingular elliptic curve quaternion isogeny signature algorithms represent the state of the art in
@@ -578,7 +595,7 @@ To help implementors understand updates to this BIP, we keep a list of substanti
 * 2024-09-30 - Refactor the ECC vs PoW section. Swap quitness for attestation.
 * 2024-09-29 - Update section on PoW to include partial-preimage.
 * 2024-09-28 - Add Winternitz, XMSS signatures, and security assumption types to PQC table. Omit NIST Level I table.
-Add spend script specification. Add revealed public key scenario table.
+  Add spend script specification. Add revealed public key scenario table.
 * 2024-09-27 - Initial draft proposal
 
 == Acknowledgements ==