BIP-54, known as the Great Consensus Cleanup, proposes tightening four parts of Bitcoin’s consensus rules: timestamp handling, block validation, transaction inclusion proofs and coinbase transactions. Supporters see a technical cleanup and a chance to improve how Bitcoin coordinates future upgrades. Critics question whether maintenance should take priority over new features.
- It targets four specific edge cases in Bitcoin’s rules.
- Matt Corallo estimates an 80% chance it will be Bitcoin’s next soft fork.
- No activation date or deployment method has been confirmed.
- Its technical estimates describe worst-case scenarios, not everyday conditions.
Four areas BIP-54 would change
BIP-54, co-authored by developers Matt Corallo and Antoine Poinsot, proposes stricter rules in four areas where existing behavior could create security or efficiency problems. Bitcoin nodes rely on consensus rules to decide whether blocks and transactions are valid.
Corallo summed up the motivation during an appearance on MARA Foundation TV with Isabel Foxen Duke, head of the MARA Foundation: “There’s a laundry list of things we know of that we really need to clean up.” Decrypt reported his comments on November 4.
1. Timestamp manipulation and difficulty adjustment
Bitcoin recalibrates mining difficulty every 2, 016 blocks, or roughly every two weeks, though block production varies. The timewarp attack exploits the way timestamps factor into that adjustment. BIP-54 proposes tighter timestamp restrictions, including a two-hour allowance for ordinary variation.
The proposal’s technical documentation estimates that, under extreme circumstances, an attacker could push difficulty to its minimum within 38 days under the current rules. That is a scenario outlined by the proposal’s authors, not evidence of an imminent attack or a routine way to manipulate Bitcoin’s mining difficulty.
2. Costly block validation
Every full node checks blocks against Bitcoin’s rules. In the worst case, some blocks could require unusually large amounts of signature verification, making them more costly to validate.
BIP-54 proposes a limit of 2, 500 certain signature-verification operations per transaction. Its authors estimate that this could cut worst-case block-validation time by a factor of 40. That projection concerns extreme validation workloads. It does not mean ordinary blocks take 40 times longer to verify than they should.
3. Ambiguity in certain Merkle proofs
A Merkle tree summarizes the transactions in a block. It allows someone to verify that a transaction is included without downloading and checking the entire block, a useful feature for lightweight clients.
The proposal addresses a narrow ambiguity involving transactions with exactly 64 bytes of non-witness data. That data can be the same size as a pair of 32-byte hashes used in a Merkle tree, so certain inclusion proofs can be interpreted ambiguously. Transaction data may be mistaken for an internal tree node. BIP-54 proposes rules to prevent that specific confusion. It does not mean Bitcoin’s Merkle trees generally fail.
4. Duplicate coinbase transactions
A coinbase transaction is the special transaction miners create to claim a block reward. It has nothing to do with the Coinbase exchange.
BIP-54 proposes additional coinbase requirements to prevent duplicate coinbase transactions. Its specification identifies block 1, 983, 702 as the earliest future height at which a duplicate could occur under current rules. That is a projection based on the existing rules, not a report of an existing duplicate or a sign that one is imminent.
A finished specification is not network activation
The BIP changelog records “complete specification” status on May 22, 2026. That means the proposed rules have been documented. It does not mean Bitcoin has approved, scheduled or activated them.
A soft fork tightens the rules for valid blocks or transactions. Once it activates, upgraded nodes enforce the new restrictions. Older nodes do not check those additional rules, so they may accept a block that breaks a new rule even when upgraded nodes reject it. Node operators who want to enforce BIP-54’s rules themselves would need to run compatible software.
No activation date or final deployment method has been confirmed. Corallo estimates an 80% chance that BIP-54 will become Bitcoin’s next soft fork. That is his judgment, not a measured probability or a commitment from developers, miners or users.
Paul Sztorc, co-founder and CEO of LayerTwo Labs, said a survey he conducted with developers at TABconf in Atlanta put September 2027 at the earliest for activation. Most respondents expected 2028 or later. The survey’s size and methodology have not been specified, so its dates offer an informal snapshot, not a dependable schedule.
Maintenance versus new features
Sztorc called the prospect of activating BIP-54 “kind of depressing, ” arguing that it would provide maintenance without adding new functionality. That is a judgment about priorities, not a technical rebuttal.
A protocol change can be useful without adding a visible feature. Reducing an edge-case risk or limiting extreme validation costs may be worthwhile, even if most users never notice the difference. Consensus changes also carry coordination costs. Their benefits and risks deserve scrutiny, especially when those benefits are not apparent in everyday use.
Other proposals reflect the different goals Bitcoin developers weigh. OP_CAT would restore an operation for combining data in Bitcoin scripts, while OP_CHECKTEMPLATEVERIFY, proposed under BIP-119, aims to enable new transaction conditions. Each raises its own technical and political questions. Neither changes what BIP-54 is designed to do.
Why the deployment process matters
Corallo argues that coordinating BIP-54 could help establish a clearer process for future soft forks. Debates over deployment methods have continued since Taproot activated in November 2021, including disagreements over miner signaling and user-enforced activation deadlines.
A clearer process could help developers and the broader Bitcoin community handle future proposals. BIP-54 cannot settle those disagreements on its own, and no activation method has been announced. Completing a specification is one step. Reaching agreement on implementation and deployment is another.
Key questions about BIP-54
-
What does BIP-54 propose to fix?
It targets timestamp manipulation affecting difficulty adjustment, costly signature verification during block validation, ambiguity in certain Merkle proofs and the possibility of duplicate coinbase transactions under current rules.
-
Is BIP-54 set to become Bitcoin’s next soft fork?
No decision has been confirmed. Corallo estimates an 80% chance, but that is his assessment, not a commitment from the network.
-
When could it activate?
There is no official date. Sztorc said his TABconf survey put September 2027 at the earliest, with most respondents expecting 2028 or later. The survey’s methodology is unknown.
-
Does “complete specification” mean Bitcoin has adopted BIP-54?
No. The changelog records that status on May 22, 2026, but completing the specification is separate from approval and network activation.
-
Why does the deployment process matter?
Developers, miners, node operators and users need to coordinate around a soft fork. Corallo sees the process for BIP-54 as a possible model for future upgrades, though the method and outcome remain unresolved.
BIP-54 is a proposed cleanup, not a response to a declared crisis or a promise of new features. Its authors’ estimates make a case for addressing specific edge cases, while the lack of an activation plan leaves the practical trade-offs and coordination questions open.
