More wrestling with MediaWiki formatting...

bip-p2qrh.mediawiki

@@ -240,7 +240,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:
 
-<code>qrh(HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ...))</code>
+<code>qrh(HASH256(HASH256(pubkey1) &#124;&#124; HASH256(pubkey2) &#124;&#124; ...))</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.
@@ -271,7 +271,7 @@ Where:
 ==== Hash Computation ====
 
 <pre>
-hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN))
+hash = HASH256(HASH256(pubkey1) &#124;&#124; HASH256(pubkey2) &#124;&#124; ... &#124;&#124; HASH256(pubkeyN))
 </pre>
 
 This construction creates a cryptographic commitment to multiple public keys.
@@ -364,7 +364,7 @@ fixed-size commitment to potentially multiple public keys of varying lengths.
 ==== Hash Computation ====
 
 <pre>
-hash = HASH256(HASH256(pubkey1) || HASH256(pubkey2) || ... || HASH256(pubkeyN))
+hash = HASH256(HASH256(pubkey1) &#124;&#124; HASH256(pubkey2) &#124;&#124; ... &#124;&#124; HASH256(pubkeyN))
 </pre>
 
 ==== Sighash Calculation ====
@@ -388,7 +388,7 @@ 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)
+  hashed_pubkeys = HASH256(pubkey1) &#124;&#124; HASH256(pubkey2) &#124;&#124; ... &#124;&#124; HASH256(pubkeyN)
 </pre>
 
 * Compute <code>computed_hash</code>:
@@ -486,8 +486,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 +504,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