Tomorrow on August 1st 2017, at 12:20pm UT, or 8:20am ET, Bitcoin will split into two. One Bitcoin will be known as “Bitcoin” and enable Segwit2x, supported by most businesses in the community. Another Bitcoin will be “Bitcoin Cash”, which has lesser support, but is currently trading on futures markets at around 20% of Bitcoin’s value.

If you control the private keys to an address with 1 Bitcoin on July 31st, after this fork event, you will control 1 Bitcoin (BTC) and also 1 Bitcoin Cash (BCC) on two, previously identical but from that point onward divergent cryptocurrency networks. You will own two separate versions of Bitcoin with their own futures and supporters after the fork event.

PSA: bridge21 does not anticipate any interruption of service

Quickly, we do not anticipate any interruption of bridge21’s services from Bitcoin’s hard fork on August 1, 2017. All of our Bitcoin will be stored on addresses where we control the private keys during the fork event, thereby ensuring no loss of funds on either chain. We’re also keeping enough Mexican Pesos in reserve so that even if there are significant disruptions to the Bitcoin network, we will still be able to satisfy customer transactions for some time after the fork. Finally, our service doesn’t need a specific type of digital currency to “win” or “lose” in order to be successful, so we have no horse in the race.

Boredom Warning: Heavy Reading Ahead

Today’s blog post is the first half of a “before and after” piece on the specifics of the Bitcoin hard fork, including an objective look at both “sides” of the scaling debate. A warning, this post will require some knowledge of Bitcoin to understand, and is unlikely to be enjoyable or even comprehensible to the casual reader.

As no one really knows what will happen with the split tomorrow writing anything today is arguably a risky move. Then again so is building a money transfer company that uses Bitcoin to settle transactions, so here we go!

To scale or not to scale: the origins of the Bitcoin scaling debate

On July 14th 2010, Satoshi Nakamoto added a limit of 1MB to the Bitcoin blocksize. Bitcoin transactions were effectively free at that time, so there was a legitimate concern that attackers could “spam” the network and arbitrarily create huge blocks with phony transactions, permanently bloating the blockchain that everyone else would have to store in perpetuity. The 1MB limit was meant to prevent this attack until such a time that a better solution could be put in place. Satoshi suggested that the solution could be a set increase in the blocksize at certain block heights, effectively growing the limit at a predetermined rate, similar to how new Bitcoin are issued.

Bitcoin scaling, an extremely brief history

Since the 1MB limit was introduced in 2010, how to scale Bitcoin has been a constant source of debate in the Bitcoin community. This 1MB limit was originally thought to limit the number of transactions per second to 7, but in practice the real number was closer to 2.3 transactions per second. 7 transactions per second was 350 times more volume than Bitcoin’s busiest day ever at the time, leaving years to grow before a solution was required.

Archives of discussion around this time indicate that the 1MB limit was introduced as a temporary measure that would be removed or raised later. Bitcoin’s value was designed to rise relative to other currencies, so with scale attacks of this nature would become cost prohibitive because transaction fees are denominated in Bitcoin.

Furthermore, it was thought that the size of the blockchain itself would not matter much anymore because of “client only mode” wallets (today we call these SPV wallets). SPV wallets allow you to use Bitcoin without downloading the entire blockchain.

The need to solve the scaling issue became a priority in 2014, as we saw the trend in transaction growth threaten to hit the 1MB limit in 2016. Gavin Andresen first proposed 20MB blocks, which was too aggressive for many. This idea was replaced by BIP101, which was meant to increase block size at 40% per year starting at 8MB, conservatively under Moore’s Law and the average speed of broadband speed increases. From here we saw various proposals, including XT which originally implemented BIP101, BIP100 which let miners “vote” on the blocksize limit, Bitcoin Classic, which was a compromise to a simple 2MB blocksize, and finally Bitcoin Unlimited, a more aggressive approach of “emerging consensus” to let users “vote” on what the blocksize should be at a given time. Others favored no blocksize increase at all, but changing the Bitcoin protocol to support “layer two solutions”, which are effectively variations of the “high frequency payment channels” Satoshi implemented in version 0.1 of the Bitcoin software.

This 2+ years of debate occurred while Bitcoin users, investors, and other members of the community watched Bitcoin’s transaction volume slowly creep higher and higher, and in 2016, that volume started to push against the 1MB blocksize.

