After BIP-110 Flops, Bitcoin's Next Soft Fork Faces a Showdown

BIP-54, formally known as “Consensus Cleanup,” would make four narrow changes to Bitcoin’s core rules. The proposal is designed to close old weaknesses and unusual edge cases, not add new ways to use Bitcoin. Its supporters say that distinction matters: This is preventive maintenance for a network now worth far more than it was when many of its rules were written.

The proposal’s authors are Antoine Poinsot, a Bitcoin Core contributor associated with Chaincode Labs, and Matt Corallo, a longtime Bitcoin developer. Corallo first raised the broader idea in 2019. Poinsot revived and expanded the work in late 2023 and early 2024, and the proposal received its formal BIP-54 designation in April 2025. The specification was marked complete in May 2026 after testing and implementation work.

The Proposal Aims to Close Four Old Gaps

The first fix is intended to address a potential “timewarp” attack on Bitcoin’s mining difficulty. Bitcoin recalculates the difficulty of mining every 2,016 blocks, roughly every two weeks, to keep block production near one block every ten minutes. A majority of the network’s mining power could exploit how Bitcoin measures time across those periods, using manipulated timestamps to make blocks appear slower to produce than they really were.

Over time, that could push mining difficulty down. In an extreme case, an attacker with majority hash rate, the computing power used to mine Bitcoin, could drive difficulty to its lowest setting in roughly 38 to 40 days. That could theoretically let the attacker produce blocks far faster than normal, rapidly create new coins, expand the network’s database of unspent coins, and disrupt time-based payment contracts such as those used by the second layer protocol, the Lightning Network.

BIP-54 would add timestamp limits at the start and end of each 2,016-block period. The rules are meant to block the classic timewarp method and a related variation known as the Murch-Zawy attack, while leaving ordinary mining unchanged.

BIP-54 Also Intends to Protect Smaller Node Operators

The second change targets “poison blocks,” valid blocks deliberately designed to take an unusually long time for computers to verify. Certain older Bitcoin transaction scripts can require minutes or even hours of processing on ordinary hardware. An attacker could use them to slow the network, increase the chance that miners waste work on stale blocks, and make it harder for people to operate independent Bitcoin nodes.

BIP-54 would cap older, pre-Segregated Witness (SegWit) transactions at 2,500 legacy signature operations. Signature operations are the cryptographic checks used to prove that someone is authorized to spend bitcoin. Normal transactions use far fewer, and SegWit and Taproot transactions would not be subject to this limit. Supporters estimate the change could reduce the worst-case verification burden by about 40 times in some cases.

The third change closes a problem in Bitcoin’s Merkle tree, the system that combines transactions into one summary for each block. A transaction exactly 64 bytes long can resemble an internal piece of that structure. That creates a way to forge a proof that could mislead some simplified payment verification, or SPV, wallets into accepting a transaction that was never confirmed.

BIP-54 would simply make 64-byte transactions invalid. Those transactions have been nonstandard for years and are rarely used. The proposal’s supporters argue that banning them fixes the underlying problem more cleanly than expecting every light wallet to use a workaround.

A Final Rule Could Simplify Bitcoin’s Future

The fourth change concerns coinbase transactions, the special transactions through which miners receive newly issued bitcoin and transaction fees. In Bitcoin’s early years, identical coinbase transactions appeared in more than one block, which caused the earlier transaction’s unspent outputs to disappear. Bitcoin added checks to prevent a repeat, but those checks add complexity to block validation.

BIP-54 would require new coinbase transactions to include settings tied to the block height, or its position in the blockchain. That would guarantee uniqueness going forward and could eventually allow nodes to remove the older duplicate-transaction checks. The change could make validation simpler and support future designs aimed at reducing the storage burden of operating a full node.

F2pool’s Position Makes Activation Harder

The technical case for BIP-54 has not ended the political debate. Wang Chun, co-founder of the major mining pool F2pool, stated on Aug. 10 that he does not support the proposal. He explained that F2Pool would update its mining nodes if BIP-54 reached the required majority through a standard BIP-9 activation process, but the pool will not signal for it beforehand.

Chun’s objection, shared back in April on X, is largely about process and priorities. He has argued that packaging four changes together resembles bundling unrelated measures into one bill. He considers several of the risks too remote to justify the coordination, software upgrades and community attention required for a soft fork, which changes Bitcoin’s rules in a way that older software may not enforce.

Supporters see bundling differently. They argue that every consensus change carries a high social cost, so combining several defensive fixes can reduce the number of difficult networkwide activation efforts. They also say Bitcoin’s rising value gives attackers more reason to explore weaknesses that once looked theoretical.

BIP-110’s Collapse Adds Fresh Caution

The debate arrives just after the failure of BIP-110, a separate proposal that sought temporarily to restrict nonfinancial data stored in Bitcoin transactions. It targeted practices associated with Ordinals inscriptions, large OP_RETURN data and some Taproot-based data storage. Its lower activation threshold failed to attract meaningful miner support, and a small chain enforcing the proposal stalled after producing a small handful of blocks.

That episode does not make BIP-54 a similar proposal. BIP-54 does not add or remove general-purpose script features, nor is it a path to covenants or OP_CAT, proposals that would expand Bitcoin’s programmable spending options. Still, BIP-110 demonstrated how quickly a disputed upgrade can become a broader argument about who should decide Bitcoin’s future.

BIP-54 is already active for testing on Bitcoin Inquisition, a Signet-based test environment, and current Bitcoin Core releases have adopted related policy protections. Some mining pools, including MARA and ViaBTC, have voluntarily begun producing compatible coinbase transactions. But formal activation parameters have not been set, and a mainnet vote remains open.

The next question is whether developers, the community, businesses, node operators, and miners can agree that fixing known but rarely exploited risks is worth another hard-fork-level coordination effort. Readers should watch for a formal BIP-9 signaling proposal, additional miner readiness announcements, and whether F2pool’s resistance prevents the broad support Bitcoin upgrades have traditionally required.