In the years following our fork from BTC, negative events have confronted us affecting the stewardship of a successful cryptocurrency. Loosely, such a stewardship comprises making technical decisions, growing engineering relationships, building the user community, and protecting the essential qualities of BCH. Most of these negative events have not alone been serious enough to risk or cause a fork, except for the Infrastructure Funding Plan (IFP) and the issues leading up to the BSV fork.
But on the technical front, we have failed to deliver many meaningful end-user innovations, instead mostly focusing on internal, janitorial work and introducing purposeless complexity and unnecessary change that consumes engineering time. Three years after the fork, it is incredible we are wrangling over a fix to a fix of a hack. Specifically, ASERT is fixing problems in the DAA algorithm that I identified in simulation and documented before the DAA was merged[1]. And the DAA itself was a fix to the EDA which was pushed into BCH as an unreviewed pre-fork change.
Arbitrary deployment of substandard code and willful disregard of evidence-based analysis is not our only technical problem. We cannot deliver end-user features: zero conf reliability has disappeared for years into an opaque piece of vaporware named “Avalanche” which has discouraged alternatives and at its best will make us a poor copy of the AVA cryptocurrency which, being entirely focused on delivering the best qualities of the Avalanche consensus mechanism, will likely outperform BCH in that regard. And we waste engineering time: we struggle for months to convince ABC to deploy something as simple as increasing the unconfirmed transaction chain depth. This reluctance is more for political issues than any engineering justification.
Let’s take an honest look at Schnorr signatures which is arguably the most exciting feature associated with ABC (note it was Mark Lundeberg who polished and ported code originally written by Core, so ABC’s role was perhaps managing the process?). What features does it provide the end users that they didn’t have already? Signatures? No. Sure, Schnorr does them better but not in a way that’s immediately meaningful to end users. Coin mixing? No, we had that already. But again Schnorr does it better. Do you see our lack of end-user focus?
Our engineering ecosystem is shrinking and suffering a turnover rate unhealthy for a complex mission-critical product. Entrepreneurship is low, with few to no companies using technologies such as CTOR, CDS, Schnorr, and the marginally higher unconfirmed transaction chain depth. Few engineers bother to contribute based on prior experience with a severe not-invented-here syndrome and the theft of their ideas (examples include DSV/CDS, the BCH specification effort, and now ASERT/Grasberg, and efficient, merkle-path-to-coinbase-only block candidate node to miner communication). I am unaware of a single technology merged into ABC from a non-Bitcoin Core client. Regular merges from the Core project that will never scale has put a de-facto soft limit on BCH scalability since ABC cannot deviate significantly from Core and still merge cleanly.
Our user community is qualitatively smaller, shown by the probable departure of SatoshiDice and others, shown by the lack of meaningful token-based efforts, and little adoption of new technologies such as coin shuffle. Notwithstanding a possible “hot spot” in Australia, BCH acceptance piggy-backs on BTC acceptance, essentially depending on BitPay’s continued support of altcoins. Quantitatively, these problems are reflected in a coin price that is highly correlated with BTC, but has fallen significantly against BTC and is likely still trending down when one accounts for the general “rising tide” of all crypto right now and the higher beta (volatility) of a lower market cap coin.
We are also not protecting the essential qualities that distinguishes BCH in the cryptocurrency ecosystem. We gave away the “onchain scalability” narrative to BSV during the BCH/BSV fork and lost 30-50% of our community (based on 2 independent metrics: what the prices settled at and how BU members split). The IFP proposal and resurrected IFP2 proposal attempt to add a per-block tax that in the IFP a small set of individuals with the right political “pull” would receive. But now, in the IFP2, it is an undisguised looting of BCH as the money goes to a single address. These IFPs introduce all the moral and practical problems that would come with governing the distribution of unearned money. Although this proposal was defeated once, ABC has refused to give it up, which is continuing to erode the community's confidence in BCH’s moral grounding as a fair currency.
Looking at the IFP more abstractly, it becomes clear that it would have introduced a central banking cartel to BCH. Notably, Grasberg introduces the same central banking, but this time less overtly, by adding code whose sole purpose is to adjust the inflation schedule. It is true that prior code has changed the inflation schedule, but the primary purpose of that code (or at least the stated primary purpose) was to solve other problems. This is a key philosophical difference from prior algorithms and ASERT, and it changes BCH’s social contract.
By now, it should be evident to most people that these problems stem from ABC and specifically poor leadership in ABC on all four of these key stewardship responsibilities.
In order to effect change we must be willing to risk a fork, because we cannot control the actions of other parties. So we must be so certain that our path is better that a split will be irrelevant long term. I am certain that the path we have taken in the last few years has been disastrous, and I am certain that we can do a better job because among the bad decisions have been voices arguing against them. Bitcoin Unlimited and I have been a leading voice in the argument against every bad decision and we have paid a political price for this. But our arguments have been well researched and carefully reasoned, and grounded in good business, end-user responsiveness, good engineering, and good science.
There are loosely three fork outcomes that will be evidenced by price and hash power. First, the existing BCH but with ASERT fixing the DAA (let's call it BCHfork) may dominate (1), or both forks may end up more or less the same (say within 50%) (2), or ABCfork (ASERT and IFP2) may dominate (3). These possibilities are comprehensive, any decision to “not fork” by one party implies either 1 or 3.
While one solution would be to simply choose a more qualified individual to lead BCHfork, let me propose a different plan. My plan will minimize surprises and allow those who do not share the plan to exit early. My plan is simply to actually HAVE a plan. We must create a clearly defined vision and execute on it. This should streamline development and minimize politics because if people do not agree with the plan, they should not join the community.
With fork outcome 1 (BCHfork has most of the value), we execute this plan at a fast-but-careful pace, cognizant of the trust given to us as stewards of significant value, but realizing that BCH is leaking value and we need strong moves to reverse the trend. In the case of fork outcome 2 and 3 (even split or ABCfork has the most value) we recognize that success in competition to BCH and BTC (and BSV and ETH) is of paramount importance and deliver features at a rapid pace.
Fundamentally, I am not interested in being a leader in the zombie-coin BCH has become, or in a BCHfork that continues in the non-productive manner of the last few years. I am interested in disrupting the entire world’s financial infrastructure. This vision responds to end user use cases or even a good story (because the only way to prove a use case is to create a competitive crypto). This will require that leaders respond to community/user needs and deliver best-in-class functionality matching or anticipating market trends rather than trailing trends. This requires leaders to say YES (pending a security review) before saying no, and for you the community members to say YES and most importantly refrain from saying no to ideas that you have little or no involvement in.
We will require a massive effort to catch up, since the industry and world have moved forward while BCH wasted time with janitorial work. We need to simulate permissionless innovation in an intrinsically permissioned blockchain until the blockchain is itself sophisticated enough to not require such. This will require delegation of tasks, trusting each other’s general competence, and tolerance of imperfect details, rather than having every engineer in this community analyze and become an expert in every proposed technology. This will require that we deliver what we technically see as best now (and iterating as problems become apparent), rather than waiting for an indefinite time for the best solution.
A BCHfork Vision and Roadmap, Loosely In Order of Importance
(HF) Groups: Miner enforced, script-aware fungible and nonfungible tokens, with covenants (contracts that are applied by the token originator to any token transaction). A quantity of BCH can also be placed within a group and therefore be controlled by a covenant.
(HF) Smart contract features: OP_PUSH_TX_STATE (transaction introspection), OP_BUFFER (allows large P2SH scripts), OP_PLACE, OP_EXEC (interfaces the covenant with the redeem script), and others as they become apparent. Groups and these smart contract features combine to provide efficient DeFi capabilities, competing with Ethereum and drawing developers to BCHfork.
Groups, covenants and smart contracts together allow any rule expressible in BCH script to apply to an “opt-in” subset of BCH or to a token. These technologies taken together allow any new BCH script expressible consensus rule to be imported into the blockchain. This functionality will massively reduce the pressure to hard fork to add extra features. It is even possible to constrain the use of new opcodes to specific groups, so that only BCH and tokens in such a group can use the new opcode. If groups are used in this fashion, the risk of deploying new opcodes is reduced since only the value within these groups are exposed to the new opcodes.
(no fork) Doublespend notifications and deep DS notifications
(no fork) Deep unconfirmed transaction chains
(HF) Large Integer opcodes. This is fundamental smart contract infrastructure, but specifically allows efficient implementation of contracts and many other signature or decryption algorithms. Going bigger than 256 bits makes our cryptographic primitive faster and more efficient than ETH which must build big nums out of 256 bit numbers.
(no fork) Counterparty and protocol discovery (CAPD). Allows wallets to discover and interact with peers anonymously.
(simple, bump-a-number fork, but a lot of underlying work for some full nodes) Transaction scalability to 512MB blocks per 10 minutes
(HF) Rapid, efficient UTXO access and UTXO commitments (UTREEXO or Peter Rizun proposal). This helps deliver scalability, and UTXO commitments are very useful in an SPV wallet context.
(HF) Block time reliability and unconfirmed transaction reliability through Storm/Bobtail
Once these features are deployed, we will have a scalable, efficient, smart-contract capable, reliable, light-wallet friendly, DeFi capable blockchain. At that point we need to slow the changes dramatically to focus on application level development. But we will be able to still respond to the community because most desirable extensions will be expressible in BCHscript, and enforceable within group constrained BCH or tokens.
We must then focus on building the end-user applications that this infrastructure will enable. I am not worried about a low value coin. All “alt-coins” today are so low value today compared to the potential market as to be essentially equivalent. And any and every cryptocurrency today is equivalently one “killer app” away from domination. I am worried about the lack of technical progress that will block a killer app from ever being created, and a coin’s value trend showing falling interest by the people who will build those apps. We need to deploy the infrastructure needed for diverse applications and then grow and deliver an ecosystem and community that finds that killer app.
Exactly.