Embrace The Coming Bitcoin Fork (2 of 3)

Addressing the objections to why a fork shouldn’t be embraced

(Not convinced? Read Part 3 of The Article Here)

Objection 1. Didn’t you see what just happened with Ethereum’s Fork?

Yes, there was a lot of debate and drama in the Ethereum community leading up to their fork and it was surprising to many that the fork resulted in two sustained blockchains. However lets put aside for a moment those fresh emotions and look rationally at the outcomes of this surprising event.

A. The Ethereum network (now two networks) both continue to function.

B. Developers and early Ethereum contributors who had stepped away due to differences with the Foundation have returned to join Ethereum Classic and there are now a net greater number of developers working on the two versions of Ethereum than there were before the fork.

C. Instead of those fundamental differences producing endless fights in the forums, the two groups have parted ways and are now back to focusing on building their particular visions for Ethereum.

D. While its still early to say what the long term view of the market will be for each project, so far the market cap of the combined Ethereum projects is roughly equal to that of the market cap of Ethereum prior to the fork.

Objectively based on at least these four metrics of function, developer engagement, community focus, and market value, the Ethereum fork has either been neutral or beneficial in the short term.

Objection 2. The Bitcoin protocol & network is not a normal software project and forking shouldn’t be taken lightly

I don’t in any way take a contentious fork lightly. This is a serious topic with a lot of economic and technical variables at play. I’m not suggesting that forking in general should be a first resort, quite the opposite, I view forking as a last resort, after all other options for reasonable consensus have been exhausted. With that said in the case of Bitcoin we are nearing that last resort, having attempted every other means of healing the divide.

I deeply understand that Bitcoin is a lot more than a typical software project with stand alone code. Bitcoin is all the hardware that secures it, exchanges that trade it, wallets that store it, merchants that accept it, and people that use it, not to mention all the software built on top of it and that is interoperable with it. So forking Bitcoin is going to take much more energy and planning than a traditional piece of stand alone software, but I think it may be worth that short term cost.

Protocols and large networks specialize and change over time. Certainly low level protocols change less often than stand alone software or even programming languages, see the timeline for major HTML version updates, there have only been five from 1991 to 2014, that’s an average 4.6years for each version. We are now in the 8th year of the Bitcoin Network so it doesn’t seem unreasonable that once a decade or so a protocol and network like Bitcoin would require a fundamental change.

Objection 3. What about the confusion resulting from having two networks and digital tokens named Bitcoin?

Yes, having two versions of of Bitcoin will lead to a bit of extra confusion. Just as every programmer flinches when someone non technical confuses Java and JavaScript. However that seems a small price to pay. There is no question the world is better off with both Java and JavaScript, the name confusion aside. The same would be true of Bitcoin Unlimited and Bitcoin Core.

If we look to the recent Ethereum fork as an example, the names of the projects quickly got differentiated, different symbols were selected for trading, different forums and discussion channels quickly formed. Yes from now on, you will be specifying Ethereum or Ethereum Classic, but again that seems a small price to pay compared to the future value of two projects with different value propositions.

Objection 4. Won’t this create 42,000,000 bitcoins and hurt bitcoin’s non inflationary reputation?

Yes critics will claim this is a form of inflation. And even some bitcoiners have used this type of thinking in the past to make the case for why alt coins are bad. This line of thinking goes something like, people will view Bitcoin as not having value because anyone can create a fork and make more units in a competing project. While people will say this, I don’t think this line of thinking holds water, any more than it did about other crypto projects.

Those that used this line of thinking in the past, aren’t making the case as loudly these days, as non Bitcoin projects have vastly grown in value, right along with Bitcoin’s growth in value. Today there are $2.3 Billion in non Bitcoin crypto token assets. Clearly having more tokens in the blockchain universe has not undermined either Bitcoin or the value of these other projects.

Yes it will be annoying to explain the fact that Bitcoin Core and Bitcoin Unlimited are two different projects now, but critics will be critics. Honestly Bitcoin’s reputation is being more damaged by all the fighting and lack of resolution more than any bad press the fork is likely to generate. Especially if the fork is seen as an implementation of a solution to the problem.

Objection 5. Shouldn’t we just wait for 2nd layer tech to solve this?

