买它！

The Blocksize War – Chapter 5 – SegWit

In the first session of the second day of Scaling Bitcoin Hong Kong, during one of the prime slots, Bitcoin developer Pieter Wuille gave a talk on something called Segregated Witness (SegWit). SegWit is a way of increasing the Bitcoin blocksize, without the new client being incompatible (i.e. it was a softfork rather than a hardfork). A Bitcoin transaction consists of various components, one of which is the signature, authorising the spend. This signature is typically the largest part of the transaction, based on the amount of data. SegWit was a new transaction format, where the signature would not need to be included in the old block, which still had a 1 MB limit. Clients that upgraded to SegWit would see a new block, which included these signatures; for these newer clients, the old 1 MB blocksize limit was removed and replaced by a 4 million unit “weight limit”. The weight limit was defined as four times the amount of non-signature data in bytes plus the amount of segregated signature data, in bytes. This meant that the signature data received a discount in the calculation, but the overall limit would be around 2 MB, which is of course what many people seemed to want: a blocksize limit increase to around 2 MB.

A Florida-based Bitcoin developer called Luke Dashjr had figured out a hack, which made SegWit possible as a compatible (softfork) Bitcoin upgrade. Luke was regarded as one of the most extreme small blockers and was another hate figure in the large block community, alongside Gregory Maxwell. Luke was not at all scared of standing out from the crowd with his non-consensus opinions. To some extent, the committed Catholic and father-of-seven was the Cassandra of the technical community; exceptionally strident. However, Luke clearly had a very strong technical understanding of Bitcoin, and his apparent non-linear thinking, which made him see things differently from others, may have helped him conceive of this hack that the other developers couldn’t quite work out.

To those that understood it, SegWit seemed like a brilliant win-win proposal. The network could get to 2 MB blocks, yet we avoided the problem of the upgrade being incompatible. In addition to this, old wallets and new wallets could seamlessly interact with each other and the upgrade was entirely optional: users could either upgrade to SegWit, or continue using the network as before. From the perspective of old wallets, the new style transactions would be missing a signature. However, the wallet would still see the transaction and recognise it as valid once it was included in the blockchain. SegWit also meant that transaction capacity could potentially increase faster than with a simple blocksize limit increase hardfork, because we would not need to wait for everyone to upgrade and we could begin using the new blockspace reasonably quickly.

Not only did SegWit appear to be a solid win for Bitcoin, it also appeared to be a brilliant tactical move, whether intentional or not, from the small blockers in the blocksize war. The proposal was simply so good there were no valid arguments against it. Gavin would have to support the SegWit proposal, and for the most part he did.^[1] If the scaling conferences were a behind-the-scenes conspiracy to buy time and release this idea, then well played! It should be noted that I am not making this accusation here. The large blockers would have been stopped in their tracks with their campaign for a hardfork, and vital time would have been bought. I remember speaking to some of the long-standing large blockers at the time. They informed me that they thought they had been outmanoeuvred by what they considered to be an ingenious proposal.

Of course, this was all in theory. In a hypothetical world, where everyone understood SegWit and all actors were rational, it was a brilliant move. With people arguing over the blocksize limit, the proposal removed the limit and replaced it with something else, thereby negating the argument. However, in reality that was far from the case. SegWit was exceptionally complicated and almost nobody understood it. This was the first major example of the small blockers overestimating the intelligence of their opponents, or at least overestimating the ability of their opponents to understand aspects of computer science. For instance, in hindsight the proposal should have simply been called something like “Increase to 2 MB blocks”. Instead, it had a deeply cryptic and confusing name, which sounded highly suspicious to the large blockers, who wanted something clear and simple they could understand. Large blockers seemed to detect that this move came from their enemy and they wanted their way. This war was about control, and they wanted control. They saw SegWit as an additional stalling mechanism, to stop larger blocks. Therefore, without really understanding SegWit, they opposed it.

As SegWit began to gain traction in the technical community, misconceptions and misunderstandings among the large blockers started to mount. These misunderstandings and rumours included (but were certainly not limited to) the following:

• SegWit is not a “real” blocksize limit increase, it only compresses transactions (it is true that, with SegWit, non-upgraded clients still only see 1 MB blocks, but this is also true with a hardfork since old nodes enforce a 1 MB limit. With SegWit, upgraded nodes do see blocks larger than 1 MB, which is presumably what the larger blockers wanted);
• Bitcoin is based on a chain of digital signatures, which SegWit removes thereby breaking the chain and creating a security risk;
• If a miner does not upgrade for SegWit and produces a block, this block will be rejected by the upgraded clients. This increases the risk of a chain-split (this should only happen if a miner uses custom software deliberately designed to split the chain);
• If a user upgrades to SegWit, they will be unable to send funds to a user who has not upgraded;
• The SegWit upgrade could be reversed, and then coins inside SegWit outputs could be stolen by anyone (reversing SegWit would be a hardfork).

Many of the misunderstandings were nonsensical and therefore a rebuttal could not easily be articulated. They appeared to stem from the fact that most people didn’t really understand the basics of Bitcoin transactions in the first place. For instance, the phrase “SegWit format address” was often mentioned, but SegWit didn’t have a new, or different, address format. If people didn’t understand the mechanics of Bitcoin transactions anyway, explaining the mechanics of SegWit was simply impossible.

