Why I am against the Segwit Soft Fork

Note: The author of this article is software engineer Steve Sokolowski. The content of the article is the author's personal opinion and does not represent the position of this website.

The upcoming release of the Segregated Witness (SegWit) code by Core is a major turning point for the Bitcoin industry. Although the block capacity issue has held back Bitcoin for nearly a year, people have been slow to give a specific time to overturn the Core development roadmap. All of this will be changed by Segregated Witness, as it represents a major turning point in the future development of Bitcoin.

The soft fork of Segregated Witness promises that existing nodes will not be eliminated from the network and can continue to operate. While this promise sounds great, the fact is that every programmer often makes affirmative statements, accompanied by clear disclaimers in case something goes wrong in the future. The worst case scenario is that the software works erratically and is abused because no one noticed the problem.

Implementing the segregated verification code via a soft fork will break most existing software. In addition, this additional complexity will reduce developer efficiency in the future. In this article, I will detail the main disadvantages of segregated verification and the adverse effects of implementing segregated verification as a soft fork on ordinary users. I suggest that the community oppose Core's soft fork decision and upgrade the soft fork to a hard fork, transferring the final decision-making power from miners to users and investors. The best time to execute this hard fork has been reduced to weeks or months.

Segregated Witness is an addition to the Bitcoin protocol that splits the data format into two parts: existing blocks and a "verification" segment. Transactions in existing blocks can serve as a guide to the detailed data in the verification segment. For example, a transaction involving multiple recipients may take up less space in an existing block because the signatures in the existing block do not have to cover all transaction information.

Segwit's supporters point to several advantages of the plan. One of them is that Segwit solves the problem of transaction malleability malleability. This problem makes it more difficult to track unconfirmed transactions using transaction hashes. Supporters also believe that after Segwit is activated, the blockchain can carry more data. Although the Segwit code does not change the 1MB transaction capacity, it can reduce the corresponding data size in the 1MB block space. Core said in an official statement that with Segwit, the future development of Bitcoin will be smooth because it properly handles the reserved operation statements in the Bitcoin script language.

Unfortunately, I believe that Segwit’s disadvantages far outweigh its advantages. I will first list some of the technical flaws, and then talk about its most fatal disadvantage - the way it is deployed.

First, it is important to check the validity of the increasing number of transactions in the block. Although Segregated Witness effectively increases the utilization of 1MB of block space, all transaction data is still received and stored in the blockchain. In Segregated Witness, the verification data is received separately, so a 1MB block will include 100KB of additional transaction verification data, a total of 1.1MB. But in fact it is not that simple: even if the block capacity is simply increased by 0.1MB, the bandwidth required for transactions will be more than expected.

Think of this as two Excel spreadsheets. These two spreadsheets contain different car data, and the license plate number needs to be recorded in both the accident report and the inspection report. If the two report spreadsheets are combined into one, the license plate number only needs to be recorded once. The duplication of the transaction identifier of the isolated verification will generate additional data.

Additionally, as I said in March, Segwit will only increase the transaction space of a small portion of Bitcoin when transactions are complex and people choose to use it. Segwit will not increase block size for simple transactions with only one input and one output. Moreover, people will only use Segwit when they see the potential benefit, so soft fork upgrades may be slow or not happen at all.

Second, segwit will disrupt existing software deployment models in the cryptocurrency space. Block explorers will likely suffer the most. Once the first segwit transactions are processed, many explorers will go offline. Having built block explorers for over 200 coins, I can attest that handling such non-standardized transactions is an extremely complex task. Coin clients don’t track balances for all addresses, so you’ll have to rewrite your software to accommodate the new data format and then rebuild the index for the entire blockchain.

We had a similar situation where it took us three months to get our block explorer code to work without math errors or missing transactions. Because transactions were calculated at the beginning, the bug only occurred after days of relocation. But the steps in the calculation that went wrong were not obvious, and the debugging process was mostly guesswork. The only way to verify the validity of the new code was to delete the database and reindex again, provided that the total value of the calculation was known. We had 1.1TB of block explorer data, more than twice the amount of Bitcoin blocks, which meant constantly reindexing 500GB of concatenated summary data. Many data analysis services eventually failed (or worse, reported incorrect data) because developers often did not have a lot of time to update and upgrade, which led to the centralization of a large amount of important Bitcoin code.

But it’s not just block explorers that will suffer. Exchanges with custom Bitcoin clients will also have to change their product code, which has been running for years without any problems. Well-run companies don’t make changes to their product code without extensive testing, after all, there’s a lot of money at stake. This upgrade is very expensive, so I’m against adopting Core’s plan to activate the segregated witness code. Companies that need to process a lot of transactions (which are usually good for segregated witness) may decide that the risk of paying high transaction fees is less than the risk of hiring someone to rewrite the code, which could result in huge losses.