2nd layer tech is great. I’m a big fan of building additional decentralized networks on top of Bitcoin. However I’ve come to the conclusion that much of the rift won’t be solved by technical solutions and for those issues technical solutions address, the decision to wait for them to arrive has a real cost.

First, lets say for example you are a user, developer or business who firmly believes in the need for bigger blocks and for Bitcoin to become a massive transnational network in general. You could continue to be frustrated, vent via forums online and impatiently wait on the development, distribution and eventual adoption of 2nd layer solutions to offer scalability. Perhaps eventually you lose confidence in Bitcoin and sell all your bitcoins and join another crypto project more in line with your view of on chain scalability. These less than optimal, fester or quit type options are a reality and it is causing Bitcoin lower engagement from users, a more toxic developer environment and a loss of value that was stored in Bitcoin.

Second, lets say for example you are a user, developer or business who firmly believes in the need for smaller blocks and for Bitcoin to be a reliable store of wealth and a global settlement layer. You wish the Bitcoin developers would be less distracted with all this debate, quit spending so many hours on Reddit, IRC or the forums when they could be coding up the future of Bitcoin. These users would benefit just as much from the improvement in the community environment post fork.

Third, lets say for example you are user, developer or business sitting on the sidelines who has a use case that requires high volumes of transactions. You are thinking about using bitcoin, however you have to delay adoption. Neither the 2nd layer, nor first layer solutions are ready yet for you to use. You look in from the outside and see a lot in infighting and as a result less progress being made. Perhaps you leave and build your project on a different technology that is working toward serving your use case.

In the end even after 2nd layer solutions mature, there are just a lot of fundamental differences that have evolved and resulted in a split in the Bitcoin community. In the mean time, the next 12 to 24 months could be better spent if there was a fork and the two communities could each move forward on their preferred path.

Objection 6. What about Replay Attacks and Technical Issues?

There are a lot of technical objections that can be made, which generally are too lengthy to cover in this article. However its fair to say that a lot of coding would have to be done by the bitcoin developers, exchanges, wallets, and others in order to prepare for a fork and adapt to the reality after the fork.

One issue that would clearly need to be addressed is “replay attacks”. The Ethereum fork highlighted this attack vector, but with knowledge of the issue has come a number of technical solutions to address it. Here is a recent article about how this might be done best in the case of a Bitcoin fork.

Even knowing these issues that must be addressed and the extra work it will create, the amount of effort required to accommodate a fork seems to be smaller (if its anywhere similar to the month or two it cost Ethereum developers) compared to the high cost of continued fighting, delay, frustration, and opt out by users, developers and businesses for another 12 to 24 months.

Objection 7. Who are the Developers of the Fork Going To Be?

This I think has been the sticking point in the debate thus far when it comes to the viability of a Bitcoin fork. Only a few well known developers have proposed created alternative versions of the Bitcoin code base, mostly notability Gavin Andreason and his work with Bitcoin Classic, though more recently Bitcoin Unlimited seems to be gaining traction both in funding of its development and now hash power exceeding 14%.

Those now discussing a fork seem to be looking to leverage Bitcoin Unlimited as a respected implementation of Bitcoin and introduce only small tweaks that would trigger the fork with less hashing power than the original 75% level proposed by Classic, (25% or 50% for example).

Objection 8. If its just a fork to 2MB blocks then won’t the Bitcoin Core developers just merge that change and bring the forks back together?

Andreas Antonopoulos has a wonderful talk on the topic of Bitcoin Scaling and comparing it to the early repeated challenges to scaling that the internet faced. He points out how people consistently underestimated how new optimizations and clever technical solutions would emerge to solve bottlenecks as users discovered every greater bandwidth sucking use cases, from Usenet messages, to email, to images, to video and eventually 4K streaming.

I agree with many of the points that Andreas makes in this talk and toward the end he points out that if a Bitcoin fork did take place, say to 2MB blocks the developers at Bitcoin Core would likely merge the change and thus close the rift. While this is a possible outcome, these comments were made before the lessons of the Ethereum fork, and also presuming a majority fork at say 75% as proposed by Bitcoin Classic’s implementation. I’m not sure this would be the case today post the Ethereum fork or for a minority hash power fork.

Not convinced? See part three, Embrace The Fork, Why A Fork Is Coming