Bitcoin Cash and Bitcoin SV, Stop The Self Destruction
In the weeks approaching the fork, ad-hominem attacks were tweeted and positions were taken that made the BSV fork inevitable. But fracturing of the community is by definition counter to our goal of one worldwide cash, so we should not be happy about this outcome. For people who are still confused and shaken by the experience, let me try to offer an interpretation and philosophical structure around what happened.
First, as I mentioned in BUIP098, the proposed changesets were mutually compatible so this split did not need to happen at this time. But in truth, this was intentionally a surface observation, and was meant to remind participants of our common goal.
In reality, there is likely a fundamental philosophical difference underlying the split. In particular, Craig Wright has advocated for (but note that the SV client has not fully implemented) a return to Bitcoin 0.1 functionality. The work to return to Bitcoin 0.1 can be separated into two philosophically different categories. First there is the re-enabling of 0.1 functionality (evolve the blockchain), and second the restriction of new functionality and even removal of post 0.1 features (freeze and revert the blockchain).
Where BSV wants to re-enable 0.1 functionality, its plan is compatible with BCH . But where BSV wants to restrict additional functionality, its plan is incompatible. By restricting additional functionality, you reject other people’s use cases and needs. BSV advocates will now argue that all needs can be handled in layer 2, but this is a hard argument to prove, especially in the face of the inability of Bitcoin Cash script to express simple ideas like enforcing equal payment to 2 outputs (see this article for more details). Restricting functionality guarantees that they will find other solutions, which is not the road to a worldwide currency.
But BCH is guilty of similar conservative behavior. There are many examples, but clearly the denial of changes proposed by the SV group in favor of the deployment of controversial ABC features was the immediate cause of the fork. And, in a move nearer to my heart, the denial of OP_GROUP tokenization has put us in a situation where BCH delivered many competing token solutions late to the market, with poor support, and even poorer uptake.
This philosophy of control and restriction is not how I helped the large block community gel from a bunch of angry voices into a unified force. You may think that that split was about large blocks, but it was just as much about an attempt to create an inclusive community in the face of Bitcoin Core’s infamous insularity. The BU Articles (produced alongside our first release) seek to give many people a voice in decision-making. But to my dismay the BCH community rapidly moved in a different direction.
We will create worldwide cash by being inclusive, not exclusive. Along with many non-ABC developers, I was not happy with CTOR. And the irony is that its proponents strongest concrete justifications, scalability and graphene, are areas which Bitcoin Unlimited has the most experience. Using those features as justification is, honestly, offensive since it completely discounts Bitcoin Unlimited’s work in these areas. Should I have made insulting tweets, created BU coin and fractured the community into thirds instead of halves? How will that help us create worldwide cash? This criticism applies equally to BCH as SV — both coins forked in November. Instead, I personally implemented CTOR in BU, because some people perceived a need, and it does not affect security, does not undermine coin value, and has a manageable albeit high (it touches tons of consensus code) risk of a bug that would cause an accidental fork.
If a coin and community is exclusive we will fracture into irrelevance. Most people adopt solutions to solve specific problems, not to chase theoretical ideals like trustless, uncensorable sound money. So we will not create worldwide adoption by rejecting people’s needs. We will create worldwide adoption by accepting people, understanding their needs, and implementing solutions. This philosophy does not mean we rush off and implement every bit of functionality as requested, but it does constrain us to work with people to discover a solution that fits our (the blockchain developer’s) needs of security, efficiency, and trustless sound money, yet most importantly meets people’s needs to their satisfaction, not ours. And yes, this may mean that we implement some things that turn out to be unused right now. Every successful project has similar baggage. For example, entire bitcoin scripting system could be considered unused baggage right now — the functionality that is actually used could be easily implemented without a complex scripting language. The HTTP web protocol has a piece of unused “baggage” which is error 402 “payment required”. Can we co-opt “useless baggage”, delivering BCH payments integrated into HTTP? What we see as unused functionality today may be an essential part of daily use for some people tomorrow.
As the Bitcoin Core group learned a year ago, needs do not disappear if not met. People do. To create a worldwide currency, we need to include the world. We now have three forks, BTC, BCH and BSV. Although its ultimately up to BU members, I have gotten criticism for supporting both BCH and BSV (and remember BU also nominally supports BTC — yes, we haven’t updated our BTC release for quite some time, but its still useful as a no-segwit wallet), but both sides are responsible for this fork. There is no good choice right now.
The coin that becomes worldwide currency will be the one that stops the sniping, and adopts an inclusive philosophy oriented towards meeting people’s needs while preserving the trustless, uncensorable, permissionless, peer-to-peer, sound money features that make the blockchain innovative.
