54
BIP54
Consensus Cleanup

Bitcoin soft fork proposal

BIP54: Consensus Cleanup

A soft fork proposal that closes four long-standing Bitcoin consensus weaknesses. Track readiness, understand each fix, and try interactive simulations of the problems BIP54 closes.

Open simulatorRead the BIP
Proposal status
Complete
In bitcoin/bips as Complete
Formal signaling
Not started
No activation bit yet
Recent blocks compatible
~42%
Coinbase locktime · as of 2026-07-28
Author
Antoine Poinsot
with Matt Corallo

Readiness vs signaling

Two different things — easy to confuse

Pre-activation
Version-bit signaling (formal)0%

Not started — activation method and bit still TBD

BIP54-compatible coinbases42%

~42% of recent blocks set nLockTime = height − 1 (mainnet.observer, 2026-07-28)

Specification
BIP54 is marked Complete in bitcoin/bips — spec text and rationale are final.
Implementation
Bitcoin Core PR #35793 is open (validation rules without mainnet activation); Signet demos of slow-to-validate blocks exist.

Important distinction

Pools setting a BIP54-compatible coinbase are showing forward-compatibility (they can already produce valid blocks under the proposed rule). That is not the same as voting for activation with a version bit. No activation bit has been assigned. Previous soft forks used BIP9 or BIP8 version-bit signaling. BIP54’s activation mechanism is still under community discussion — separate from pool forward-compatibility.

Typical historical threshold once signaling starts: TBD (historically ~90–95% of blocks in a difficulty period)

Timeline

From early draft to pool adoption

  1. 2019
    Original draft

    Matt Corallo proposes an early consensus cleanup soft fork.

  2. 2023–24
    Revival

    Antoine Poinsot restarts research and community discussion on Delving Bitcoin.

  3. 2025
    BIP54 published

    Number assigned 2025-04-11 and specification merged into bitcoin/bips on 2025-04-29; later marked Complete.

  4. 2026
    Pool forward-compat

    WhitePool, MARA, ViaBTC, Foundry and others produce BIP54-compatible coinbases (~42% of recent blocks). Formal activation signaling still not started.

Mining pools with BIP54-compatible coinbases

First time each pool mined a coinbase with nLockTime = height − 1, and all-time compatible-block counts (3,693 in total). From mainnet.observer as of 2026-07-28.

Raw pool CSV ↗
PoolFirst heightFirst dateBlocks
Foundry USA952,8802026-06-081,834Largest adopter by compatible-block count so far
MARA Pool940,5482026-03-13938Early major-pool adopter
ViaBTC949,0942026-05-12886Partial rollout reported at first (mixed pool software)
WhitePool937,4042026-02-1928Among the first BIP54-compatible mainnet blocks
Solo CK951,4082026-05-283Solo mining via ckpool
CKPool956,0212026-06-302Small open pool
Unknown940,4842026-03-132Unattributed miners

On 2026-07-28, 42.4% of mainnet coinbases set nLockTime = height − 1 (BIP54-compatible); the trailing 7-day average was 41.6%. This is not version-bit signaling. Live charts: mainnet.observer. Only coinbases whose nLockTime equals exactly height − 1 are counted — pools that set the field to some other value for their own purposes do not appear here.

What BIP54 fixes

Four related consensus weaknesses, one soft fork

01

Timewarp attack

Stops miners from manipulating timestamps across difficulty periods to drive difficulty toward the minimum.

Risk: A majority-hashrate attacker can bring difficulty down to its minimum within 38 days, arbitrarily raising the block rate and stealing subsidy from future miners.
BIP54: Require a minimum timestamp for the first block of each difficulty period, plus a non-negative period duration.
Simulate this problem →
02

Slow-to-validate blocks

Legacy scripts can be crafted so a valid block takes several minutes to verify on high-end hardware, and up to a few hours on lower-end devices.

Risk: Creates DoS pressure, favors large miners, and pushes out node operators on consumer hardware.
BIP54: Cap legacy signature operations at 2,500 per non-coinbase transaction (~40× better worst-case validation).
Simulate this problem →
03

Merkle tree weakness

A 64-byte transaction is the same size as an internal Merkle node, enabling forged SPV inclusion proofs.

Risk: Lightweight wallets and SPV verifiers can be tricked into accepting a payment that never existed on-chain.
BIP54: Make witness-stripped 64-byte transactions consensus-invalid (also specified in BIP53).
Simulate this problem →
04

Duplicate coinbase risk

BIP30 prevents duplicate txids, but early BIP34 violations mean explicit BIP30 checks must return at block 1,983,702.

Risk: Extra validation cost forever, and designs like Utreexo struggle with BIP30-style checks.
BIP54: Require coinbase nLockTime = height − 1 (and nSequence ≠ 0xffffffff) so uniqueness is built-in.
Simulate this problem →

Official resources

Specs, explainers, live stats, and implementation tracking

Official BIP text

Full specification in the bitcoin/bips repository.

External link ↗
Readable BIP rendering

Human-friendly view of BIP54 on bips.dev.

External link ↗
BIP54.org

Community explainer covering all four fixes and FAQ.

External link ↗
mainnet.observer — BIP54 coinbases

Live chart of the share of blocks with BIP54-compatible coinbase locktimes.

External link ↗
mainnet.observer — first BIP54 coinbase by pool

When each mining pool first mined a BIP54-valid coinbase.

External link ↗
Bitcoin Optech topic

News and technical notes on the consensus cleanup soft fork.

External link ↗
BIPs PR #1800

Pull request that merged BIP54 into bitcoin/bips.

External link ↗
Bitcoin Core implementation PR

BIP54 validation rules (regtest) without mainnet activation.

External link ↗