The discussion around scaling Bitcoin has continued into the summer months of 2017, with BIP 148 and SegWit2x now the two most talked about proposals. A key similarity between these proposals is that they both intend to activate the Segregated Witness (SegWit) improvement; however, up to this point, the way in which SegWit would be activated by each proposal has not been made compatible. A recently proposed change to the SegWit2x implementation could change this.
BIP 148 is a proposal from the pseudonymous developer Shaolinfry that attempts to force miners into the activation of Segregated Witness via economic forces. The way it works is that those running Bitcoin nodes that have implemented BIP 148 will only accept blocks from SegWit-signalling nodes starting on August 1st.
If BIP 148 is not signaled by more than 50 percent of the network hashrate by August 1st, then there will be a chain split; however, since SegWit is a soft fork, the chain not signaling for BIP 148 could eventually be reorganized into the BIP 148 chain if a majority of the network hashrate decides to support the BIP 148 chain at a later date or time. A reorganization would effectively mean that it was as if the non-BIP 148 chain never existed.
The main reason that miners may change their mind after August 1st would be if the economic majority of users decided to support the BIP 148 chain, although they may also feel the need to avoid a chain split entirely. In Bitcoin, honest miners are incentivized to follow the most profitable chain for them to mine in a soft fork scenario.
SegWit2x
SegWit2x is a proposal that came out of an agreement between many Bitcoin-related companies made during Consensus 2017 in New York. The basic proposal here is to activate SegWit once it is signaled by 80 percent of miners and then attempt a hard fork increase to the base block size limit to 2MB at a later date. This would effectively lead to a greater than 4MB block size limit because SegWit also includes an increase to the block size limit.
Notably, entities accounting for more than 80 percent of the network’s mining hashrate have signed an agreement to run SegWit2x code. The current agreed upon timeline is to start running the SegWit2x code on July 21st.
Making SegWit2x Compatible with BIP 148
The key compatibility issue with these two proposals, at least over the short term, is that they attempt to activate SegWit at different times. If BIP 148 activates before SegWit2x, then there could be an attempted activation of SegWit without majority support from miners, which would lead to a chain split (although the split could be temporary).
To solve this issue, James Hilliard made a pull request in the SegWit2x GitHub repository. The pull request would ensure that SegWit is activated before August 1st, as long as SegWit2x remains on schedule and those involved in the agreement still account for at least 80 percent of the network hashrate when the code is rolled out by all involved parties.
Hilliard’s pull request has been reviewed positively on GitHub by many different individuals, which means it is likely to get merged into the final version of SegWit2x.
The Threat of a Split Still Looms
Of course, a key issue that remains is that SegWit2x will attempt a hard-forking increase to the base block size limit within six months. Unlike a soft fork, a hard fork is not backwards compatible and will lead to a chain split by default, as long as there is enough support on the minority chain for it to continue.
If this hard fork is activated, a split of the Bitcoin community into two separate cryptocurrency networks is possible. It could lead to a similar situation that unfolded after the Ethereum network attempted a hard fork to bail out DAO token holders. There are now two Ethereum networks, known as Ethereum and Ethereum Classic.
Of course, anything can happen between the time SegWit activates and the hard fork is attempted. For now, it seems more likely that a chain split will be avoided on August 1st.