All You Need to Know About This Whole SegWit vs. SegWit2x Thing, Explained
What is Segregated Witness?
It’s an updated version. The original article was published April 20, 2017
Segregated Witness, often abbreviated to SegWit, is a proposed update to the Bitcoin software, designed to fix a range of serious issues.
It is developed by its long-standing team. Bitcoin Core is currently the most popular Bitcoin reference client, in use by the majority of the businesses in the industry.
Originally, the update was aimed at solving transaction malleability, a well-known weak spot in Bitcoin software. Although this vector of attack is not the most damaging to the users, it has been exploited in several instances already, highlighting the need to patch it.
However, SegWit offers a range of other advantages and by now the focus of attention has shifted from fixing the transaction malleability to solving the problem of Bitcoin scaling.
What is SegWit’s solution to the Bitcoin scaling problem?
SegWit increases the Bitcoin’s block size limit and allows the implementation of the second-layer solutions for further improvement.
Current issues of Bitcoin scalability arise primarily from the insufficient block size. Consecutive blocks of transactions are what the Blockchain technology is comprised of. Blockchain, in turn, is the ledger of all transactions that have taken place in the network up until now - the lifeblood of the cryptocurrency.
The problem here is that currently, blocks have a hard-coded limit of one megabyte. This is not enough to account for the hundreds of transactions that the users are trying to send every minute.
Consequently, a lot of those users have to wait in line until their transaction can be confirmed; sometimes for hours or even days. As the size of the network grows, so does the transaction intensity, whereas the block size limit stays the same, which means that the problem is continuously getting worse.
SegWit’s solution to this is twofold. First of all, it enables an immediate increase of the block size limit to four megabytes. There’s one caveat here: four MB is the absolute maximum, while the actual block size will depend on the network conditions. It is predicted by experts to be in the range of about two to 2.1 megabytes immediately after SegWit’s activation.
Secondly, by solving transaction malleability, SegWit eliminates what used to be a minor problem for Bitcoin itself, but a major barrier to implementing second-layer solutions on top of it. One of those solutions is the proposed Lightning Network. It is expected to allow for a massive increase in the network capacity by moving the bulk of transactions off the Blockchain for quick processing.
What are the main arguments against SegWit?
The key ‘against’ points can be roughly divided into three groups: technical, political and ideological.
Some have argued that SegWit, in its current state, will not be able to solve the problems it promises to solve. One of the primary arguments here is that the block size increase proposed by the update is not nearly enough to satisfy the growing needs of Bitcoin’s user base.
The majority of the experts seem to agree about the high technical competence of the authors of SegWit, as well as the solidity of the technology itself. However, it is nearly impossible for a person who is not a programmer to evaluate the authenticity of the arguments proposed by both sides.
The fact that the debate is now not purely technological but has a political aspect too only complicates things. A large number of people working on SegWit are also employed by a company called Blockstream, whose primary product is sidechain solutions.
Some from the community claim that this creates a conflict of interest, as the developers are incentivized to obstruct attempts at increasing the block size, in order to artificially increase the demand for sidechain solutions, such as the Lightning Network. There is no definitive proof for this claim but a large part of the community has still chosen to believe in it and is opposing SegWit as a result.
The main ideological argument, leveled against the update, is that it does not provide scalability while preserving a sufficient degree of decentralization of the Bitcoin network. As has been said earlier, SegWit solves the long-term problems with Bitcoin’s insufficient transaction capacity only insofar as allowing for implementation of second-layer sidechain solutions, such as the Lightning Network.
The problem some people see here is how the sidechains work. In order to not rely on the highly congested Blockchain, they move the coins to a second-layer system. There, all transactions are processed by a trusted third party, without having to broadcast them across the entire network, which saves a lot of resources and time.
But a trusted point of authority in charge is exactly what Bitcoin was meant to remove from the monetary system. For some, that is an unacceptable compromise, no matter how little power the third party wields in solutions such as the LN and others.
Who supports SegWit?
A wide range of individuals and companies have endorsed SegWit at some point in the past.
Over 100 of the industry’s most prominent companies are known for a fact to either plan, work on or have implemented support for SegWit in their businesses. The entire list is here.
In addition, many prominent individuals known for their work in the Bitcoin community have made clear their support for SegWit on Twitter, and various other platforms. Among them are Andreas Antonopoulos, Samson Mow, Charlie Lee, and others.
The current support level is as follows
What is SegWit2x?
SegWit2x is the next step of Bitcoin update.
It’s is a second part of the New York Agreement reached May 23, 2017. This update means increasing the Bitcoin block up to two MB.
SegWit fixed some mistakes and provided background for the next improvements. Nevertheless, it didn’t solve the problem of small blocks. Back in the days, one MB might have been enough to meet users’ needs, but nowadays the amount of data is too large. It has a great impact on the rate of transaction confirmation and internal fees. And who likes high fees and anxious waiting for block confirmation?
Who supports SegWit2x and who doesn’t?
Despite being a part of the New York Agreement, a lot of nodes and mining pools have changed their minds.
Six months ago, most of the participants agreed on the hard fork. But with time, more and more companies refused to accept SegWit2x, like TREZOR, Bittrex and others. They are worried about the possibility of a replay attack and uncertain future for both chains. There is no unity in the Bitcoin community on the issue and that’s why so a lot of companies don’t want to take risks. Worldwide known cryptographer and smart contracts specialist Nick Szabo is also not satisfied with the proposed update.
The LItecoin founder, Charlie Lee:
I noticed this also. In my opinion, Nick Szabo is the closest we have to Satoshi, if not Satoshi himself. With Nick and all of Bitcoin Core devs against Segwit2x, why are people still pushing for this hardfork that will split the chain? https://t.co/5jRvNMaK5n— Charlie Lee (@SatoshiLite) November 8, 2017
There’ve also been a lot of tweets with a hashtag #NO2x around Twitter opposing the hard fork.
But at the same time, there is a group of mining pools in favor of the hard fork.
ViaBTC mining pool will support both B1X and B2X, give the choice to our users.— Haipo Yang (@yhaiyang) October 9, 2017
What to expect about SegWit2x?
SegWit2x is canceled but it’s still possible to be implemented in the near future.
Specialists point out that this update has some weak points. The main problem is a replay protection, more precisely, a lack of replay protection. The possibility of a replay attack allows fraudsters to get access to user confidential information, which, in turn, undermines the credibility of Bitcoin. This problem is too serious to ignore it.
The problem of Bitcoin scaling is still relevant. It has to be solved. SegWit2x is a possible solution but it has some technical issues. Quite possibly, the scaling will be forthcoming but it will take time to consider and change the hard fork implementation.