Thunder: The Drivechain That Ended the Blocksize War

June 22, 2026 · 13 min read

The blocksize war is the most consequential internal conflict in Bitcoin's history. It split the community into two camps that have not had a civil conversation since 2017. It produced multiple hard forks, several lawsuits, an ongoing trial-by-Twitter that destroyed dozens of reputations, and a culture of mutual ostracism that made certain technical conversations literally impossible to have in public.

It also produced, eventually, a synthesis. Paul Sztorc's design for Thunder (a high-volume payments sidechain that runs as a drivechain on Bitcoin) resolves the central technical dispute of the war by giving both sides exactly what they actually wanted, on different chains. Thunder is one of the most important and least understood products of the decade-long argument, and understanding it requires understanding the argument it solves.

What the war was actually about

The shorthand version of the blocksize war is that one side wanted bigger blocks and the other side wanted smaller blocks. This is true but misleading. The deeper disagreement was about what Bitcoin is for.

The bigblocker faction, led publicly by figures like Roger Ver, Gavin Andresen (at the time) and later Amaury Séchet, believed Bitcoin was designed primarily as a payment system. Satoshi's whitepaper, after all, was titled "A Peer-to-Peer Electronic Cash System." If Bitcoin's blocks were too small to accommodate the world's transaction volume, the result would be unusable fees, abandoned merchants, and Bitcoin's eventual marginalization. Their proposal was to increase the block size limit incrementally, allowing throughput to grow as adoption grew, accepting the trade-offs that came with larger blocks.

The smallblocker faction, led publicly by figures like Adam Back, Greg Maxwell, Luke Dashjr and the Bitcoin Core development team, believed Bitcoin's primary value was its decentralization... meaning specifically that ordinary individuals running ordinary hardware should be able to validate the entire chain. Large blocks would mean larger nodes would mean fewer node operators would mean centralization. Their proposal was to keep the L1 small and conservative, with scaling happening on Layer 2 protocols: most famously Lightning Network.

Both sides had legitimate points. Both sides also exaggerated their opponents' positions into caricatures. Big blockers were accused of wanting to destroy decentralization for the sake of cheap coffee purchases. Small blockers were accused of wanting Bitcoin to be a settlement-only asset for the wealthy, abandoning ordinary users. Neither caricature was accurate. Both factions contained serious technical thinkers who understood the trade-offs and disagreed about which trade-offs mattered most.

The war ended inconclusively in 2017. SegWit activated as a soft fork, providing modest capacity gains. Bitcoin Cash forked off to pursue larger blocks. The small blockers won the social war on the main chain, the big blockers created their own chain, and then the two sides stopped talking. Lightning Network was promoted as the official scaling answer, and a decade of delayed deployment began.

Paul Sztorc's unusual position

In a war that demanded loyalty, Sztorc refused to enlist. He did not write essays denouncing big blockers. He did not write essays denouncing small blockers. He maintained respectful working relationships with serious thinkers on both sides: with Adam Back at Blockstream, with Roger Ver before his deeper drift into hostile rhetoric, with Amaury Séchet during the Bitcoin Cash years, with Greg Maxwell when Greg was still active in Bitcoin development.

This was professionally costly. Bitcoin culture in the post-war years rewarded tribal signaling. Anyone seen talking to "the other side" was suspected of disloyalty or worse. Sztorc absorbed those costs because he believed, correctly, that the technical disagreement underneath the political war contained real information, and that the synthesis was findable if anyone bothered to look for it.

His approach was simple: take seriously what each side actually said when arguing in good faith, identify what they were really worried about, and design a system that addressed both sets of concerns simultaneously.

From the small blockers, Paul Sztorc absorbed three substantive concerns.

• Bandwidth: that large blocks impose costs on node operators that scale linearly, eventually pricing out small participants.

• Validation complexity: that nodes need to verify every transaction in every block, and growing block size means growing validation cost.

• Long-term decentralization: that even if a single block size increase seems harmless, the political process that produces one increase will produce more, ratcheting node requirements upward indefinitely.

From the big blockers, Paul Sztorc absorbed three different substantive concerns.

• Throughput: that 7 transactions per second cannot serve a global user base, and pretending otherwise is wishful thinking.

• Fee predictability: that variable, unpredictable fees make Bitcoin unusable for commerce and discriminate against poorer users.

• Onboarding friction: that Layer 2 solutions like Lightning impose complexity costs that exclude the very users they're supposed to serve.

Each concern was legitimate. Each was held by serious people with technical reasons for holding it. The mistake of the blocksize war was assuming the concerns were mutually exclusive, that solving one set meant abandoning the other.

The synthesis: Thunder

Thunder is Paul Sztorc's answer to the war. The design is described in detail in his 2021 essay of the same name on truthcoin.info, and it deserves more attention because there's quite a lot going on.