SegWit proved so complicated that even Jeff Garzik didn’t seem to understand it. He thought there would be “two buckets” for fee bidding: one related to the old 1 MB limit, and one related to the new 4 million unit weight limit.^[2] In actual fact, the two limits, blocksize and blockweight, were constructed such that they were consistent with each other and therefore equivalent, such that there would only be one fee market bucket. This is not a criticism of Jeff; SegWit was an extremely difficult proposal to fully appreciate and understand, which proved to be a fundamental weakness of the idea. This just goes to illustrate that, while, technically, SegWit may have been a solid way forward, it was simply not possible to communicate this to the Bitcoin community due to the complexity involved.

There were some valid arguments against SegWit, apart from the high degree of complexity. In order to get the benefits of SegWit and the increased blockspace, user wallets had to upgrade to support the new transaction format. This could take more time than a simpler hardfork increase, which did not require transaction formats to change. It should be pointed out, however, that as soon as some users upgraded to SegWit, it would free up blockspace for the laggards who were slower to upgrade.

To many of the small blockers, getting users to upgrade to a new transaction format was part of the point of SegWit. In addition to providing a blocksize limit increase, the new SegWit transaction format also fixed a number of bugs, namely third party transaction malleability and the non-linear scaling of sighash operations. I won’t go into too much detail here. Briefly, third party transaction malleability is essentially an issue that arises because anyone has the ability to change the transaction ID of a Bitcoin transaction before it gets confirmed in the blockchain, and for the transaction to remain valid. This had caused issues for some wallets and merchants in the past, who had trouble tracking funds. It is essentially a bug. Fixing this was also somewhat necessary for a layer-two transaction network called lightning.

The non-linear scaling of sighash operations means that, as the number of inputs in a transaction increase, the number of hashing operations required to validate the transaction increases quadratically rather than linearly. This scaling problem was an impediment to larger blocks, as attackers could create transactions which took so long to verify that the network could grind to a halt. This issue was actually one of the main reasons cited by small blockers for opposing blocksize limit increases, as attackers could exploit this weakness. An attacker could construct a block which contained many of these large transactions, such that it could take an ordinary computer many hours to validate. Therefore, to many small blockers fixing this issue was a prerequisite to a blocksize limit increase. They derided the large blockers for complacency in overlooking this weakness and lacking an adversarial mindset. Conversely, large blockers appeared to believe Bitcoin was almost indestructible or antifragile, as they often put it. Small blockers attributed the robustness of the system to hard work and caution from the development team, but that wasn’t appreciated by the community to the extent it should be. Most large blockers believed that fixing these bugs should not be a priority; it was the blocksize limit that was key.

Regardless, when using SegWit, these bugs were fixed. From the point of view of small blockers, this made perfect sense. With SegWit, we could keep the old 1 MB limit for the old buggy transactions that did not scale well, and at the same time have more space available for new transactions without the bugs. From an engineering point of view, SegWit seemed fantastic. The problem, again, was the complexity; most Bitcoin users had no idea about these problems and did not care about them. And Bitcoin is more than just engineering and computer science. It is also a social system, a live payment system, an economic system, and a financial system. Whether SegWit made sense when looking through these angles was less clear.

Although the idea for SegWit was presented to the conference in December 2015 in Hong Kong, it still had to be implemented, analysed, tested and discussed. It was not until November 2016 when SegWit was finally released in Bitcoin Core, a long wait of more than 10 months. Even though it was released in Bitcoin Core, this did not mean that people could begin using SegWit. It was a change to the protocol rules, or, more precisely, a tightening of the protocol rules or a softfork. This meant there was an activation methodology. The chosen activation mechanics were that miners had to signal support. If 95 percent of blocks signalled support in a 2,016-block difficulty adjustment window, the softfork would then activate, after another two-week grace period. If, after 12 months, the activation had not occurred, the upgrade would be aborted.

To the large blockers, this activation methodology was inappropriate. You never get 95 percent agreement on anything, they argued. This would allow any small coalition of miners, with just five percent of the hashrate, to block the change. Some large blockers saw this 95 percent activation threshold as a stalling tactic, and preferred the 75 percent threshold in Bitcoin XT. Large blockers tended to see the miner flags as a vote, a decision-making process. In this context, 95 percent did not seem to make much sense. On the other hand, smaller blockers saw the flags as a signalling mechanism or safety feature. In their view, users decided on the protocol rules and miner signalling was necessary to ensure a safe transition to the new rules. It was not considered a political voting process.

Besides, 95 percent was not picked out of nowhere. The last three Bitcoin softforks had all activated using this same 95 percent threshold: BIP 66 (restricting signatures to DER encoding) in July 2015; BIP 65 (Check Lock Time Verify) in December 2015; and BIP 68, BIP 112 and BIP 113, three different softforks which activated at the same time in July 2016. SegWit had just chosen to continue with the same (or slightly modified) activation methodology. It should be noted that these previous softforks had not progressed perfectly. The activation of BIP 66 in July 2015 caused a chain-split for a few blocks, as miners appeared to fail to upgrade for the softfork, despite flagging that they had upgraded. The July 2016 upgrade also took longer than expected and the community had to lobby mining pools to signal support. Mining pools on the large block side of the debate were slower to upgrade for this unrelated softfork, perhaps due to a degree of disillusionment with Bitcoin Core.

Given the above history and the new tension in the community, when SegWit was released there was considerable uncertainty as to whether miners would activate SegWit or not. Indeed, one of the mining pools, ViaBTC, had already indicated they would not support the upgrade even before the client was released.^[3] While SegWit was engineering wizardry, it did little to calm tensions in the conflict.

^[1] https://twitter.com/gavinandresen/status/800405563909750784

^[2] https://www.slideshare.net/jgarzik/bitcoin-status-report-on-chain-scaling-aug-2016

^[3] https://bitcoinmagazine.com/articles/segregated-witness-officially-introduced-with-release-of-bitcoin-core-1477611260