BIP-54: Consensus Cleanup
Antoine Poinsot's proposal to fix long-standing protocol bugs
WHAT IS IT
A soft fork that fixes four legacy consensus issues that have been known for years but never formally addressed: the timewarp attack, slow-to-validate blocks, the duplicate coinbase vulnerability, and Merkle tree ambiguity. Originally proposed in 2019 by Matt Corallo, now formalized by Antoine Poinsot.
THE FIXES
Timewarp: Constrains timestamp manipulation across difficulty periods
Validation DoS: Caps worst-case block validation time
Coinbase uniqueness: Prevents duplicate txids after BIP-34 enforcement gaps
Merkle tree: Eliminates 64-byte transaction ambiguity
Validation DoS: Caps worst-case block validation time
Coinbase uniqueness: Prevents duplicate txids after BIP-34 enforcement gaps
Merkle tree: Eliminates 64-byte transaction ambiguity
DETAILS
Author: Antoine Poinsot
BIP: 54
Type: Soft fork (consensus)
Status: Draft
Original idea: Matt Corallo's "Great Consensus Cleanup" (2019)
Activation: Deployment TBD
BIP: 54
Type: Soft fork (consensus)
Status: Draft
Original idea: Matt Corallo's "Great Consensus Cleanup" (2019)
Activation: Deployment TBD
Four Legacy Vulnerabilities
TIMEWARP ATTACK
An attacker with >50% hashrate can manipulate block timestamps at difficulty adjustment boundaries to artificially lower difficulty. This could allow faster block production, pull subsidy forward from future miners, and increase validation costs for nodes. BIP-54 constrains the timestamp of the first block of a new retarget period to be no more than 2 hours before the last block of the previous period.
SLOW VALIDATION BLOCKS
Legacy script opcodes like
OP_CHECKMULTISIG allow crafting blocks that take minutes to validate on normal hardware. An attacker could use this to DoS the network during IBD or stall block propagation. BIP-54 limits the worst-case validation cost by capping legacy sigops per transaction to 2,500.DUPLICATE COINBASE TXIDS
BIP-34 required block height in coinbase scripts, but some pre-activation coinbase transactions coincidentally contain valid height commitments for future blocks, creating potential txid collisions. BIP-54 adds additional constraints to ensure all future coinbase transactions are unique, closing the gap permanently.
MERKLE TREE AMBIGUITY
A 64-byte transaction can be confused with an internal Merkle tree node, enabling SPV proof forgery. BIP-54 invalidates 64-byte transactions entirely. This is non-standard already, so no legitimate use cases are affected.
Deployment Discussion
ACTIVATION MECHANISM
The BIP itself is still Draft and does not yet standardize activation parameters. The open question is how a future deployment should package the four bug fixes, whether miner signaling should be used, and what level of coordination would be required to activate a narrow cleanup soft fork.
WHAT "COMPATIBLE" MEANS FOR MINERS
A forward-compatible block sets coinbase
nLockTime to block_height − 1 with appropriate nSequence, plus complies with the proposed timestamp and sigops rules. Bitcoin Core 29.0 block templates already avoid violating the proposed timestamp rules, and Core 30.0 templates already exclude transactions that would violate the proposed legacy-sigops limit. Mining pools could choose to produce forward-compatible blocks voluntarily even before any activation path is finalized.FIRST SOFT FORK SINCE TAPROOT
If BIP-54 moves from draft to deployment, it would be the first new soft fork activation attempt since Taproot in November 2021. Because it fixes long-known bugs rather than adding new functionality, it has become a test case for whether Bitcoin can still coordinate upgrades on a narrowly scoped consensus cleanup.
DISCUSSION POINTS
Deployment design: Should activation parameters live outside the BIP text, and how much miner coordination should be required?
Scope debate: Should timewarp be separated from the other fixes?
Activation precedent: Success could pave the way for future soft fork discussions. Stalling reinforces the ossification narrative.
Scope debate: Should timewarp be separated from the other fixes?
Activation precedent: Success could pave the way for future soft fork discussions. Stalling reinforces the ossification narrative.
Context & Resources
TIMELINE
2019: Matt Corallo proposes the "Great Consensus Cleanup" on bitcoin-dev
Apr 2025: Antoine Poinsot authors BIP-54; BIP assigned as Draft
Core 29.0: Block templates avoid violating the proposed timestamp rules
Core 30.0: Templates exclude transactions violating the proposed sigops limit
2026: Draft and deployment discussion continue
Apr 2025: Antoine Poinsot authors BIP-54; BIP assigned as Draft
Core 29.0: Block templates avoid violating the proposed timestamp rules
Core 30.0: Templates exclude transactions violating the proposed sigops limit
2026: Draft and deployment discussion continue
WHY BITDEVS SHOULD CARE
BIP-54 is a litmus test for Bitcoin governance. If fixing unambiguous bugs takes years and contentious debate, it signals the difficulty of any future protocol upgrade. Watch the draft itself, Core's forward-compatibility work, and the eventual deployment discussion — together they say a lot about Bitcoin's upgrade path.