SegWit2x, BIP148, and Wirex’s Contingency Plan

July 20, 2017
Wirex Team

For the better part of two years now, the Bitcoin community has been embroiled in an increasingly bitter civil war over how best to scale the Bitcoin network. The crux of the debate primarily revolves around Bitcoin’s current 1 MB block size limit, where each block in the Bitcoin blockchain, created at an average rate of one block every 10 minutes, can only accommodate up to 1 MB of Bitcoin transactions. This, in turn, means that the Bitcoin network is capable of processing only up to approximately seven transactions per second.

However, Bitcoin’s recent explosive growth in price and popularity has also meant that the Bitcoin network has been bursting at the seams with more new transactions than it can handle. For example, during the week leading up to May 25, 2017 — when the price of bitcoin hit a then-all-time-high of $2,558.10, according to BitcoinAverage’s Global Bitcoin Price Index — the number of unconfirmed Bitcoin transactions peaked at an all-time high of 157,558 transactions at around 4:00 P.M. (UTC) on May 23, 2017. Not only did this result in massive transaction confirmation delays for many of Bitcoin’s users, but Bitcoin’s capacity issues as a whole had also led to the development of a fee market, where users essentially bid to have their transactions confirmed by miners as quickly as possible.

 

Segregated Witness and Increasing Bitcoin’s 1 MB Block Size Limit

The debate has historically been a colossal tug-of-war between two proposals: Segregated Witness (SegWit), and increasing or removing the Bitcoin network’s 1 MB block size limit.

 

Segregated Witness (BIP141)

Segregated Witness is a soft fork proposed by Bitcoin Core developer Pieter Wuille on December 7, 2015, and was formally introduced as BIP141 on December 21, 2015.

Interestingly, SegWit was originally not designed with Bitcoin’s scaling issues in mind. Instead, SegWit was primarily designed to resolve a long-standing issue within the Bitcoin network known as transaction malleability, where a bug in the way a transaction’s identifier (txid) was calculated meant that small modifications to an unconfirmed transaction would change its txid, but not its content. This had the potential to cause many problems, not least of which it was preventing sidechains such as the Lightning Network from being easily and efficiently implemented. SegWit resolves transaction malleability by allowing Bitcoin users to move the malleable parts of the transaction into a separate area called the transaction witness and then segregating that witness (hence the name) to prevent changes to the witness from changing the txid.

By moving a transaction’s malleable parts into the witness section and then segregating that witness, SegWit-compatible Bitcoin nodes are then able to fit more transactions into the base 1 MB block, since the witness data is no longer part of the base block. SegWit blocks therefore have an effective size (or a block weight) of up to 4 MB, and remain compatible with non-SegWit Bitcoin nodes, in that non-SegWit nodes will only download the witness-stripped base block and continue to enforce the 1 MB block size limit on that block.

SegWit relies on a system called version bits (as specified in BIP9) for its activation. The version bits system is a way to introduce soft forks to Bitcoin by allowing miners to signal that they are ready to validate the soft-fork rules. This signaling is done by setting the soft fork’s relevant version bit in a block header’s nVersion field. A soft fork introduced by way of BIP9 would lock in once 95% of blocks produced within a given difficulty period (every 2,016 blocks, or roughly two weeks) signal support for the soft fork before its proposal times out. A locked-in soft-fork proposal would activate after another 2,016 blocks have been produced.

For example, miners signaling support for SegWit (BIP141) would set a version bit of 1 in the blocks that they mine. Once 95% of blocks produced within a given difficulty period (every 2,016 blocks, or roughly two weeks) signal support for BIP141 before its proposal times out on November 15, 2017 (UTC), BIP141’s status on the Bitcoin network would be set to locked-in. Once locked-in, BIP141 would activate proper on the Bitcoin network after another 2,016 blocks have been produced (roughly another two weeks).

Unfortunately, miners have been less than enthusiastic toward SegWit (BIP141), to say the least. Since its official start time on the Bitcoin network on November 15, 2016 (UTC), miner support for BIP141 floundered around the 30% mark, mostly due to political reasons, chief of which has reportedly been the BIP141-opposing miners’ dissatisfaction with what they perceive as Bitcoin Core’s (Bitcoin’s main open-source development team) monopoly over Bitcoin’s development process. These miners instead pushed alternative proposals for scaling the network, centered around the increase or outright removal of Bitcoin’s current 1 MB block size limit.

On a side note, BIP9 (the version bits system discussed earlier) was never intended to give miners the ability to vote on proposed soft forks. BIP9 was instead designed as a system that enabled smooth cooperation between developers and miners when deploying soft forks, as soft forks deployed prior to BIP9 had led to some miners producing invalid blocks (and thus losing out on mining revenue) as they failed to comply with the new soft-fork rules in time. The 95% miner-support threshold introduced in BIP9 was intended to resolve this issue and was never intended to grant miners veto power over soft-fork proposals.

 

