Great Consensus Cleanup

Remark 35.1 (Why These Bugs Exist)

Many bugs stem from Bitcoin's early development:

• Satoshi worked alone with limited review
• Some edge cases were not anticipated
• Fixing bugs post-launch risks breaking consensus
• Conservative approach: do not fix unless necessary

new_target = old_target × (actual_time / expected_time)

where:
  expected_time = 2016 × 10 minutes = 2 weeks
  actual_time = timestamp(block[2015]) - timestamp(block[0])
  (the first and last blocks of the same 2016-block period)

Remark 35.2 (Attack Procedure)

With >50% hashrate, an attacker can perform a two-phase timestamp manipulation each retarget period:

1. Phase 1: Hold the period's timestamps far in the past, then set the last block (block[2015]) as late as the rules allow (~2 hours past real time)
2. Phase 2: Set the first block of the next period (block[2016]) back to the held-back past time
3. The difficulty formula sees a large actual_time (future minus past), causing difficulty to decrease (subject to the 4× clamp per period)
4. Repeat: each period reduces difficulty by up to 4×
5. Mainnet difficulty is roughly 10¹⁴ times the minimum, and log₄(10¹⁴) ≈ 23, so about 24 fourfold reductions bring difficulty to its floor

In this model the attacker drives difficulty to its minimum and could mine the remaining subsidy within weeks.

Remark 35.3 (Proposed Fix: Timewarp)

The cleanup proposes constraining the first block of each retarget period specifically (not all blocks, since MTP rules already constrain non-boundary blocks):

// New rule for retarget boundary: block at height h where h % 2016 == 0:
timestamp(block[h]) >= timestamp(block[h-1]) - 2 hours

This prevents the timestamp manipulation needed for the attack.

Remark 35.4 (Proposed Fix: 64-Byte Transactions)

Ban transactions whose witness-stripped serialization is exactly 64 bytes (the stripped form is what feeds the txid and the Merkle leaf):

// New consensus rule:
if (tx.GetSerializeSize(WITHOUT_WITNESS) == 64)
    return Invalid("64-byte-tx")

No legitimate use of 64-byte transactions is known.

Block with txs: [A, B, C]
Merkle construction:
  Level 0: [H(A), H(B), H(C), H(C)]  // C duplicated
  Level 1: [H(H(A)||H(B)), H(H(C)||H(C))]
  Root: H(...)

Block with txs: [A, B, C, C]  // Duplicate C
Merkle construction:
  Level 0: [H(A), H(B), H(C), H(C)]
  Level 1: [H(H(A)||H(B)), H(H(C)||H(C))]
  Root: H(...)  // identical root

Different blocks, same merkle root → attack vector

Remark 35.5 (Mitigation Status)

Mitigations:

• Bitcoin Core detects mutated blocks (duplicated merkle branches) during validation and does not mark the block hash as permanently invalid
• Separately, BIP-30/BIP-34 address duplicate txids (CVE-2012-1909), a different bug
• Remaining issue: the merkle construction itself still permits interior-node duplication

Great Consensus Cleanup proposes additional restrictions.

Remark 35.6 (Cleanup Proposals)

The Great Consensus Cleanup proposes:

• Limit OP_CODESEPARATOR in legacy scripts
• Restrict FindAndDelete behavior
• Cap maximum validation time
• Remove other legacy quirks

Note: Tapscript already fixes many of these for new scripts.

Remark 35.7 (Worst-Case Validation as an Attack)

An attacker with sufficient hashrate could:

1. Create a block with pathological transactions
2. Block takes very long to validate (~minutes to hours)
3. Nodes fall behind, potential network split
4. Attack window for double-spends

Remark 35.8 (Proposed Validation Limits)

Proposed fixes:

• Maximum script validation time per input
• Maximum total block validation time
• Limits on signature operations in legacy scripts

Remark 35.9 (Current Status)

As of mid-2026:

• The cleanup was proposed by Matt Corallo in 2019 and revived by Antoine Poinsot in 2024–2025 as a draft BIP
• The revival includes the timewarp fix, the 64-byte-transaction fix, and limits on worst-case validation cost
• Technical review is ongoing; the proposal is generally less contested than feature additions
• No activation parameters have been set, and the fork is not activated