diff --git a/bip-XXXX.mediawiki b/bip-XXXX.mediawiki
index 6638badb..ef3f4a9b 100644
--- a/bip-XXXX.mediawiki
+++ b/bip-XXXX.mediawiki
@@ -90,14 +90,13 @@ This BIP disallows bitcoin transactions that are serialized to 64 bytes in lengt
==Rationale==
-=== SPV clients ==
+===SPV clients===
Attacks on SPV clients could be mitigated by knowing the depth of the merkle tree. Requiring SPV clients to request both the coinbase and payment transaction could mitigate this attack.
To produce a valid coinbase transaction at the same depth that our fake transaction F occurs at would require 224 bits of work.
As mentioned above, this is computionally and financially expensive, but theoretically possible. This design would increase the size
of SPV proofs by 70%.[[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/29?u=chris_stewart_5 Base proof: 80 byte header + 448 byte partial merkle tree = 528 bytes. Proof with coinbase tx, assuming the coinbase tx is in the left half of the tree and the tx to prove is in the right half of the tree: 80 byte header + 416 bytes partial merkle tree for coinbase tx + 416 bytes partial merkle tree for tx = 912 bytes.]]
-
==Backward compatibility==
There have been 5 64-byte transactions that have occcurred in the bitcoin blockchain as of this
@@ -105,7 +104,7 @@ writing [[https://github.com/Christewart/bips/blob/2024-12-20-64bytetxs/64by
With the last transaction 7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612][[https://mempool.space/tx/7f2efc6546011ad3227b2da678be0d30c7f4b08e2ce57b5edadd437f9e27a612 Last 64-byte transaction in the bitcoin blockchain]]
occurring at block height 419,606[[https://mempool.space/block/000000000000000000308f1efc24419f34a3bafcc2b53c32dd57e4502865fd84 Block 419,606]].
-### Pre segwit 64-byte transactions
+====Pre segwit 64-byte transactions====
64-byte transactions cannot spend a utxo protected by a digital signature.[[https://github.com/bitcoin/bips/blob/master/bip-0066.mediawiki After BIP66 was activated on the bitcoin network, bitcoin transactions cannot have a digital signature smaller than 9 bytes.]]
The largest scriptSig a 64-byte transaction can have is 4 bytes.[[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73]]
@@ -114,10 +113,10 @@ There are 6[[https://github.com/Christewart/bips/blob/2024-12-20-64bytetxs/n
non standard hashlock utxos in the bitcoin blockchain. None of them have a 0-3 byte pre-image. This means they cannot be spent by a 64-byte transaction.
Pre-segwit 64-byte transactions that spend a nonstandard utxo that are inherently malleable][[https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#trust-free-unconfirmed-transaction-dependency-chain Details on how to malleate a pre-segwit transaction]].
-Policy rules such as `CLEANSTACK`, `MINIMALDATA`, `PUSHONLY` are policy rules - not consensus. If a user has a way to confirm an already non-standard
+Policy rules such as CLEANSTACK, MINIMALDATA, PUSHONLY are policy rules - not consensus. If a user has a way to confirm an already non-standard
64-byte transaction - they can malleate the transaction by violating policy rules to change the size of the transaction to a size other than 64 bytes.
-#### Segwit 64-byte transactions
+====Segwit 64-byte transactions====
This BIP disallows single-input single output segwit transactions that pay to a 2 byte witness program.[[https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/73#p-4382-future-segwit-versions-10 BIP141 says witness programs can be 2 bytes in size, which makes the scriptPubKey a total of 4 bytes]]
The only known use case[[https://bitcoin.stackexchange.com/a/110664 Why do we have 2 byte witness programs? The original rationale for the lower end of the range of valid witness program lengths is that 2 bytes is enough to guarantee no ambiguity of how the program would be pushed (some 1 byte values can - and according to standardness, must - be pushed with OP_n, and dealing with those would have complicated the matter).]]