Your node is grinding. One transaction came in, perfectly valid under every rule the protocol recognizes, and now your modest machine has been chewing on it for three minutes while the rest of the network moves on without you.
That is the quadratic hashing problem. It was real, it landed on mainnet, and tracing the exact mechanics tells you something that most Bitcoin commentary skips entirely: consensus rules can be locally valid and globally ruinous at the same time.
The Signing Formula That Didn't Scale
When a node verifies a Bitcoin transaction, it must compute a sighash for every input: a digest of transaction data checked against that input's signature. Under the original pre-SegWit serialization, each input requires hashing the entire transaction. Every input, every output, serialized fresh, for each input being checked.
So if a transaction has N inputs, the verifier hashes roughly N copies of the full transaction body. And because the body is large precisely because it has N inputs, each copy is itself proportional to N. Work grows as N squared. That is where the name comes from.
Put figures to it. A transaction with 10 inputs might require hashing around 10 kilobytes total. Manageable. A transaction with 1,000 inputs, each referencing a non-trivial script, could require hashing several gigabytes of data, even while the transaction itself sits inside the one-megabyte block limit. The block size cap protected against storage bloat. It said nothing about verification cost.
A Worked Scenario
In July 2015, researcher Rusty Russell documented exactly this on the Bitcoin mainnet. A transaction carrying 5,569 inputs, later nicknamed the "megatransaction," required nodes to hash approximately 25 gigabytes of data to fully verify. Some nodes took minutes. Block propagation times spiked visibly. It was not a theoretical demonstration.
Picture the mechanics concretely. A malicious actor constructs a transaction with 5,500 inputs, each spending a tiny UTXO worth a few satoshis, each scriptSig kept compact enough to land just under the 1 MB limit. On paper: valid. A well-specced server clears it in roughly 25 seconds. A modest node takes over three minutes. Now imagine a block containing several such transactions. The modest node falls behind the chain tip, effectively partitioned from the network until it catches up, and an attacker producing blocks like this consistently could isolate specific nodes at a cost that is low relative to the disruption caused.
The block size limit, intuitive as a defense, is the wrong tool for this problem entirely. It constrains the serialized size of data as it sits on disk. A 900 KB transaction with 1,000 inputs still forces the verifier to compute 1,000 sighashes, each covering most of those 900 KB: roughly 900 MB of hashing work from a single 900 KB object. Block size and validation cost are two separate resources. Capping one does not cap the other, and conflating them is a mistake I have seen made in otherwise careful technical writing.
How SegWit Closed the Door
Segregated Witness introduced a new transaction serialization format defined in BIP143. The change sounds like a bookkeeping adjustment. It is actually structural.
Under BIP143, the data committed to in each input's sighash is not the full serialized transaction. Instead, several fields (the hash of all outpoints, the hash of all sequences, the hash of all outputs) are computed once and then reused across every input. Each input's sighash references these precomputed values rather than reserializing the entire transaction body from scratch. Think of it as replacing a process where every diner at a hundred-person table reads the entire menu aloud before ordering, with one reading shared by all.
The result is linear scaling. A transaction with 1,000 SegWit inputs requires roughly 1,000 units of work, not 1,000,000. The attack surface collapses.
And here is the question worth sitting with: why did it take an on-chain incident to accelerate the fix? The mathematics were not obscure. The answer, I think, is that Bitcoin's development culture rightly demands demonstrated risk over theoretical risk before touching consensus rules, which is defensible as a principle even when it means absorbing one live hit.
One Honest Caveat
SegWit does not eliminate the problem for legacy inputs. Anyone holding a large set of pre-SegWit UTXOs and constructing a transaction spending thousands of them still exposes verifying nodes to the old quadratic cost. Bitcoin Core introduced additional validation limits over the years, including per-transaction sigop caps and heuristic checks, that make the worst-case attacks harder to execute cheaply. But the underlying math for legacy inputs has not changed.
The practical risk is low because the economic incentive to move coins to SegWit addresses is strong: lower fees, same security. The legacy UTXO set keeps shrinking as coins move and get respent under the new rules. "Low risk" and "zero risk" are not the same sentence, and treating them as such would be imprecise.
Taproot, extending the BIP143-style linear sighash to its own output type, continues the same design principle forward. Each generation of Bitcoin's scripting system has been an opportunity to correct what the previous one left exposed.
The megatransaction broke no rule that existed in 2015. It simply cost far more to verify than to create. Closing that gap between creation cost and verification cost is, quietly, one of the longest-running engineering projects underneath Bitcoin's surface, and it is nowhere near finished.