The core insight is architectural. The blocksize war assumed there could be only one chain making one set of trade-offs. If you wanted big blocks for throughput, you had to accept the centralization costs. If you wanted small blocks for decentralization, you had to accept the throughput costs. The trade-offs were genuinely real, but the assumption that they had to be made on a single chain was false.

Thunder is a sidechain. Specifically, it is a drivechain: a sidechain secured by Bitcoin's miners through blind merged mining, with cryptographic two-way pegging to the main chain through BIP-300. This means Thunder can make completely different trade-offs from the L1, without affecting the L1 at all.

The trade-offs Thunder makes are exactly the ones big blockers wanted:

• Large blocks. Thunder targets blocks orders of magnitude larger than Bitcoin's L1, supporting throughput at the level of Visa or beyond.
• Optimized for payments. Thunder's design is laser-focused on the high-volume, low-fee payment use case that motivated the bigblocker faction in the first place.
• No Lightning complexity. Thunder transactions are simple on-chain transfers within the sidechain. No channels to manage, no liquidity to balance, no watchtowers to monitor.

Meanwhile, the trade-offs the L1 makes are exactly the ones small blockers wanted:

• Small blocks. Bitcoin's L1 remains conservative, with the existing block size limit and the existing validation requirements.
• Maximum decentralization. Anyone with a Raspberry Pi can still run a full Bitcoin L1 node.
• Settlement-focused. The L1 handles inter-sidechain settlement, large transactions, and the cryptographic anchoring that secures the entire system.

Users who want fast, cheap payments use Thunder. Users who want maximum decentralization use the L1. Both groups get what they wanted. The architectural decoupling resolves the dispute.

Why Lightning wasn't this answer

A natural question is why Lightning Network, the small blocker faction's preferred scaling solution, did not already accomplish what Thunder accomplishes. The answer reveals the deeper problem with the post-war consensus.

Lightning makes different architectural commitments. It is a payment channel network, not a sidechain. It requires users to lock funds in channels, manage liquidity, run always-online nodes, and handle a level of operational complexity that has proven incompatible with mainstream adoption. The bigblocker complaint about onboarding friction applies to Lightning with full force.

Lightning also fails to address several concerns that even small blockers should care about. It does not capture transaction fees for L1 miners: Lightning fees flow to channel operators and LSPs, not to the hashrate securing the system. It does not provide a programmable execution environment for non-payment use cases. It does not allow experimentation with different cryptographic schemes or consensus rules without forking the protocol.

Thunder addresses all of these. As a drivechain, it generates fees that flow to Bitcoin miners through blind merged mining. As a sidechain, it can implement any rules its designers choose. As an on-chain system within the sidechain, it imposes no operational complexity on users beyond what they already manage on the Bitcoin L1.

In other words, Thunder is not just an alternative to Lightning. It is the version of Lightning that would have worked, if Lightning's designers had been willing to use a sidechain architecture instead of a payment channel network.

The diplomatic achievement

The technical achievement of Thunder is significant. The diplomatic achievement is arguably greater. Sztorc designed a system that gives both factions of a hostile decade-long war what they actually wanted, without requiring either side to admit defeat.

The bigblockers can have their large blocks, their high throughput, their low-fee payment chain. They get this on Thunder, without having to argue that Bitcoin's L1 should adopt their preferred trade-offs.

The smallblockers can keep their small L1, their conservative consensus, their decentralized validation. They get this on Bitcoin's main chain, without having to argue that high-volume payments are unimportant.

Neither side has to publicly retract anything. Neither side has to admit that the other side's concerns were valid. The architecture simply makes the debate moot by providing both outcomes simultaneously.

This is, in a sense, the model for how all technical disputes in cryptocurrency should be resolved. Most arguments are not really about technical trade-offs; they are about which trade-offs a single shared chain should make. Once you accept that different chains can make different trade-offs, and that they can be cryptographically connected without conflicting, most disputes dissolve.

The deep lesson of Thunder is that you can usually have both. The architectural assumption that one chain has to make one set of trade-offs is what creates the appearance of irresolvable conflict. Drop the assumption and the conflicts evaporate.

What Thunder makes possible

Beyond ending the blocksize war, Thunder has practical consequences that the previous decade missed.

• For merchants, Thunder makes Bitcoin payments commercially viable at scale. Low fees, fast confirmations, predictable costs, no Lightning channel management. A merchant can accept Thunder payments the way they currently accept Stripe, with a similar user experience but without the 3% fee and with cryptographic settlement finality.

• For remittances, Thunder addresses the use case Lightning was supposed to address but never quite reached. A worker in San Francisco can send fifty dollars to family in El Salvador for cents in fees, with confirmation in seconds, without needing either party to understand channel management.