Third, even if all service agencies successfully upgrade, the community will still face a high degree of transaction complexity, which will ultimately hinder the development of Bitcoin. Previously, developers only needed to understand and manage a single simplified blockchain, but after the implementation of isolated verification, developers must handle both the main chain and verification data transactions.
Cryptocurrency is a relatively complex field, and the ability of developers is very important. The current Bitcoin system has become increasingly complex, and almost no one can fully understand it. After the implementation of segregated verification, the system will become more complex, and the training time for developers will definitely increase. We are likely to lose most of the potential talents. The Bitcoin community is already facing a shortage of talents, especially ethical developers. Segregated verification will complicate the system while reducing the input of talents.

Fourth, even if every developer thinks that the increased complexity of the system is not a big deal, once isolated verification is implemented, it will exist forever. This means that every subsequent modification of every client must be tested in both the existing blockchain code and verification data. Is it really worth permanently slowing down the pace of development for some relatively minor improvements? Core estimates that the stability of isolated verification requires additional testing of more than 3,300 lines. All tests must be run and updated with each modification, and some problems that do not exist yet but need additional testing may be discovered in the process.

Fifth, segregated verification can indeed solve some of Bitcoin's "historical problems", such as transaction malleability. However, the solution of segregated verification is too complicated. A few months ago, Bitcoin Unlimited launched Xtreme Thinblocks, which can greatly avoid the phenomenon of block processing delays when receiving large amounts of data. In comparison, this method is simpler.

The solution proposed by Segregated Witness is also suspected of being "adding fuel to the fire". A large number of cryptocurrencies have been running scalable transactions for more than 7 years without any problems. If handled properly, scalability issues will not lead to capital losses. Core believes that solving the transaction scalability problem will make smart contracts more compatible with the Bitcoin system. This statement is correct, but there is already a coin that is highly compatible with smart contracts. Core should focus on Bitcoin's strengths, namely currency transactions.

Core is eager to solve the transaction scalability problem in order to promote the official implementation of the Lightning Network. But the Lightning Network will never be successfully deployed. Theymos (former r/bitcoin moderator) has long said that the Lightning Network was heading for destruction from the beginning. Because the war he triggered in the Bitcoin community over the issue of block expansion will definitely affect the Lightning Network.

Core has been adding new features since client 0.12 without asking users what they want. They have a low rate of new releases because there aren't any compelling features in them. Core should stop holding weekly dev meetings that never touch on block capacity. They should focus on cost-benefit analysis. They should consider the following questions before adding any new features: Will anyone actually use this new feature? Is this a waste of time that delays our progress in solving the block capacity problem? It's unclear whether the problem that Segregated Witness is trying to solve represents user demand.

Finally, the most worrying and disastrous thing about Segwit is that Core is trying to activate the Segwit code via a soft fork. Soft forks are a cowardly act, and they are using this to force changes on people that they don't want. In a soft fork vote, miners are likely to make the economic decision that affects them the least. They don't have to pay the developers to improve the software; they don't have to worry about losing money after changing code that has been running for years and is still fully functional; they don't have to worry about whether anyone uses the Segwit update; and they don't have to worry about how to communicate with people who don't often visit the forums. In fact, they have no right to make decisions, and those who have to bear the consequences of the code update have this right.
There is another solution: a hard fork, which would give everyone in the community the power to decide. This is the main reason why I am calling for a hard fork to implement Segwit. At least one exchange needs to support the current "simple" blockchain. The biggest challenge is to find the right person with enough time to make a small improvement to Bitcoin Core or Bitcoin Unlimited to fork the network when Segwit is activated. This person cannot participate in the endless discussions about forks. This change can be a simple instruction to use the Segwit code to reject blocks containing verification data. Btcfork (Reddit) is a bad example because the solution is obvious and does not need much discussion.

It is much better to stick to their guns on Segwit than on blocksize, since people can call a no-confidence vote on the issue ^[1] . Opposition to the Segwit fork and the long battle for it will make Core feel that the features they have added since version 0.12 are unnecessary. They can then focus on developing a long-term or short-term solution to the impediment to Bitcoin adoption: blocksize. Core will then realize that blindly adding features that are not widely used will not improve the software. Core must understand that miners and developers serve the users of the software. Either follow the community's choice or get out.

In conclusion, there are advantages to segwit. A lot of people have been working on it. Maybe it will be useful in other cryptocurrencies. A segwit hard fork will probably be supported by a large portion of the community. If most users want to keep the status quo, the Core developers who support segwit will probably continue to run on the less valuable side. Just like the Ethereum hard fork.

Soft forks give the decision to miners, who are not actually affected by the final outcome. Therefore, users should be the ones making the decisions. If no one steps up before the soft fork, everyone will be stuck. Even if unlimited block capacity is achieved in the future, it will still be the fate of dealing with segwit transactions. If someone wants to tell the community that Bitcoin exists because of users, not developers or miners, then they should make segwit a hard fork.

Notes (↵ returns to text)

1. In Western parliamentary countries, the parliament votes to express confidence in the cabinet's policies or the behavior of cabinet members and ministers. It is an important way for the parliament to supervise the government.