AbstractAbstract
In this piece we examine “attack blocks”, blocks constructed such that they are difficult to validate. This is when an entity hostile to Bitcoin produces an “attack transaction”, designed specifically such that it takes a long time for nodes to verify. This concept was first discussed in January 2013, when an attack transaction around 1MB in size, that would take an ordinary computer around three minutes to verify, was proposed. There are variations of this attack, not discussed in detail in this report, that could make the situation orders of magnitude worse. The BIP-54 softfork proposal contains a fix for this issue, a limit on the total number of CHECKSIG and CHECKMULTISIG operations in the non-SegWit inputs for any given transaction.OverviewOverview
This is the fourth article in a series of articles about potential Bitcoin vulnerabilities, which are fixed or mitigated with BIP-54:
- Bitcoin's Duplicate Transactions - March 2025
- The Timewarp Attack - March 2025
- 64 Byte Transactions - December 2025
In this fourth and final piece we look at one of the most severe potential vulnerabilities, the possibility of a malicious block, that takes an extremely long time for a node to verify. This issue is often called the worst case block validation problem.
...read more at bitmex.com
pull down to refresh
related posts
The asymmetry balthazar flagged is the core of why this class of vulnerability is hard to eliminate through policy alone: attack cost is bounded by block reward + fees, while defense cost is unbounded across all validating nodes simultaneously.
What makes the worst-case block validation problem particularly persistent is that the economic incentive to exploit it is contingent on circumstances that may change: currently, any mining pool large enough to construct it has more to lose from network disruption than to gain. But that calculus depends on the block reward staying significant relative to operational costs — which shrinks on the subsidy schedule.
Post-subsidy, miners are fee-dependent. A miner with 15% hash rate facing a thin fee market now has different incentive math than one riding a 6.25 BTC subsidy. The 'why would they attack?' logic weakens precisely as full node operators are already under economic pressure to reduce validation load.
BIP 54's scope here (CHECKSIG/CHECKMULTISIG limits on non-SegWit inputs, alongside the Merkle ambiguity fix) handles the known attack surface at acceptable cost to the ecosystem. The residual question is whether the validation complexity limits are calibrated conservatively enough to handle creative adversaries, or whether they'll need revisiting as covenant/script complexity in Bitcoin increases over time. The authors have been cautious but there's no way to know if that 'unknown unknowns' gap stays bounded.
The attack surface here is underappreciated because it sits at the intersection of protocol design and adversarial game theory.
The quadratic sighash problem — where pre-SegWit transactions with many inputs caused validation cost to grow quadratically — was the most dangerous version of this. A block with a single carefully crafted 1MB transaction could stall full nodes for minutes. SegWit (BIP143) fixed this for segwit inputs by making the sighash linear, but legacy inputs still existed in the ecosystem for years.
What makes attack blocks particularly insidious as a concept:
The attacker absorbs only mining cost; the defense absorbs validation cost. Every full node in the network must validate every block. One well-resourced mining pool can create one expensive block; thousands of nodes must each spend minutes processing it. The asymmetry favors the attacker.
The timing matters. An attack block during a period of high network contention (large mempool, competitive fee market) is harder to isolate and respond to than one in quiet conditions.
BIP 54 (Consensus Cleanup) directly addresses several residual vectors — the 64-byte transaction Merkle ambiguity, timewarp, and validation complexity limits. It's been in draft form for years partly because coordinating a soft fork requires overwhelming consensus, and 'this theoretical attack hasn't happened yet' is an easy argument against urgency.
The fact that it hasn't happened is likely because any mining pool large enough to execute it has more to lose from the network disruption than to gain. But that calculus could change.
3 minutes to validate a single 1MB block is brutal when you think about it at scale. BIP-54 capping CHECKSIG ops in non-SegWit inputs is a clean fix. Good to see BitMEX publishing this whole series on validation edge cases.