Bitcoin Transactions per Block over Time

This graphic of Bitcoin’s transactions per block clearly shows a change in the transaction growth trend of Bitcoin. In early 2016 the trend started to break down, and by mid 2016, the number of transactions per second stopped growing. Not because of a lack of user demand, but because of a hard-coded limit in the Bitcoin protocol itself limiting it to around 2.3 transactions per second, the 1MB blocksize limit. This also caused transaction fees to go from pennies to as high as $5.00 per transaction, and settlement times to go from 10 minutes to hours or days. This made Bitcoin non-competitive with existing services like Western Union or Paypal, strictly on the basis of speed and cost.

What impacts did the limit have on Bitcoin from 2014 through today?

As someone that’s followed Bitcoin since late 2010, it’s my opinion that the precipitous drop-off in investor interest in “pure” Bitcoin plays as well as the dramatic loss of Bitcoin market dominance are directly attributable to the lack of scaling and “redlining” of Bitcoin’s transactions per second. Bitcoin will not grow as originally designed without new users and startups using it, and building technologies and services over it.

It’s difficult to prove causation, but there are two trends that are correlated to the 2016 rate limiting of Bitcoin’s to 1MB blocks, or around 2.3 transactions per second.

Trend 1: Follow the Money — Blockchain vs. Bitcoin specific investment over time

First, investment in Bitcoin specific startups grew from 2012 through 2015, but trends changed dramatically in 2016, as is evident from light analysis of data from Coindesk shows. While investment in “blockchain” has still rising steadily year-over-year, investment in firms that are focused on using Bitcoin as a subset of “blockchain” have dwindled.

Blockchain vs. Bitcoin specific investment (Millions USD)

Note, this change in investor preference for alternatives to Bitcoin coincides with full blocks in 2016, and a lack of clear resolution to the scaling debate.

Trend 2: Bitcoin’s sudden and dramatic loss of market capitalization

A second, complementary trend appears when we examine Bitcoin’s market capitalization compared to all other cryptocurrencies in this chart from Coinmarketcap.com.

Notice that the sharp drop in Bitcoin market dominance from 80% to as low as sub-40% coincides with the Bitcoin blocksize “filling up” in 2016? Bitcoin’s market dominance compared to other digital currencies dropped like a rock at exactly when Bitcoin’s transactions per second limit started to impact its growth. If you imagine this market capitalization chart over the transactions per second chart above, the timing is uncanny.

It is also interesting that Bitcoin’s market dominance rebounded around July 1st, almost precisely the time the Bitcoin Cash hard fork was announced. There is absolutely no way to “prove” it, but with a community so divided, I speculate that the market viewed the fork as a positive sign for Bitcoin’s long term health. More on this later…

The scaling debate’s recent, turbulent history

Recently, the “Bitcoin Unlimited” movement gained momentum quickly, largely due to widespread frustration with a lack of real scaling solutions, and was closing in on 50% of the Bitcoin miners “voting” for their approach. The pure “Segwit” approach, which did not increase the blocksize limit, but partitioned digital signatures to an “extension block”, giving an effective increase growing from 1.56 MB to 1.86 MB with adoption. Segwit was promoted by the dominant development team, Bitcoin “Core”. Segwit was introduced with a 95% activation threshold, but failed to achieve more than 35% support months after release, so it was clearly not going to achieve activation, and Bitcoin Unlimited was gaining ground quickly, which made many in the community uneasy, as their approach to scaling was very new, radical, and arguably not as well tested in the real world.

This changed rapidly over an industry conference in 2017, where a compromise quickly achieved 80% and then > 90% support. This compromise was proposed earlier in April by a separate group, but failed to gain traction at that time. The compromise is known as Segwit2x, which combines Segregated Witness with a 2MB blocksize increase three months later.

Around the same time, a group led by a LiteCoin developer started a movement known as the “User Activated Soft Fork” (UASF), which would fork the Bitcoin network in early August, creating a Bitcoin that uses SegWit with no blocksize increase, separately from Bitcoin’s main chain.

A third major group formed around the concept of a “User Activated Hard Fork” (UAHF), where if the Segwit2x group let Segwit activate, but then reneged, doublecrossed, or otherwise failed to increase the block size to 2MB as per the original Segwit2x agreement, the group would splinter off, discard Segwit, and increase the block size directly, allowing for more transactions per second without the more extensive changes included in the SegWit2x release.