Increasing or Removing Bitcoin’s 1 MB Block Size Limit

An equally contentious proposal for scaling the Bitcoin network has been increasing or even outright removing Bitcoin’s current 1 MB block size limit. This proposal has generally been championed by the larger mining pools (e.g., Antpool, BTC.top, and ViaBTC). All proposals that seek to increase or remove Bitcoin’s 1 MB block size limit require a hard fork.

Bitcoin XT. One of the earliest attempts to increase Bitcoin’s 1 MB block size limit came in the form of Bitcoin XT, a fork of Bitcoin Core introduced on August 15, 2015 that sought to increase the block size limit to 8 MB. The release of Bitcoin XT is notable for the fact that the mining community never warmed up to it. As a result, Bitcoin XT never received the necessary 75% miner support for it to take off.

Bitcoin Classic. A more modest proposal soon followed, with Bitcoin Classic being released on February 10, 2016 that sought to increase the block size limit to 2 MB instead. Although Bitcoin Classic gained more support from startups and miners alike, it too ultimately did not gain the amount of support necessary to take off, and eventually fizzled out by mid-May 2016.

Bitcoin Unlimited. Perhaps the most contentious proposal to come along that sought to increase Bitcoin’s block size limit came in the form of Bitcoin Unlimited, which sought to replace Bitcoin’s 1 MB block size limit with a flexible block size mechanism called Emergent Consensus. In a nutshell, Emergent Consensus is a mechanism where miners and full nodes essentially haggle on an appropriate block size based on certain prescribed parameters until consensus regarding the block size to use at the time emerges (hence the name).

Despite many concerns regarding the safety, security, and efficacy of Emergent Consensus, especially concerns over how network splits might become the norm, Bitcoin Unlimited nevertheless gained crucial miner support from some of the world’s largest mining pools, including Antpool and ViaBTC. This led to some pretty nail-biting moments where no one could predict whether, or when, the Bitcoin network might split into two.

 

BIP148 and SegWit2x

As tensions resulting from Bitcoin Unlimited’s growing dominance started to boil over, two further proposals soon emerged that has today taken center stage in the scaling debate: a user-activated soft fork for the “mandatory activation of segwit deployment” as specified in BIP148, and SegWit2x.

 

User-Activated Soft Fork (BIP148)

BIP148 was introduced by a pseudonymous developer called Shaolinfry in order to force the activation of SegWit on the Bitcoin network by enabling users to activate SegWit at an agreed-upon point in time, with or without miners’ approval. This would be done by having BIP148 nodes reject any Bitcoin blocks that do not signal support for SegWit by way of BIP9 (the version bits system) beginning August 1, 2017 (UTC). The theory here is that if the majority of the Bitcoin economy enforces BIP148, miners would be incentivized into signaling support for SegWit so as to not have their blocks rejected (and therefore not earn any mining revenue). And if the economic strong-arming from these BIP148 nodes is powerful enough to get 95% of miners to signal support for SegWit via BIP9, BIP141 would eventually be activated before it times out on November 15, 2017 (UTC).

BIP148 carries some significant risks, however. For example, if only a minority of miners enforces BIP148, the Bitcoin blockchain could split into two, and users would have to be extremely careful so as to not lose any funds. The safest way to navigate the aftermath of a chain-split would be to not send any bitcoins until the dust settles.

 

SegWit2x (The New York Agreement)

On May 23, 2017, “58 companies located in 22 countries” representing “83.28% of hashing power, … 5.1 billion USD monthly on chain [sic] transaction volume … [and] 20.5 million bitcoin wallets” agreed to a proposal now colloquially known as SegWit2x.

The goal of SegWit2x is twofold: (a) activate SegWit at a reduced hashing power threshold of 80%, and (b) increase Bitcoin’s block size limit to 2 MB “within six months.”

SegWit2x plans to activate SegWit through BIP91, which is very similar to BIP148 in that all BIP91 nodes would reject any blocks that do not signal support for BIP141 (SegWit). However, where BIP91 differs from BIP148 is that BIP91 nodes would only reject those blocks once 80% of blocks produced within a specific two-day period (or 269 out of a specific 336-block period) signal support for BIP91.

Although SegWit2x’s original plan was to have BIP91 nodes running and signaling beginning Friday, July 21, some mining pools jumped the gun and signaled support for BIP91 as early as Monday, July 17. As of Wednesday, July 19, more than 80% of hashing power have been signaling for BIP91, meaning that BIP91 could lock in as early as Friday, July 21. If BIP91 does lock in by then, SegWit would activate properly on Sunday, July 23, 2017 (another 336 blocks after BIP91 locks in).

