Two years of competing proposals have pushed Bitcoin toward a critical juncture on block capacity. Groups within the community want to expand transaction throughput through hard-fork changes to the ne
Two years of competing proposals have pushed Bitcoin toward a critical juncture on block capacity. Groups within the community want to expand transaction throughput through hard-fork changes to the network's core code. Hard forks demand that every economically-relevant full node upgrade to a new network version simultaneously. A soft fork operates differently—it maintains backward compatibility and doesn't force this coordinated transition.
Contentious hard forks carry substantial risks. Ethereum's hard fork to rescue DAO token holders showed how acrimonious this path becomes. Yet a sufficiently contentious soft fork can produce the same outcome: users and miners splitting away, creating multiple Bitcoin versions that coexist indefinitely, much like Ethereum and Ethereum Classic do today.
This debate doesn't pit hard-fork purists against soft-fork absolutists. The disagreement centers on preference for specific upgrades. Segregated Witness exemplifies the tension. Some argue it should become a hard fork rather than soft fork.
Johnson Lau, a Bitcoin Core contributor, posted a BIP draft to the development mailing list proposing soft-fork block expansion through extension blocks. The idea isn't novel. Past discussions on the mailing list have examined it. Adam Back, Blockstream's CEO, discussed the concept publicly in 2015. When Bitcoin released SegWit, Back saw it as a form of extension block.
"SegWit is kind of a simplified extension block, where signatures only are in it," Back told MiningPool. "With a full extension block, you put the whole transaction in it."
Extension blocks demand broad community consensus but appeal more to developers and investors leery of hard forks. Coordinating hard forks across distributed nodes presents substantial logistical friction. Extension blocks share some properties with sidechains yet differ fundamentally. A sidechain operates as a separate blockchain. An extension block functions as part of Bitcoin's core network.
Full nodes validate transactions in extension blocks, eliminating the two-way peg system that sidechains require. With sidechains and drivechains, a miner majority can potentially steal stored bitcoins. Paul Sztorc, creator of Bitcoin Hivemind and an economist at Bloq, believes his drivechains proposal addresses this vulnerability. Extension blocks bypass the problem entirely because full nodes validate both layers.
"Because everyone validates everything, of course they know [when] funds are locked or destroyed," Lau said.
Back and Lau agree that extension blocks serve straightforward Bitcoin modifications. Complex features belong elsewhere. A sophisticated extension block jeopardizes the main chain's security.
"A sidechain is very independent, it's a separate daemon, and has no consensus connection," Back explained. "Even an RSK-like side chain could be [an] extension block, but that means we are bringing the risks of RSK to bitcoin," Lau added.
RSK, a complex smart contracting system in development as a hybrid drivechain, mirrors Ethereum. Extension blocks and sidechains in the block size context offer a middle path. Users wanting to maintain 1MB blocks don't need the extension block. Those preferring 8MB or higher can opt in.
Hard-fork advocates cite two primary arguments. First, soft forks accumulate technical debt. Second, they concentrate upgrade authority among developers and miners at users' expense.
SegWit critics call it an inelegant hack introducing unnecessary codebase complexity that hampers future development. Bitcoin Core maintains that SegWit removes existing technical debt, particularly transaction malleability.
SegWit's added complexity surfaces concretely. Exchanges and wallet providers must track two transaction IDs, different addressing paths, and additional variables for each transaction if they implement the upgrade.
"Ultimately, you don't have a clean upgrade from A to B. You upgrade from A to a situation where you have A and B coexisting for months and years into the future," Jeff Garzik, Bloq's CEO and former Bitcoin Core contributor, said at an OnChain Scaling Conference presentation last summer.
More intricate code opens doors to unforeseen vulnerabilities. SegWit underwent testing on three custom testnets and the main testnet before its release in a Bitcoin Core version. No real funds faced risk on those testnets. Some question whether Litecoin could serve as an effective testnet for Bitcoin, with genuine money at stake, if SegWit activates there first.
On authority and governance, Garzik raised concerns in a Bitcoin Uncensored interview. "That is the key, underlying parameter—being able to upgrade the system in a way that allows people to have a voice, to have a say, in that upgrade," he said.
Garzik supports SegWit but prefers a hard fork path. "I think it would be far better as a hard fork because if you introduce changes in pricing [or] economics and you do that through a tiny set of people (a couple developers and a couple of miners), then that is really that antithesis of what Bitcoin was meant to be."
In Garzik's view, soft forks don't distribute power appropriately among developers, nodes, miners, and the broader economy. Developers and miners control protocol decisions.
"I think it's a mistake to enoble a high-priesthood of Bitcoin and say, 'Just these hallowed few will make decisions for everyone,'" Garzik said. "Also, I think it's a mistake to assume technical experts are also economic experts . . . That's not the Bitcoin we all bought into in 2010."
Users retain options against soft forks. They can reject them by hard forking away from miners. They can decline the soft-forking upgrade. Garzik called soft forks "voluntary upgrades."
If soft forks are voluntary, where's the coercion? The distinction matters. While users aren't forced to upgrade, non-upgraded nodes suffer degraded security after soft fork activation. Old nodes stop validating new system rules. Some view this degradation as coercive.
Some Bitcoin Core contributors acknowledge soft forks can occupy coercive territory. These developers generally conclude SegWit doesn't cross that line.
On degraded security for non-updated nodes post-SegWit, Bitcoin Core contributor Nicolas Dorier responded on Twitter: "A miner who is ready to [lose] 12.5 BTC can make a non-upgraded user [believe] he got 1 [confirmation] for 10 minutes."
Lau points out that accepting 12.5 BTC on one confirmation poses risks regardless, due to natural blockchain reorganizations. BIP 9, the Bitcoin improvement proposal governing soft fork rollouts, includes a warning system. Full nodes receive alerts three weeks before soft fork activation.
A similar security tradeoff occurred during BIP 16's activation. "I think such [a] temporary degrade has been proven as acceptable," Lau told MiningPool.
Garzik also noted that SegWit prevents predictable block space economics. The block size limit increases as individual wallet providers implement the upgrade, not when the network activates the change.
These soft fork concerns merit discussion. Whether they outweigh soft forks' backward compatibility benefits and voluntary opt-in structure remains unclear. That question sits at the core of the debate.
The hard fork versus soft fork discussion centers on tradeoffs. Each mechanism carries advantages and costs. Neither operates without compromise. The path forward likely means selecting the option with fewer drawbacks.