The Segwit2x group successfully locked in before UASF, nullifying both the UASF and retaliatory UAHF movements, but then a fourth movement emerged in June/July. This movement aimed to fork Bitcoin into a separate chain without Segwit no matter what on August 1st, but with 8MB blocks. It was dubbed Bitcoin Cash, supported by the new Bitcoin software client “Bitcoin ABC”.

Ok, that’s a lot of craziness! What happens on August 1st?

UASF and UAHF will not occur, but as mentioned earlier, on August 1st, 2017 at 12:20pm UT (which tomorrow morning at 8:20am Eastern), Bitcoin will split into two. One group will be Segwit2x, supported by most businesses in the community, and also Bitcoin Cash, which has lesser support, but is currently trading on futures markets at around 20% of Bitcoin’s value.

What are the big differences between Bitcoin (SegWit) and Bitcoin Cash?

Bitcoin will support Segregated Witness transactions and may, if all parties honor the agreement they signed, increase the base blocksize to 2MB in about three months. It’s complicated, and more on this below, but Segwit2x should give Bitcoin a 3.72x increase in transactions per second with a 3.72MB blocksize, after all wallets and users upgrade to Segwit addresses and transactions. Bitcoin under Segwit2x enjoys far more support in terms of its existing infrastructure, including miner hash power support. Many major exchanges refuse to acknowledge Bitcoin Cash at all, or allow their customers to retrieve their Bitcoin Cash tokens. Segregated Witness enjoys major advantages over Bitcoin Cash today in terms of community acceptance.

Bitcoin cash will not support Segregated Witness, but will bump up the blocksize to 8MB, increasing the transactions allowed per second 8x over today with an 8MB blocksize. Bitcoin Cash has the support of a little over a dozen Bitcoin exchanges, but is recognized by a few power players in the industry, including ViaBTC, OKCoin, Kraken, and others. While it is unlikely to have more than 10% of the miner hashrate of Bitcoin in the beginning, it has been built with a “slow” difficulty re-adjustment baked in, so that its difficulty will re-adjust fast enough for the currency to function during the initial period after the fork.

It’s so political, how do you know which version is “better” for scaling?

Bitcoin’s scaling debate is highly political, full of disinformation with the more extreme members of each “side” behaving more like members of religious cults than computer scientists evaluating options objectively.

That said, here is my best guess as to the “truth” behind the properties of each version of Bitcoin. This guess is based on great work done by a community member in this google spreadsheet, where the analyst took actual bitcoin blocks and compared their size with Segwit, and without it, using real data.

First a quick primer on blocksize limits with and without Segwit

Segregated Witness changes Bitcoin at a more fundamental level, charging different fees for different types of data. Signature data receives a 75% discount, while other transaction data costs “full price”. This effectively replaces the 1MB blocksize limit with a “block weight” limit. If we combine a 2MB size increase with Segwit, we have a potential for 2MB in normal transaction data, and another 6MB for signature data, with a maximum theoretical block size limit of 8MB. When looking at real data, the numbers are different though.

Bitcoin Cash, however, simply increases the blocksize limit to 8MB, for a simple 8x in transaction throughput.

But again, how do these two approaches compare?

If we extrapolate based on transactions in past blocks, assume no one maliciously attacks the network with signature heavy transactions, and that one wants to fully verify transactions for security, probative and/or legal reasons, there are two answers to this question, now and later. The difference is if Segwit specific addresses are implemented.

Segwit Now

Without Segwit specific addresses, we’ll see 54% more transactions in Segwit2x at a space increase of 86%, based on historical data. This means that without Segwit specific transactions, we’ll only get 3.08MB worth of transactions in that 3.72MB.

Segwit Later

In the future, when Segwit specific addresses are implemented by more and more service providers and users, we’ll see about 86% more transactions using 86% more space per 1MB today, which is the same level of scaling as increasing the blocksize directly (as with Bitcoin Cash). This means Segwit2x will give us an effective blocksize increase of around 3.72MB (1.86 x 2) for 3.72MB of size, on average, using past transactions. It is worth noting that Segwit2x could allow 8MB blocks for far fewer transactions in an attack scenario, another point of contentious debate, but under normal conditions using past transactions as a basis, efficiency will be almost equal to Bitcoin Cash in terms of space required on the blockchain.

