If one proposal excited attendees at the recent Scaling Bitcoin workshop in Hong Kong, Bitcoin Core and Blockstream developer Dr. Pieter Wuille’s Segregated Witness was it. Praised by many within the technical community, Segregated Witness is expected to improve Bitcoin’s performance in a number of ways, while some even hope it might be the scaling solution that helps bring some peace back to the Bitcoin community.
The first and second parts of our three-part Segregated Witness series covered how it works and what it does. In this final part we explore what it means for the block-size dispute.
What is the block-size dispute again?
To see what Segregated Witness means for the block-size dispute, let’s first recap what the block-size dispute is. (Note that this is not an analysis of the arguments; just an explanation of them. If you’re well aware of these arguments, feel free to skip to the next section.)
In essence, the block-size dispute represents a trade-off between throughput and decentralization – with a touch of economics involved. The current 1 megabyte block-size limit allows the Bitcoin network to process up to seven transactions per second. “Block-size Progressives” consider this much too low; as on oft-cited comparison, Visa can process thousands of transactions per second.
Undersized blocks, progressives fear, could limit Bitcoin’s potential and increase the cost of transacting on the blockchain to the point where only centralized services will utilize it, or lead to users moving to alternative payments systems, or perhaps even cause a total failure of the system.
On the other end of the spectrum, Bitcoin’s “Decentralists” fear that increasing the block size too much could further centralize Bitcoin on a protocol level in several ways. For one, larger blocks take longer to propagate from one node to the next, and take longer for each individual node to verify, which further increases networkwide propagation time. This benefits miners (or pools) who find more blocks, as it means they get a head start mining on top of all blocks they find. Decentralists worry this would centralize mining into fewer pools.
Furthermore, larger blocks would increase the cost of running a full node, as it would require more bandwidth, more processing power, and more disc space to do so. This complicates using Bitcoin in a trustless manner, where users verify all transactions against the consensus rules they signed up for. Instead, it incentivizes users to trust others to verify consensus rules for them; another centralizing force.
Most Decentralists also believe some sort of block-size limit is required as an economical tool to create scarcity in blocks. This scarcity is needed, they think, to prevent a tragedy of the commons type of situation, where miners end up in a downward spiral undercutting each other’s fees to the point where transactions are almost free. If transactions are almost free, miners will be unable to earn enough to properly secure the network.
Some Block-size Progressives believe fee pressure will establish naturally. Adding transactions increases the size of blocks, which would increase the orphan rate of outgoing blocks. This would make sure miners charge enough fees to make up for the added risk. Decentralists, however, argue this dynamic will simply result in another incentive to centralize mining, as that would prevent orphaned blocks altogether.
All of these centralizing forces, Decentralists say, could open the door to regulation of Bitcoin on a protocol level. Regulation on a protocol level, in turn, could harm Bitcoin’s censorship resistance, and therefore Bitcoin’s core value proposition.
While Decentralists acknowledge that smaller blocks limit the number of transactions that can be processed on Bitcoin’s blockchain, they typically envision a future where bitcoin – the currency – is transacted over added layers, such as the Lightning Network, treechains and more.
Block-size Progressives generally like these types of additional layers, too, but not as a solution for scalability. They typically believe Bitcoin should be designed to scale “on-chain” first.
What does Segregated Witness mean for Bitcoin’s scalability?
As shown in the previous article, Segregated Witness affects Bitcoin’s scalability in several ways. It solves transaction malleability, allowing added scaling layers to be rolled out faster and better. It enables Fraud Proofs, which improve SPV-node security to a certain extent. It allows discarding of old signature data, decreasing the cost of running a full node. It introduces version bytes, potentially making it easier to improve scalability in the future.
And, of course, most directly related to the block-size limit, Segregated Witness could effectively increase Bitcoin’s block size without increasing Bitcoin’s block-size limit. To be precise, Wuille’s proposal would allow for blocks up to some 2 megabytes of real transactions – or 4 megabytes if a miner fakes transactions designed to max out the potential.
Unfortunately, this means that most improvements offered by Segregated Witness – while great – don’t fundamentally solve the block size dispute. Fixing transaction malleability is fantastic, but Block Size Progressives don’t accept the Lightning Network as a scalability solution. Fraud Proofs are useful, but SPV-nodes will still not be as secure as full nodes. Discarding old transaction data helps, but Bitcoin Core was rolling out similar solutions even before the introduction of Segregated Witness. And version bytes could come in very handy in the future, but these effects remain to be seen.
Segregated Witness and the block-size limit
The question, therefore, is whether the effective block-size increase as offered by Wuille’s Segregated Witness proposal satisfies both Decentralists and Block-size Progressives. Or – more specifically – whether 2 megabytes is large enough for Block-size Progressives, since Segregated Witness would allow up to 2 megabytes of real transaction data. And whether 4 megabytes is conservative enough for Decentralists, as large miners trying to outplay smaller competitors could produce 4-megabyte blocks.
One of the interesting things about Segregated Witness, is that it is an “opt-in” solution. It’s up to individual users to decide whether they want to upgrade their software to incorporate it. Users who want to use Segregated Witness can do so, and will get a “discount” on fees, as they’re effectively using less of the scarce block space. And users who don’t want to use Segregated Witness because of the increased cost of running a full node, don’t have to. As such, at least one part of the Decentralist concern – the increased cost of running a full node – is solved.
Another part of the Decentralist concern – increased propagation time – is a bit more complicated. But Wuille – himself a Decentralist – does not think the increased block size will cause problems.
Because of how Segregated Witness nodes are verified, the added verification time for individual nodes is expected to be negligible. And while propagation time from node to node might increase a bit, Wuille’s simulations suggest that the 4 megabyte maximum block size is within bounds of what the network can currently safely handle (but just barely).
As such, and because of the added advantages, most Decentralists support Segregated Witness as a vital part of a scalability “road map,” as set out by Bitcoin Core developer Gregory Maxwell. Similar to Core developer Jeff Garzik’s BIP 102, Wuille’s proposal could provide for a temporary bump to win time before blocks fill up (if Segregated Witness works and is used as intended) – but without breaking any of the existing consensus rules.
Decentralists want to utilize this added time to work on long-term solutions, including a more durable block-size policy (perhaps flexcaps), additional scaling layers, and other optimizations.
Most Block-size Progressives, however, don’t consider an effective increase to 2 megabytes sufficient. For comparison, Bitcoin XT and Bitcoin Core developer Gavin Andresen’s proposed solution, BIP (Bitcoin Improvement Proposal) 101, starts with a block-limit increase to 8 megabytes, and is set to double every other year for 20 years until it reaches 8 gigabytes.
An earlier proposal by Andresen would have raised the maximum block size to 20 megabytes – which he already considered a compromise.
Moreover, (pessimist) estimates by some Block-size Progressives predict it could take as much as a year before Segregated Witness can start to function as a relief valve for transaction data. Because of that, some developers erring to the side of Block-size Progressives, including Garzik, prefer a networkwide switch to increase the block-size limit, even before Segregated Witness is deployed.
And that brings us to the main issue.
On hard forks and soft forks
One of the most interesting aspects of Wuille’s Segregated Witness proposal is that it can be rolled out without breaking any of the existing consensus rules. As such, the proposal can effectively be enforced by miners only. This is called a soft fork.
A soft fork contrasts with a hard fork. A hard fork breaks the existing consensus rules, and requires all nodes on the network to implement the change. Every node that does not implement the change will be forked off the network. This could even result in two separate networks; two different types of Bitcoin. (If and how long such a situation would persist is up for debate.)
Increasing the block-size limit (the “old-fashioned way”) can be done only through a hard fork. As such, there must be consensus among all of Bitcoin’s user-base that a block-size limit increase is the best way forward.
Absent consensus, a segment of Bitcoin’s user base can attempt a hard fork, presumably hoping the rest of the user-base will implement the change after the fact. But if the rest of the user-base does not follow, the network will split. One such strategy was recently employed by R3CEV developer Mike Hearn and former Bitcoin Core lead developer Gavin Andresen through Bitcoin XT, but has not reached sufficient support so far.
Furthermore, some developers – often (but not always) those in favor of increasing the block size limit through a hard fork – prefer to deploy Segregated Witness as hard fork as well. This has several advantages over a soft fork.
First, a hard fork intends to make sure all nodes on the network adhere to the exact same rules. As such, full nodes verify whether all transactions are valid according to these rules, even transactions that do not involve their bitcoin.
Second, a hard fork would be a “cleaner” solution. While Wuille’s Segregated Witness proposal, for instance, uses a clever trick to avoid breaking the existing consensus rules, it does so by utilizing parts of Bitcoin’s protocol – the coinbase transaction’s input – in ways it wasn’t intended. Some fear that this added complexity could cause new problems in the future.
And third, because of this clever but atypical workaround, writing Bitcoin compatible software (like wallets) can be a bit more complicated.
Other developers – often (but not always) those who favor of a more conservative block-size approach – believe hard forks should only be deployed as the last available measure. The inherent risk of a hard fork, a split of the network, is something they want to avoid if at all possible. And if a hard fork must happen, for whatever reason, they maintain this should be announced and organized very far in advance to make sure every single user has had the chance to upgrade.
A soft fork, on the other hand, can be rolled out as soon as the code is ready and vetted, and miners agree. The rest of Bitcoin’s user base can upgrade if and when it pleases.
So where does that leave us?
What it comes down to, in the end, is not whether a hard fork – either to increase Bitcoin’s block size or to implement Segregated Witness – is objectively good or bad. Neither Bitcoin nor any of its developers can force Bitcoin’s user base to adhere to new consensus rules that break the existing consensus rules – that’s by design.
The real question, therefore, is whether a potential hard fork can reach consensus-support among Bitcoin’s user base. And while “consensus” is considered a vague requirement by some, few will maintain that a hard fork solution has reached consensus as of yet.
The most likely path forward for now, therefore, seems to be Maxwell’s road map. That’s the only path that does not require a hard fork any time soon, and it has been endorsed by a large segment of Bitcoin’s development community. As such, it now really only requires support from a majority of hash power.
But another hard fork attempt – perhaps by prominent industry players – can’t be ruled out. And, of course, Bitcoin XT is still out there as well.
At publication time of this article, the debate on Segregated Witness and scalability is not quite settled yet; for more discussion, see the Bitcoin development mailing list.TAGS