BITCOINS HARD FORK SIDESHOW

One of the hottest topics of discussion within the cryptocurrency crowd recently has been Bitcoin’s (BTC’s) anticipated November hard fork, Segwit2x. This iteration of BTC’s hard fork has drawn critical debate amongst the community, the Core Bitcoin developers, and Segwit2x dev team.

THE GIST

Segwit2x is meant to increase Bitcoin’s block size to 2MB. According to reddit user paleh0rse, these are the differences between BTC Core and Segwit2x::

Figure 1: Core vs. Seg2x

The concept is meant to be an upgrade to the BTC blockchain. However, the Bitcoin Core dev team disagrees. The drama ignited when Bitpay released a post promoting the BTC1 codebase of Segwit2x, referencing it as a client alternative to Bitcore nodes.

DRAMA

The disagreement stems from the fact that Bitpay encourages their users to update their nodes to Segwit2x whilst implying Segwit2x will be the new BTC and not the original Core.

BITPAY’S REASONS ARE

“Once the new Segwit consensus rules are activated, bitcoin transactions will now contain additional transaction information, and some definitions for important transaction rules will be changing. Nodes which fail to upgrade to support Segwit will face major security risks, including the risk of double-spend transaction fraud.”

“There are 2 vulnerabilities faced by nodes that do not upgrade to the new Segwit validation rules. The first is an increased risk of 0-conf double spends. The second is the risk of temporarily following an invalid fork.

Segwit introduces new rules that treat certain output scripts as special. For Segwit nodes these outputs may only be redeemed if certain conditions are met. The conditions include, “a proper signature must be provided”.
For old nodes, these outputs look like “anyone-can-spend” outputs. Under the old rules, these outputs may easily be redeemed by anyone on the network without a signature. It is possible to craft a transaction that is valid under the old rules, but invalid under the new rules. This presents a series of problems if these transactions are relayed to non-upgraded nodes or included in a block that is relayed to non-upgraded nodes.

Figure 2: 0-conf Double Spends

The above image demonstrates the 0-conf double spends dilemma and how it affects both blockchains.

DISAGREEMENT AND DISRUPTION

The Core development team strongly disagrees. John Carvalho, @BitcoinErrorLog, posted to Twitter that Bitpay is “deceitful for recommending it’s users to install btc1 without mentioning it is a contentious fork”.

Tuur Demeester, @TurrDemeester, states that Bitpay “needs to be transparent about what code this is (2XHF!), and to discuss the risk of chain split, replay & loss of value”.

From the perspective of Bitcoin Core developers, the move by Bitpay was a fraudulent move, passing btc1 off as Bitcoin software, and is a violation of bitcoin.org’s hardfork policy.

BTC1 developer Jeff Garzik championed Bitpay’s views, “It is reasonable and practical to follow the blockchain with the most hash power (thus most secure)”. This was not received well by the Core team, and Jeff promptly found himself removed from the Core bitcoin repository as a contributor.

Bitcoin’s operator Theymos does not agree with Garzik, and responded, “Bitcoin is not and must not be ruled by miners”. Bitpay also found themselves no longer affiliated with bitcoin.org, as all Copay Wallet and Bitpay services have been removed from the site.

OFFICIAL STATEMENT BREAKDOWN

Bitcoin Core’s official team released a statement aiming to clarify the differences between the Bitcoin and Segwit2x:

“Segregated Witness (or Segwit, a soft fork which will be active within the coming days) is not related to the Segwit2x hard fork. Segregated Witness is backwards compatible with all previous Bitcoin software. For the vast majority of Bitcoin users, no action is required.”

“btc1 is not connected to Bitcoin Core in any way.”

“While it is difficult to determine what the broader Bitcoin community supports, be wary of claims suggesting the large and diverse Bitcoin community is moving entirely to one fork or another, without independent verification. “

“Concerns raised by Bitcoin Core contributors and Bitcoin community members about the Segwit2x proposal have not been adequately addressed by its proponents. The details of the proposal were established before Bitcoin’s Segregated Witness activation, and before the recent creation of the BCH currency. It is irresponsible to ignore the outcome of these events when planning for the future. As an example, we’ve seen the confusion that arises when a single address is valid across two chains, yet the Segwit2x proposal intends to repeat the same mistake. Furthermore, BCH’s implementation of strong replay protection provided significant protection to users of both BCH, as well as Bitcoin, something Segwit2x does not plan on providing.”