Bitcoin Cash Now and Later

Bitcoin Cash will give 8x the transactions for 8x the space, without changing the way blocksize limits work in Bitcoin.

What are the pros and cons of Bitcoin Segwit vs. Bitcoin Cash?

Bitcoin Cash allows a 1:1 scaling increase today, changes far less of the Bitcoin codebase (which is risky and complicates future changes too), does not change the relative cost of transaction vs. signature data (another change and unknown) and still solves many of the issues with Bitcoin scaling that Segwit was engineered to overcome, like On2 scaling issues with SigOps. It arguably does this in a cleaner manner, because there is no requirement for users and service providers to do anything differently, and all of the benefits are available day 1. Bitcoin Cash also enables “l2 solutions” by fixing transaction malleability and quadratic scaling challenges, although via a simpler approach.

Bitcoin Segwit2x offers only an 0.827:1 increase today, but will, with further implementations, enable near 1:1 scaling in the future breaking even with Bitcoin Cash. Segwit also enables “layer 2 solutions”, like payment channels, that could conceivably move transaction volume off of the Bitcoin network and onto overlays that are not recorded on the Bitcoin blockchain except as bulk settlement events, reducing their burden on Bitcoin. It also applies a 75% discount to signature data, which supporters argue can be pruned from most nodes running Bitcoin software.

If you had to gamble, how would you see all of this playing out?

Segwit without a blocksize increase failed to achieve more than 35% support. It was the 2x component plus Segwit that drove support over 90%. It is clear that the majority of the community prefers a blocksize increase. That said, here are several ways I could see this unfolding over the next 1–2 years.

Outcome #1: Segwit2x honors 2x and prioritizes on-chain scaling

If Segwit2x honors the full agreement, increases the base limit to 2MB, and continues to prioritize scaling Bitcoin so we are not “backed up” as we have been since 2016, I believe Bitcoin Cash will become “Ethereum Classic” to Bitcoin Segwit. It will linger around 5% to 20% of Bitcoin Segwit2x’s market capitalization.

Outcome #2: Segwit2x reneges on 2x or does not prioritize on-chain scaling

Many in the community fear that the developers behind Segwit2x will either lose momentum to the “Bitcoin Core” group that wants Segwit without an increase, or may simply decide to not code the increase in 3 months to 2MB. Others still believe we may see the 2x increase in 3 months, but future increases will not happen when required, and Bitcoin will return to a state of uncompetitively high fees and unpredictable settlement measured in hours or even days (as we saw this Q2 2017). If this were to happen, it would be a radical departure from the original vision of Bitcoin as peer to peer electronic cash that can scale to mass adoption levels without help from intermediaries. It’s likely the majority of the community would view this as a second case of negligence by its developers on top of the 2016 through H1 2017 period. If the developers fail to scale Bitcoin with Segwit2x pragmatically on-chain, one of two sub-scenarios is likely (or to some degree both). Let’s call them “2a” and “2b”:

Outcome #2a:

All but the most hard core Bitcoin supporters abandon both Bitcoin Segwit and Bitcoin Cash. Both versions become the “MySpace” of crypto-currency, giving their P2P payment system market share to cryptocurrencies that handle peer to peer payments specifically as a use case, and their “programmable money” market share to other cryptocurrencies that focus on these areas.

Outcome #2b:

Bitcoin Cash, perhaps because of its simplicity and closer resemblance to the design of the original “Bitcoin”, overtakes Bitcoin Segwit and grows again in the P2P payment system market, while Bitcoin Segwit fades into obscurity as a peer to peer payment system, and either disappears from view or moves into adjacent use cases (like institutional settlement), as “L2 solutions” that preserve the properties and features of the original Bitcoin fail to appear quickly (or ever).

Conclusion

I’m not a betting man, but if Segwit2x reneges on the 2x part of the agreement or fails to scale responsibly on-chain, I just don’t see Bitcoin becoming MySpace. I hope for outcome #1, but if we see a return of ridiculous “double blind auction” fees and unpredictable settlement as a result of inaction a second time, well, my money will be on 2b. Only time will tell!

Will

If you made it to the end you should join the bridge21 community slack here to continue the conversation.