More formatting fixes.

bip-p2qrh.mediawiki

@@ -145,9 +145,9 @@ 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.
 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^24 quantum operations. As for Grover's application to mining, see
+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^24 quantum operations. As for Grover's application to mining, see
 [https://quantumcomputing.stackexchange.com/a/12847 Sam Jaques’ post on this].
 
 === Rationale ===
@@ -243,7 +243,7 @@ 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:
 
-qrh(HASH256(HASH256(pubkey1) <nowiki>||</nowiki> HASH256(pubkey2) <nowiki>||</nowiki> ...))
+  qrh(HASH256(HASH256(pubkey1) <nowiki>||</nowiki> HASH256(pubkey2) <nowiki>||</nowiki> ...))
 
 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.
@@ -262,27 +262,29 @@ Example P2QRH address:
 
 The <code>scriptPubKey</code> for a P2QRH output is:
 
-OP_PUSHNUM_3 OP_PUSHBYTES_32 <hash>
+  OP_PUSHNUM_3 OP_PUSHBYTES_32 <nowiki><hash></nowiki>
 
 Where:
 
 - <code>OP_PUSHNUM_3</code> (<code>0x03</code>) indicates SegWit version 3.
-- <hash> is the 32-byte HASH256 of the concatenated HASH256 of each public key.
+- <nowiki><hash></nowiki> is the 32-byte HASH256 of the concatenated HASH256 of each public key.
 
 ==== Hash Computation ====
 
-hash = HASH256(HASH256(pubkey1) <nowiki>||</nowiki> HASH256(pubkey2) <nowiki>||</nowiki> ... <nowiki>||</nowiki> HASH256(pubkeyN))
+  hash = HASH256(HASH256(pubkey1) <nowiki>||</nowiki> HASH256(pubkey2) <nowiki>||</nowiki> ... <nowiki>||</nowiki> HASH256(pubkeyN))
 
 This construction creates a cryptographic commitment to multiple public keys.
 
 === Transaction Serialization ===
 
 Following BIP-141, the transaction serialization is modified to include a new attestation field after the witness field:
 
-[nVersion][marker][flag][txins][txouts][witness][attestation][nLockTime]
+  [nVersion][marker][flag][txins][txouts][witness][attestation][nLockTime]
 
 - <code>marker</code>: <code>0x00</code> (same as SegWit)
+
 - <code>flag</code>: <code>0x02</code> (indicates the presence of both witness and attestation data)
+
 - <code>attestation</code>: Contains the quantum-resistant public keys and signatures.
 
 === Attestation Structure ===
@@ -343,8 +345,9 @@ OP_PUSHNUM_3 <32-byte hash>
 
 2. The attestation must include:
 
-* The quantum-resistant public key(s) whose HASH256 concatenated and hashed again matches the <hash> in
+* The quantum-resistant public key(s) whose HASH256 concatenated and hashed again matches the <nowiki><hash></nowiki> in
 the <code>scriptPubKey</code>.
+
 * Valid signatures corresponding to the public key(s) and the transaction data.
 
 3. For multi-signature schemes, all required public keys and signatures must be provided for that input within the
@@ -374,7 +377,7 @@ The message to be signed includes these hashes, ensuring transaction malleabilit
 
 Signature verification is as follows:
 
-1. Extract the <hash> from the <code>scriptPubKey</code>.
+1. Extract the <nowiki><hash></nowiki> from the <code>scriptPubKey</code>.
 
 2. For each input:
 
@@ -384,9 +387,9 @@ Signature verification is as follows:
 
 * Compute <code>computed_hash</code>:
 
-computed_hash = HASH256(hashed_pubkeys)
+  computed_hash = HASH256(hashed_pubkeys)
 
-* Compare the resulting hash to <hash>. If they do not match, the script fails.
+* Compare the resulting hash to <nowiki><hash></nowiki>. If they do not match, the script fails.
 
 3. Verify each signature against the corresponding public key and the sighash.
 
@@ -396,7 +399,9 @@ computed_hash = HASH256(hashed_pubkeys)
 
 Signing for a single input using both FALCON-1024 and secp256k1 Schnorr:
 
-[num_pubkeys]: 0x02
+Number of public keys:
+
+  [num_pubkeys]: 0x02
 
 Pubkey 1:
   [pubkey_length]: 0x0701 (1793 bytes)
@@ -406,7 +411,9 @@ Pubkey 2:
   [pubkey_length]: 0x20 (32 bytes)
   [pubkey]: public_key_secp256k1
 
-[num_signatures]: 0x02
+Number of signatures:
+
+  [num_signatures]: 0x02
 
 Signature 1:
   [signature_length]: 0x0500 (1280 bytes)