As two proposals for boosting bitcoin’s transaction capacity approach key deadlines, one proposal, known as SegWit2x, has perhaps garnered the most attention.
As CoinDesk has previously reported, the plan, first proposed in May, quickly won favor among many of bitcoin’s startups and mining pools. Yet, it has also emerged as contentious in some quarters, owing to its specific goals and its technical construction.
But, what’s at the heart of the arguments for and against?
First, SegWit2x seeks to upgrade bitcoin in two ways:
- It would enact the long-proposed code optimization Segregated Witness (SegWit), which alters how some data is stored on the network.
- It would set a timeline for increasing the network’s block size to 2MB, up from 1MB today, to be triggered about three months after the SegWit activation.
Understanding the ins and outs of the proposal from here can be challenging. While technical, the proposal is also political and philosophical (and some would argue, personal).
Still, the specifics of the debate revolve around basic facts about current network design and performance.
- Bitcoin is currently limited in the number of transactions it can process. (Today, it can only process up to 1MB of transactions roughly every 10 minutes.)
- Owing to this limit, users may experience delays in transaction approval during times of heavy use.
- As all users pay a fee to miners to execute transactions, this limitation on space has increased average fee costs.
- Increasing the block size makes network nodes, which store the full history of all transactions, more difficult to run for users.
To begin, SegWit2x is not the first proposal for scaling bitcoin’s transaction capacity, though it does differ in some key ways.
- It was not put forward by, nor has it been endorsed by, Bitcoin Core, the network’s main open-source developer team.
- It doesn’t introduce new ideas so much as combine those previously proposed by various developers in a new way.
As outlined above, these ideas include:
- SegWit: An optimization proposed by Bitcoin Core developer Pieter Wuille at the end of 2015, SegWit increases the volume of transactions that fit into each block without raising the block size parameter. Specifically, it also removes transaction malleability, an issue that once resolved could lead to a number of network improvements. (You can read more about the technical specifics here and here).
- A block size increase: The change, long-proposed as a scaling solution, simply involves updating the software rules to allow for 2MB blocks.
On their own, neither proposal has garnered enough support to impact the network.
For example, a few alternative bitcoin implementations (Bitcoin XT, Bitcoin Classic and Bitcoin Unlimited) emerged with the goal of increasing bitcoin’s block size parameter. But none have yet reached the necessary threshold of support.
Then, SegWit was officially released last November, giving network users the option to run it. But, for technical reasons, it required mining pools to activate the change, and they have been hesitant to adopt the change for a variety of reasons.
Who supports it? Who opposes it?
In favor of SegWit2x are a significant number of high-profile bitcoin businesses and individuals, most of whom are more closely affiliated with the ecosystem’s startup and investment community.
- Most of the network’s larger mining pools
- Bitcoin startups like Coinbase, BitPay and Blockchain
- Notable developers, including former lead maintainer of Bitcoin Core, Gavin Andresen.
(A full list of supporters can be found in the original SegWit2x agreement announcement.)
Still, others oppose the plan, including:
- A few businesses (including Bitrated and Bitonic)
- Many node operators and bitcoin users
- Nearly all Bitcoin Core developers responsible for maintaining the software.
(The actively updated Bitcoin Wiki page offers a longer list of those who support, oppose and are undecided.)
What’s at stake?
Looking ahead, the outcome of SegWit2x will depend on how many users ultimately adopt the proposal.
As is probably to be expected from such a large ecosystem, different users have different opinions on the best course of action, perhaps owing to the competing ideologies underlying their participation to begin with.
As such, SegWit2x is not the only scaling proposal. Alternative proposals have been introduced and could be enacted on the network in the coming month.
As such, several different outcomes could emerge, including:
- If the mining pools that have pledged support for the change follow through by the end of July, the SegWit portion of the proposal will be activated on the network.
- If the proposal doesn’t get that support, the change could trigger a domino effect that, in the worst case, could lead to a split into two competing bitcoin assets.
Further, SegWit2x is competing with another proposal: BIP 148. This could activate days after mining pools and users are supposed to begin running the SegWit2x code if it doesn’t gain the necessary support in time.
Still, developers have put work into making these proposals compatible and, if enough mining pools support SegWit2x before August 1, bitcoin should avoid a split.
A longer-term issue is that all users need to upgrade their software in support of the 2MB hard fork component, or bitcoin could split into two competing assets with different users.
(A more detailed version of this timeline, and the potential ramifications, can be found on Bitcoin Magazine.)
How you can follow SegWit2x’s progress?
There are various places to track the project’s development.
As the period for adoption starts on July 21, many will now be keeping a close eye on the evolving situation.
Disclosure: CoinDesk is a subsidiary of Digital Currency Group, which acted as organizer for the SegWit2x proposal and has an ownership stake in Coinbase and BitPay.
Dominoes image via Shutterstock
The leader in blockchain news, CoinDesk is an independent media outlet that strives for the highest journalistic standards and abides by a strict set of editorial policies. Interested in offering your expertise or insights to our reporting? Contact us at [email protected].
Powered by WPeMatico