BIP54.org

How the attack works

Bitcoin adjusts mining difficulty every 2,016 blocks to maintain an average 10-minute block time. However, the current difficulty adjustment compares the timestamps of the first and last block of a period, a span that covers only 2,015 block intervals.

This creates an "off-by-one" bug: the first block of a difficulty adjustment period is different from the last block of the previous period. Miners exploiting the timewarp attack manipulate this gap by:

1. Setting the timestamp of the last block in each difficulty period to the maximum allowed value (up to 2 hours in the future)
2. Setting the timestamp of the first block of the next period to the minimum allowed value (up to several hours in the past, constrained only by Median Time Past)

This timestamp manipulation makes each period appear to have taken longer than it actually did, causing difficulty to decrease. The attack can be repeated indefinitely with a compounding effect, progressively reducing difficulty to its minimum value.

Impact

Once difficulty reaches the minimum, a majority of hashrate could mine blocks as fast as the Median Time Past rule allows which is approximately six blocks per second. At this rate:

• All remaining block subsidy could be mined in roughly 40 days
• Bitcoin's controlled supply schedule would be destroyed
• UTXO set growth, network bandwidth, and validation requirements would spike dramatically with faster blocks, forcing out nodes on consumer hardware and accelerating centralization
• Timelock-based contracts would break, including Lightning Network channels, HTLCs (Hash Time Locked Contracts), and other protocols that rely on nLockTime, OP_CHECKLOCKTIMEVERIFY or OP_CHECKSEQUENCEVERIFY providing a stable measure of time. Accelerated block production would cause timelocks to expire much faster than intended, potentially allowing theft of funds
• Transaction confirmation assumptions like "N confirmations = X minutes of security" would be broken, as confirmations would arrive orders of magnitude faster than expected

BIP54's fix

BIP54 prevents timewarp attacks by requiring a minimum timestamp for the first block in a difficulty period based on the timestamp of its predecessor, the last block of the prior difficulty period. This restriction on shifting the start of a difficulty period precludes the timestamp manipulation across period boundaries necessary for the timewarp attack.

The fix also includes a two-hour grace period after each difficulty adjustment to accommodate natural timestamp variation.

Variants

The Murch-Zawy timewarp variant circumvents the above rule by setting the end timestamps of 2 difficulty periods several weeks into the future to achieve a greater decrease in difficulty by the time the chain is accepted. To ensure the chain is eventually accepted by the wider network and doesn't always have timestamps too far in the future, this attack has to alternate with 1 difficulty period which is closer to the real time, thereby increasing the difficulty momentarily. It therefore takes longer to drain the subsidy.

BIP54 also addresses this variant through requiring that the timestamp of the last block in a difficulty period must be greater than (or equal to) the timestamp of the first block in the same period.

Since in any case, nodes will follow the chain with most cumulative PoW, the attacks above both require 51% control of hashrate. Even if blocks were produced at a higher rate in one fork, the preference for highest cumulative PoW still imposes this constraint on an attacker. These new rules limit the damage that can be inflicted, should an attacker control 51% of the hashrate during a few weeks/months.

Read more: "The timewarp attack" from BitMEX Research

The problem

Legacy Bitcoin transactions (pre-segwit) can be specially crafted to artificially increase their validation times. Various techniques may be used to exploit improper resource usage limits and quadratic behaviour in validation of pre-segwit Bitcoin Script.

An attacker can exploit this to create blocks that can take several hours to validate on lower-end hardware, even though it is valid according to current consensus rules. A variation of this attack is for a miner to delay its competition with blocks that take under a minute to validate but are significantly cheaper to create, to systematically delay its competition.

While most experts would be able to figure out how to create hard-to-validate blocks, details have been discussed in a private Delving Bitcoin thread out of an abundance of caution. A demo was performed on the Signet test network in March 2026.

Attack scenarios

• Denial of service due to nodes spending excessive time validating malicious blocks fall behind the chain tip, making them vulnerable to eclipse attacks or causing them to be partitioned from the network
• Longer block validation and propagation times increase stale rate, disproportionately advantaging larger miners at the expense of smaller ones
• Prohibitive block validation times may:
  • incentivize miners to skip it in favour of non-technical enforcement mechanisms (typically, through legal contracts)
  • Push out node operators using less performant hardware

BIP54's fix

BIP54 introduces a per-transaction limit of 2,500 legacy sigops. This is a conservative limit since normal transactions use far fewer sigops. Even then, reaching this limit requires a transaction that deliberately inflates validation costs, which is the behavior this fix aims to prevent. The limit does not apply to segwit transactions, which represent 90% of today's traffic, since they are by definition not affected by this issue.