REPLAY ATTACK PREVENTION

When Unspent Transaction Outputs (UTXO) are valid on both chains and used dishonestly, it is considered a replay attack. Without proper protection, a malicious entity can replay the transaction on one chain and also fraudulently claim coins on the other chain. BCC’s network implemented strong security for such an occasion and the split was clean. Segwit2x’s team has chosen to go with Gavin Andresen’s opt-in relay protection for BTC1 transaction.

Criticism from Core developer, Gregory Maxwell:

“This is an absurd change. It is minimally useful for users, and mostly looks like a pretext “yes we added replay protection” which doesn’t really protect, and bloats up Bitcoin as a side effect.

“It also adds an alarming coin blacklist to s2x. Visions of things to come in that coin? Instead they could have made a ~2 line change to allow an extra ignored bit to be set in the sighash flags, or a simple additional serialization so that you could make S2X only transactions. They’re making a hardfork in any case, so it would be trivial to allow a new transaction style that Bitcoin doesn’t accept.

“Since use of it would remain opt-in it also would continue to not be real replay protection and would not do much to protect most users from losses– but it would be strictly better than the ugly hack they implemented instead, and wouldn’t burden Bitcoin’s chain and UTXO set with additional unnecessary data… and wouldn’t have the technical debt or ugly precedent of a consensus address blacklist.

“What’s interesting is that Bitcoin ABC (bcash), had basically the above in their first version before they implemented replay protection. They had the technically clue to get that right and the integrity to not falsely describe a one sided only by request thing as replay protection.”

Figure 3: Interaction Flow

Daniel Krawisz states a bitcoin fork shouldn’t have to implement a replay protection because it’s a competition. “You need to be saying, ‘No I am the true bitcoin, I’m going to defeat you — You should implement replay attack protection against me.’”

SEGWIT2X BACKLASH

With a significant amount of business support and majority of the hashrate behind their cause, the Segwit2x team believes their fork will be the true Bitcoin. Jeff Garzik has stated in the past, “The goal of Segwit2x is to upgrade Bitcoin- to be Bitcoin, and not to create an altcoin.” This is why they are refusing to add more defined replay protection – it would go against Garzik’s goal of Segwit2x being BTC’s upgrade. Instead, the Segwit2x proponents are asking why BTC should not be the one to implement the replay attack prevention.

Figure 4: jgarzik

Segwit2x is not expected to drop until November, but it is already apparent it will be a controversial move. Core supporters do not see the benefit in Segwit2x, since there is already a live soft fork version, and block size is no longer an effective metric for capacity and transactions.

Most recent conversations including Garzik’s decision to merge “Add -advertise2x option, for NODE_xxx optionality,” into Segwit2x’s Github repository. The new revision will allow BTC1 nodes to be masked making it difficult for Core 0.15 nodes to identify them.

Ira commented on their Github commit, calling Segwit2x’s revision a trojan horse “as it allows anyone to run 2x nodes in disguise. Now Core needs to find a new way to detect and ban your nodes”.

Other opinions posted on the repository state “this commit is a pure shame for 2x and for all 2x supporting companies. Intentionally trying to disrupt the bitcoin network will have consequences and in a lot of states you will be held accountable by law for this attack.”

Figure 5: advertise2x

Segwit2x is supported by more than 50 industry startups, miners and technologists; organized by industry investor Digital Currency Group. Recently, many groups have voiced their discontent with the fork, withdrawing their initial decisions.

Figure 6: Adios!

Segwit2x is still supported by a few major companies; Bitpay, Coinbase and Xapo. Support has all but been pulled from the rest. One of the most notable rejection was F2Pool’s decision to no longer accept Segwit2x. Accounting for ~10% of BTC’s hashrate, the consequences were notable. F2Pool reiterated that they would’ve only supported Segwit2x if it happened in July.

Figure 7: I didn’t pull out…