• For micropayments, Thunder unlocks economic models that were impossible on the Bitcoin L1 and impractical on Lightning. Paying per-article for news, per-minute for streaming, per-query for AI services: all of these become trivially viable at Thunder's fee levels.

• For miners, Thunder generates substantial sidechain fees that flow back to Bitcoin's hashrate through blind merged mining. The "miners get paid twice" thesis applies most strongly to a high-volume payments chain, because payment chains generate enormous transaction counts even at low per-transaction fees.

• For the broader Ecash ecosystem, Thunder demonstrates the model. If a payments-focused sidechain can succeed, the same architecture works for privacy sidechains, smart contract sidechains, prediction market sidechains, and any other use case the cypherpunk imagination can devise. Thunder is the proof of concept for the entire drivechain thesis.

Why this took a decade

A reasonable reader will ask: if the synthesis was findable, why did it take a decade to find?

Part of the answer is that Sztorc found it years ago. The core design has been public since 2015. The Thunder essay that crystallized the framing was published in 2021. The technical work was done; the political work was not.

The political work required two things that Bitcoin culture systematically discouraged. First, it required listening to both factions seriously; which marked anyone who did so as suspicious to both. Second, it required patience to wait for the political moment when the synthesis could actually be deployed... which meant absorbing a decade of being right and ignored.

Paul Sztorc did both, while the rest of the community spent the decade fighting a war that had been technically over since at least 2018. The cost was years of his career spent on what looked, to outsiders, like irrelevant academic work. The payoff is that Ecash is positioned to ship the synthesis at exactly the moment Bitcoin's political system has finally proven unable to ship anything else.

What the big blockers should know about Thunder

If you fought on the big blocker side of the war (if you ran a Bitcoin Cash node, or supported XT or Classic or Unlimited, or simply believed that on-chain payments mattered) Thunder is the design you should have been advocating for.

It gives you everything the blocksize increase was supposed to give you. It does so without requiring you to abandon Bitcoin's security model, without forking off into an isolated community, and without giving up the network effects of the Bitcoin name. You get to be right about everything you cared about, and you get to be right about it on a chain that inherits Satoshi's original UTXO set.

The fact that this design was developed by someone who never picked your side (who treated Adam Back and Greg Maxwell with the same respect he treated you) is a feature, not a bug. It is the reason the design is viable. Tribal allies could not have built it because their tribalism would have demanded ideological purity. Paul Sztorc was free to build it because he was free of the tribalism.

What the small blockers should know about Thunder

If you fought on the small blocker side (if you supported Core, if you believed in Lightning, if you considered the big blockers a threat to Bitcoin's decentralization), Thunder is also the design you should be supporting.

It preserves everything you cared about on the L1. The block size limit stays. Validation costs stay constant. Decentralization remains protected. Your Raspberry Pi can still run a full node in 2040 the way it can in 2026.

What Thunder gives you, additionally, is the answer to the legitimate complaint that Bitcoin cannot serve the world's payment volume on the L1 alone. You no longer have to defend Lightning's failures as the only alternative. You can say, with technical honesty, that Bitcoin scales... just not on the L1, and not through Lightning, but through dedicated sidechains optimized for specific use cases. Thunder is the existence proof that the smallblocker position is compatible with a chain that actually scales.

The architectural lesson

The single most important thing about Thunder, beyond its specific design, is the architectural lesson it teaches. You can resolve fundamental technical disagreements by accepting that different chains can make different trade-offs.

This applies far beyond the blocksize war. The privacy debate (whether Bitcoin should adopt confidential transactions, ring signatures, ZK SNARKs, or other privacy enhancements at the L1 level) dissolves the same way: build a privacy sidechain. Users who want privacy use it. Users who want maximum L1 transparency stay on the L1. Both get what they want.

The smart contract debate dissolves the same way. The tokenization debate dissolves the same way. The high-frequency trading debate dissolves the same way. Every architectural disagreement that has ever fractured the Bitcoin community can, in principle, be resolved by deploying the contested feature on its own sidechain and letting users choose.

This is the deep promise of the drivechain architecture, and Thunder is its first concrete demonstration. The blocksize war was fought because everyone assumed it had to be fought on a single chain. It did not have to be. It does not have to be, in the future, for any analogous dispute.

Paul Sztorc designed the architectural escape from Bitcoin's political deadlock. Thunder is the first chain through that escape. Everything else that ships on Ecash (the privacy sidechains, the prediction markets, the smart contract platforms, the use cases not yet imagined) is following Thunder's path.

The blocksize war ended in 2017 with a stalemate that exhausted both sides. It is finally ending properly, nine years later, with Thunder shipping the synthesis on Ecash. The vindication is not just that Paul Sztorc was right. The vindication is that he was right in a way that lets everyone else also be right, on their own terms, on their own chains, secured by the same hashrate.

That is what synthesis looks like. That is what patience produces. That is what Thunder is for.