The fix reduces worst-case block validation time by approximately 40x while minimizing the risk of confiscating coins locked in unusual legacy scripts. Bitcoin Core has already made transactions exceeding this limit non-standard as a forward-compatibility measure, meaning miners running Bitcoin Core will not include these transactions in their blocks by default.

Read more: "Attack Blocks" from BitMEX Research

The vulnerability

Bitcoin's merkle tree implementation has a flaw in that a 64-byte transaction has exactly the same size as an internal merkle tree node (two 32-byte hashes concatenated). An attacker can construct a transaction whose serialized form is identical to a merkle tree node, allowing them to forge merkle proofs.

How the attack works

Simplified Payment Verification (SPV) verifiers don't download or validate full blocks. Instead, they verify that a transaction is included in a block by checking a merkle proof, a path of hashes from the transaction up to the merkle root in the block header.

By crafting a 64-byte transaction that matches an internal merkle node hash, an attacker can:

1. Create an arbitrarily-sized fake transaction that appears to have valid proof-of-work behind it
2. Present a merkle proof to an SPV verifier showing this "transaction" is confirmed
3. Trick the wallet or verifier into accepting payment that was never actually validated by any full node

The attacker doesn't need to mine blocks or perform expensive proof-of-work. They do need however to perform about 70 bits of work to construct a malicious merkle tree structure and present it to the victim's SPV wallet/verifier.

Impact on SPV wallets and verifiers

This vulnerability undermines the security model of SPV verification and lightweight wallets. While no known real-world losses have occurred, the attack is theoretically sound and exploitable. SPV verifiers are used in various contexts including mobile wallets and other resource-constrained environments as well as by side-systems to validate deposits, making this a concern for Bitcoin's usability and security.

BIP54's fix

BIP54 takes a straightforward approach: make all 64-byte transactions invalid at the consensus level. This prevents anyone from creating transactions that could be confused with internal merkle tree nodes.

This fix is safe because any 64-byte transaction is necessarily insecure: it must contain at most one output, which must either burn the coins or be spendable by anyone. The practical impact is minimal as such transactions are inherently unsafe to use.

The related BIP53 formally specifies the 64-byte transaction ban, which is incorporated into BIP54's broader consensus cleanup.

Read more: "64 Byte Transactions" from BitMEX Research

Historical incidents

In Bitcoin's early history, identical coinbase transactions were actually mined in two separate pairs of blocks:

• Blocks 91,722 and 91,880 (same coinbase transaction)
• Blocks 91,812 and 91,842 (same coinbase transaction)

When the second block in each pair was mined, the UTXO from the first block was effectively destroyed. The coins became unspendable because the UTXO database only keeps one entry per transaction ID. This resulted in permanent loss of 100 BTC (50 BTC from each duplicate).

Why this was possible

Early Bitcoin had no mechanism to ensure coinbase transactions were unique. Miners could create identical coinbase transactions in different blocks, producing the same transaction ID. Since Bitcoin's UTXO set uses transaction IDs as part of the keys, the second occurrence would overwrite the first, destroying the earlier coins.

Additionally, Bitcoin's design assumption that transaction IDs uniquely identify transactions breaks down when duplicates exist, creating potential consensus failures and attack vectors.

BIP30 fixes the vulnerability

BIP30 (activated in 2012) fixed this vulnerability by requiring that new transactions cannot have the same ID as an existing transaction whose outputs haven’t all been spent. This is a stopgap to prevent duplicate coinbase transactions from overwriting existing UTXOs. However, BIP30 requires computationally unnecessary overhead for enforcement for every block. Additionally, alternative full-validation models being explored, like Utreexo, may not be able to perform BIP30 validation at all.

BIP34 (activated in 2013) required coinbase transactions to include the block height in their coinbase field (similar to scriptSig, with different rules), which made coinbase transactions effectively unique. This allowed nodes to skip the expensive BIP30 checks in most cases.

However, BIP34 has a known gap: some early coinbase transactions happened to contain data that matches valid future block heights, meaning BIP30 checks would need to be re-enabled around block 2,000,000 (approximately year 2047).

Why BIP30 needs improvement

While BIP30 successfully prevents duplicate transactions, it has two inefficiencies. First, the checks are computationally expensive. Second, BIP34's gap means that around block 2,000,000, nodes would need to re-enable full BIP30 validation for every block.

BIP54's improvement

BIP54 improves the BIP34 fix to BIP30 by requiring coinbase transactions to set their nLockTime field to the block height minus 1. Since nLockTime is currently unused in coinbase transactions, this adds transaction uniqueness without disrupting existing uses.

This requirement ensures that every coinbase transaction will be unique by construction, closing the BIP34 gap and allowing nodes to permanently skip expensive BIP30 checks. Bitcoin Core's internal miner has already been updated to implement this requirement.

Read more: "Bitcoin's Duplicate Transactions" from BitMEX Research