The Transaction That Could Freeze a Network
You are a node operator in 2015. A new block arrives. You begin validation. One transaction inside it has a thousand inputs, each spending a small UTXO seeded across the chain over the preceding weeks, each requiring a signature check, each of those checks forcing your software to serialize the entire transaction from scratch and run it through SHA-256 twice. Your fan spins up. Your node falls behind the chain tip. Minutes pass.
That is not a hypothetical. It happened.
This is Bitcoin's quadratic sighash problem, a real and exploitable vulnerability that Segregated Witness closed in 2017, and one that rewards closer attention than most post-mortems have given it.
Why the Original Design Produced O(n²) Work
To understand the flaw, you need to understand what a Bitcoin node does when it validates a transaction signature.
Under the pre-SegWit rules, validating any given input's signature requires constructing a special serialized form of the transaction: the sighash preimage. This preimage includes, among other fields, all the other inputs in the transaction, stripped of their scriptSigs and replaced with the scriptPubKey of the input being signed. The node hashes this preimage with SHA-256 twice, then checks the result against the attached signature.
Here is where the geometry turns ugly. If a transaction has n inputs, the node must compute n separate sighash preimages, one per input. Each preimage contains data proportional to n, because it encodes all inputs. Total validation work is therefore proportional to n × n. Quadratic. O(n²).
For a normal wallet sending two or three inputs, this is invisible. The numbers are tiny. But the protocol imposed no hard cap on inputs per transaction, only on total transaction size in bytes. A cleverly constructed transaction can pack a large number of inputs into the maximum block size without those inputs contributing much script data individually. The result: an attacker can engineer a transaction that is technically within the block size limit but demands an extraordinary amount of hashing to validate.
The arithmetic is not subtle. A transaction with 5,000 inputs requires roughly 25 million preimage hash operations. Scale to the theoretical maximum and you are looking at validation times measured in minutes on typical hardware, for a single transaction.
What the Exploit Actually Looked Like in Practice
The attack vector is concrete enough to walk through in detail.
Suppose an attacker creates a transaction with 1,000 inputs, each spending a small UTXO previously seeded across the chain. Each input uses a script requiring a signature with SIGHASH_ALL, the default flag that includes the full transaction in the preimage. The transaction stays within the 1 MB block size limit by keeping individual scripts short. A miner, seeing valid fees, includes it in a block.
Every node on the network now has to validate this block. Each of the 1,000 signatures triggers a full serialization and double-SHA256 of a preimage that itself encodes all 1,000 inputs. That works out to roughly 1,000,000 preimage constructions and hash operations. Stack several such transactions into a single block and you have created something that behaves less like a transaction and more like a tar pit: technically valid, metered in fees, ruinous in compute.
This is not theoretical. Blocks constructed to exploit this property were broadcast on mainnet. Rusty Russell documented some of the worst cases, including one crafted transaction requiring over 25 seconds to validate on then-modern hardware. Bitcoin Core developer jl2012 calculated that a maximally adversarial transaction could exceed several minutes of validation time. Nodes that lagged were effectively partitioned from the network's tip, creating real if temporary instability.
The Two Layers of Risk Most Analysis Skips
Most write-ups stop at "nodes get slow." The deeper risks are more interesting, and any analysis that stops there leaves the more consequential implications on the table.
Consider first the mining incentive distortion. If a miner knows that including a specific transaction will cause competing miners' nodes to stall during validation, that miner gains a measurable advantage: their own node, having already validated the block during construction, proceeds immediately to the next block while competitors are still grinding through hash work. This is a subtle form of selfish-mining amplification, and it does not require the miner to be the attacker. They only need to be willing to include the malicious transaction for the fee.
The denial-of-service angle at the relay layer is equally underappreciated. Nodes relay unconfirmed transactions to their peers before any block confirms them. A node that receives a valid but computationally expensive transaction must validate it before deciding whether to relay it. An attacker broadcasting many such transactions floods the mempool validation queue without ever needing those transactions confirmed. The cost to the attacker is low (small UTXOs, modest fees). The cost to the network is disproportionately large.
That asymmetry is the signature of a real vulnerability, not a theoretical one.
To be precise about scale: Bitcoin's maximum pre-SegWit block size was 1,000,000 bytes. Researchers estimated that a maximally constructed adversarial transaction fitting within that limit could require hashing on the order of 3 gigabytes of data total across all sighash preimages. On typical 2015-era node hardware, that translated to validation times ranging from tens of seconds to several minutes.
How SegWit's Sighash Algorithm Actually Fixes It
SegWit (BIP143) does not merely move signatures outside the transaction structure for malleability reasons. It redesigns the sighash algorithm from scratch.
The key change: instead of serializing the entire transaction freshly for each input, SegWit pre-computes several hash digests once for the whole transaction and then includes those digests in each per-input preimage. Specifically, it pre-computes hashPrevouts (a hash of all input outpoints), hashSequence (a hash of all input sequence numbers), and hashOutputs (a hash of all outputs). Once. Each per-input preimage then references these pre-computed digests rather than re-serializing the full input list.
Total hashing work now scales linearly with the number of inputs: O(n), not O(n²). A transaction with 1,000 SegWit inputs requires roughly 1,000 preimage hash operations, each of constant size. The attack surface collapses.
There is an elegant side effect worth noting here. Because each input's sighash now commits to the amounts being spent (another BIP143 addition), hardware wallets gained the ability to verify they were not being tricked into signing away more funds than displayed. The fix for the quadratic problem bundled a separate security improvement almost for free. That is good protocol design, the kind where solving one problem honestly surfaces another and resolves it in the same motion.
One Honest Caveat: Legacy Inputs Still Exist
SegWit did not eliminate the quadratic sighash problem for all transactions. It fixed it for SegWit inputs. Legacy inputs, those spending pre-SegWit UTXOs, still use the old algorithm. A transaction mixing legacy and SegWit inputs still exposes the legacy inputs to the original O(n²) behavior.
In practice, the share of legacy UTXOs in the active UTXO set has declined steadily since SegWit activated, and the economics of constructing an attack transaction using legacy UTXOs grow increasingly punishing as those outputs get spent. Taproot (BIP341) extended SegWit's linear sighash design to its own input type, further shrinking the attack surface. Anyone reasoning about full elimination of this class of problem should know it remains technically present for legacy inputs.
The other thing worth stating plainly: this vulnerability required specific, deliberate construction to exploit at meaningful scale. Ordinary wallet transactions never came close to dangerous input counts. This was not a bug average users stumbled into by accident. It was a protocol-level design flaw requiring patience, modest capital to seed UTXOs, and willingness to burn fees. Real, but not trivial to weaponize.
Quadratic Complexity Is a Protocol Design Tax
The sighash vulnerability is a clean example of a category of problem that recurs across distributed systems: an operation that looks cheap locally becomes catastrophically expensive when composed at scale by an adversary who controls the inputs. Think of it as a slow leak in a pressurized system, invisible at normal operating conditions, catastrophic only when someone deliberately cranks the valve.
Bitcoin's original designers did not anticipate that transaction validation time could scale super-linearly with size. The block size limit was conceived as a bandwidth and storage constraint, not a computational one. The quadratic sighash problem revealed that computational cost and byte count can decouple badly, and that a protocol needs to bound both independently.
Every blockchain that allows complex scripting or validation logic faces some version of this question. Ethereum's gas metering exists precisely to address it at a different layer. Bitcoin addressed it, for SegWit inputs, by restructuring the sighash algorithm itself.
So ask yourself: if a protocol lets an external party determine the cost of work the whole network must perform, what guarantees that the cost scales predictably? When no such guarantee exists, someone will eventually find the ceiling. The only real question is whether they find it before or after the fix ships.