The next step of SegWit2x’s plan, and arguably its most controversial, is to increase Bitcoin’s block size limit to 2 MB three months after SegWit locks in. This could be Bitcoin’s biggest risk yet of a network split, as a significant part of the Bitcoin community (and nearly the entire Bitcoin Core development team, who were not invited to the SegWit2x meeting) remain strongly opposed to the SegWit2x plan as a whole, and especially to the 2 MB block size limit increase. Many in Bitcoin’s development community have voiced concerns that three months is simply too short of a timeframe to implement such drastic changes to the Bitcoin network, and are especially peeved over the SegWit2x development team’s penchant for developing the SegWit2x software behind closed doors.

 

Potential Risks and Dangers

With the Bitcoin network now at the cusp of what is arguably its most pivotal phase — with both BIP148 and SegWit2x intending to activate SegWit in less than two weeks — it is extremely important that every Bitcoin user monitors the situation closely, so as to not get caught out by any of the resulting circumstances. Despite the best efforts of developers on both sides to minimize the chances of a network split, both BIP148 and SegWit2x still possess very real risks of diverging from the current Bitcoin protocol, which in turn could lead to further network splits.

For example, if on August 1, a majority of Bitcoin’s hashing power does not signal support for SegWit — whether through BIP91 or BIP141 — but at least a minority does, the Bitcoin blockchain would split into two. There would then be two types of Bitcoin tokens, which for the purposes of this article will be called 148BTC (for the token on the BIP148 chain) and LegacyBTC (for the token on the original chain).

The messy part here is that once the network splits into two, each and every bitcoin on one chain would have an exact copy on the other chain. For example, if you hold one bitcoin right before the network splits into two, you would then have both one 148BTC coin and one LegacyBTC coin after the split.

The danger here is threefold.

Firstly, the LegacyBTC chain could be wiped out if the 148BTC chain accumulates a majority of hashing power over the LegacyBTC chain after the split. Any bitcoins on the LegacyBTC chain after the split would then be lost forever. For example, if you sent or received any LegacyBTC after the split, but before the LegacyBTC chain was overtaken by the 148BTC chain, the LegacyBTC coins you sent or received would disappear.

Secondly, although 148BTC is immune from being wiped out by LegacyBTC (this is because BIP148 nodes will never accept the LegacyBTC chain as valid), there is no guarantee that 148BTC would continue to be used, especially if there is too little hashing power on the 148BTC chain to confirm its transactions in a reasonable amount of time. Remember, Bitcoin’s mining difficulty (which 148BTC would inherit) is adjusted every 2,016 blocks to regulate the rate of block creation to one block approximately every ten minutes. If a significant amount of hashing power leaves the 148BTC chain towards the beginning or middle of a difficulty period, the 148BTC chain’s block creation rate (and in turn, transaction confirmations) would slow to a crawl. Any use of 148BTC would then be highly impractical until it reaches the next difficulty period where its mining difficulty would be adjusted to account for the much-reduced hashing power, if ever.

Finally, in the event of a network split and in the absence of any protections coded into the software of either chain, users on both sides of the split would be vulnerable to replay attacks. Because transactions on both sides of the split would look identical to both 148BTC and LegacyBTC nodes, any transaction made on one side of the split may also be valid on the other side of the split. In other words, spending coins on one side of the split could lead to accidentally spending the equivalent amount of coins on the other side. For example, if Alice were to send one 148BTC to Bob after the split, Alice could also be accidentally sending one LegacyBTC to Bob at the same time. Bob would then be receiving both one 148BTC and one LegacyBTC, and Alice would be both one 148BTC and one LegacyBTC poorer. Until replay protection is added to one or both chains, both 148BTC and LegacyBTC would essentially be stuck together after the split.

 

Wirex’s Contingency Plan

Therefore, in light of these potential risks and dangers, Wirex will be suspending any and all transactional activity on all of our platforms in the 24-hour windows before and after August 1, 2017 (UTC). In other words, from July 31, 2017 (UTC) to August 2, 2017 (UTC), all Wirex users will not be able to make any Wirex transactions, whether through the Wirex website or the Wirex app.

This is to protect all customer funds from being adversely affected by any replay attacks and/or chain reorganizations that may result from the activation of BIP148, especially if BIP91 and/or BIP141 fails to lock in or activate before BIP148 activates.

In other words, from July 31, 2017 (UTC) to August 2, 2017 (UTC), all Wirex users will not be able to make any Wirex transactions, whether through the Wirex website or the Wirex app. This is to protect all customer funds from being adversely affected by any replay attacks and/or chain reorganizations that may result from the activation of BIP148, especially if BIP91 and/or BIP141 fails to lock in or activate before BIP148 activates.

We apologize in advance to any and all of our users who may be inconvenienced by our decision to suspend our services. We sincerely hope that you would understand our desire to keep all of our customers’ funds safe during this uncertain period, and we look forward to serving you again on the other side of BIP148.