Historical context for the Bitcoin Cash fork in November 2020
In November 15th Bitcoin Cash will have another hardfork upgrade, and there will very likely be a split between ABC and no-IFP (often referred to as the BCHN chain).
This conflict didn’t come out of nowhere but has been brewing for a long time, some might say even from the beginning when Bitcoin Cash was created. I’m sadly not too surprised that we’ll have another split as it always felt like a question of when, not if.
With this article I hope to give you some historical context and to explain why I’ve felt that another Bitcoin Cash fork was inevitable, and why we’re forking right now.
And I apologize for the long article. If I had more time I would’ve written a shorter one. You can jump to What can we learn from this history lesson? for the point I’m trying to make.
Bitcoin Cash forks from Bitcoin
A blocksize increase was desperately needed in Bitcoin for a long time before Bitcoin Cash. Many people tried to convince developers, miners and other stakeholders but they were ultimately thwarted by Blockstream and the small blocker zealots.
In hindsight maybe people were too nice and wanted everyone to get along, therefore the big block crowd tried to compromise again and again and again. From a dynamic blocksize to an ever decreasing limit of 16 MB, 8 MB, 4 MB and finally 2 MB, but nothing was ever small enough to be acceptable.
People had been trying to create a big block fork for a while, but in the end it was the fork announcement by ftrader (currently the BCHN lead developer) and deadlnix (Amaury Sechet, the lead developer of ABC) that in 2017 gathered enough momentum to later become Bitcoin Cash. They were not the only full-node client as at the time of the fork as there were several others such as Bitcoin Unlimited, Bitcoin Classic, Bitcoin XT and Bitprim.
The “don’t care about others, just do it” mentality was exactly what was needed at this time, but that would come back to haunt us later on.
You either die a hero, or you live long enough to see yourself become the villain.
The first difficulty adjustment upgrade
Very quickly we start saw a problem with the Emergency Difficulty Adjustment (EDA). The purpose of it was to significantly decrease the proof-of-work if no block had been found for a while in order to prevent the chain from fizzling out after forking from Bitcoin, but it did so much too aggressively and it caused periods of extreme block shortage and with extremely many blocks.
For a good article of the EDA and it’s problems, I recommend this article by Mengerian: https://medium.com/@Mengerian/bringing-stability-to-bitcoin-cash-difficulty-adjustments-eae8def0efa4
The BCH developers recognized this as a problem and were working together on a replacement, but in the middle of that process ABC suddenly announced that they had chosen the next Difficulty Adjustment Algorithm (DAA), and it would not be the one that the other developers favored. Their reasoning:
We have the utmost respect for the all developers involved in the discussions, but only one algorithm could be chosen, and a timely decision was required.
Therefore, we decided to take a scientific approach and utilized two impartial and unconnected testing teams: Bitprim and nChain. These teams conducted their tests separately and came to the same conclusion of which algorithm was most appropriate.
In other words, they rushed the decision and let two other teams (Bitprim and nChain) decide the algorithm.
Unfortunately this was not a “scientific approach” as they never released their research methodology or research data, making it impossible for anyone to falsify their tests (a core property of the Scientific Method). The algorithm that was chosen was ABC’s own and it had known problems that caused the unreliable blocktimes we’ve now had to live with for almost three years. This is (finally) something that will be fixed in the November upgrade.
Permissioned tokens
OP_GROUP was a proposal from Bitcoin Unlimited that aimed to bring on-chain tokens to Bitcoin Cash, quite similar to Ethereum’s tokens. I thought it was pretty neat, but unfortunately it was shut down by ABC.
I’m not really upset about it not getting approved (well maybe a little), but what made me really upset was the arguments ABC used against it.
In short they argued that tokens don’t have to be permissionless, and we should therefore use Wormhole as our token solution, which only supports permissioned token transfers. (This was before SLP was invented, which has permissionless transfers.)
Maybe I was foolish to think that permissionless is a big part of why we’re here, and a requirement for tokens to be at all interesting, but what do I know?
OP_GROUP was made with zero feedback and contradictory claims made about it’s planned inclusion such as it has absolutely zero review at this point. When concern are raised, proponent decide to start drama on social media rather than address the concerns. This is a recipe for maximum drama and minimum results.
So he says he feels OP_GROUP was rushed. I disagree, follow the link to see a rebuttal, but let’s say that’s true. Why then has it been 2.5 years, and we’ve made no progress?
The answer to why we don’t have miner validated tokens on Bitcoin Cash is that ABC didn’t want them, and they’ve always given different answers as to why that is. BU recognized that it’s more important to keep the community together than to fight for this change, so they gave in and let ABC have the final word.
Amaury’s “BCash” moment
The 7th of August 2018 Amaury made a post on r/bitcoin, a subreddit with extreme hate against Bitcoin Cash, with the title:
Hillarious: Creator of BCash, has been banned from the BCash Slack. And then they say r/bitcoin is censored
If you’re familiar with Bitcoin Cash then you’ll know that the slur “BCash” is used by trolls to shit on Bitcoin Cash. And here Amaury, the de-facto lead developer of Bitcoin Cash, uses the same derogatory slur to belittle the project in r/bitcoin, one of the most censored and narrative-controlled subreddits there is.
Who’s the one who starts drama on social media again?
The BSV fork
Another huge conflict in the history of Bitcoin Cash was with Craig “Faketoshi” Wright and his nChain company. I won’t rehash the events as it’s not what this article is about, but suffice to say nChain came up with different things to complain about and it ended up with a “hash war” that they lost and they split out into their own coin, BSV.
It’s good that we got rid of Faketoshi but the BSV conflict drowned out technical concerns about another feature that ABC forcefully pushed through, called CTOR.
Here ABC did what they complained that BU tried to do with OP_GROUP: they rushed through a change that wasn’t needed (and still isn’t really used to any significant degree) against the judgement of the other developers. And again ABC got their way, this time because Faketoshi was the bigger enemy and CTOR wasn’t a big enough change to split the community further.
Note that I’m not saying CTOR is necessarily bad, and it will help us scale with things like Xthinner, but there are other ways to sort transactions other than CTOR that would work just as well (or possibly better). For more info I refer to Toomim’s article: https://medium.com/@j_73307/benefits-of-ltor-in-block-entropy-encoding-or-8d5b77cc2ab0
Voting to set the blocksize cap hard limit to 10 TB
In another “maximum drama stunt” both Amaury and Micropresident joins with the BSV trolls and vote that Bitcoin Unlimited should raise the hard blocksize limit to 10 TB. This would have disastrous consequences as we cannot handle close to that size and would at best crash BU nodes and at worst cause a chainsplit.
As to why they voted for it Micropresident had this to say:
FWIW, I intend to vote yes on this proposal. It will be nice to give everyone a chance to see what the limit is for, in the wild, so I can quit hearing about it.
Meaning he knows it would be disastrous, but did it anyway. Maybe in an attempt to sabotage Bitcoin Unlimited, which they’ve had a conflict with since the beginning of Bitcoin Cash.
The unconfirmed transaction limit
Another important issue for Bitcoin Cash is the unconfirmed transaction limit. It means that you’re only allowed to chain 25 unconfirmed transactions in a row before a node will reject them.
This was so important for Satoshi Dice that they announced a 1,000 BCH bounty if we could get it fixed in 2019!
Some developers tried to work on it, but it didn’t go anywhere because Amaury didn’t want to prioritize it:
Shammah says that /u/deadalnix told Shammah that there were other things that he wanted done first.
The limit is there because of poor full-node performance, which ABC backported from Bitcoin Core. ABC has stated their intent to raise the limit to 50, but the fundamental problem is unresolved.
In the meantime other implementations like Bitcoin Unlimited have made large improvements in this area, but without ABC’s support in practice this is still a problem users will face.
The 2 MB soft limit
Bitcoin Cash was created to be the big block alternative to Bitcoin, and today we have a 32 MB limit that would in theory allow BCH to process around 20 times more transactions than BTC.
But in September 2019 when an on-chain stress test was made we discovered that many miners only created 2 MB blocks even though they could create much larger blocks. This was because ABC had a default soft-limit of 2 MB and if miners didn’t change it they would only create 2 MB blocks.
That’s quite a poor display but what’s worse is that Amaury argued that it was dangerous to raise it:
Sure or we can mine large block, so we move the problem from the mempool to indexing node that fill trip over themselves bsv style as they are not optimized to handle 100x the usual demand.
In essence he’s parroting the small-blocker talking point that Bitcoin Cash can’t handle larger blocks. This is completely false and the same stress test showed that we could handle 20 MB without issue, and after some small fixes were made we can do even larger.
But there is a performance problem worth noting; ABC is the least optimized full-node client and it handles large blocks much worse than BU or Flowee for example. By only focusing on backporting changes from Bitcoin Core (which has horrible performance) this self-made problem has been deemed “too difficult and too expensive to solve”.
Avalanche: The solution to everything
ABC’s pet project is Avalanche. It will supposedly make transactions settle in mere seconds, help us scale and even protect us against the dreaded 51% attack.
Sounds too good to be true? Then it probably is.
There has been no response to the serious concerns people have raised against Avalanche, including how it overrides proof-of-work and changes the consensus algorithm of Bitcoin Cash. (They have responded by dismissing the concerns without actually addressing them.)
Despite us needing a ton of research into how we could safely integrate Avalanche with proof-of-work ABC still pushes ahead with Avalanche as if it’s already been decided on. Even if Avalanche can be made to work the best estimates puts it years away from integration, yet it’s still used to dismiss other improvements such as double-speend proofs, which is a simple way to radically increase the safety of 0-conf.
Ever heard of the vaporware called Lightning Network, and how Bitcoin developers declared that it would solve all their issues? How it was used to prevent a blocksize increase? And how that was years ago yet it’s still nowhere near ready? Avalanche for Bitcoin Cash follows the exact same pattern.
The IFP
Jiang Zhuoer of BTC.TOP was the one to present the first version of the Infrastructure Funding Plan (IFP) for Bitcoin Cash. The plan was to force all miners to send 12.5% of the coinbase to a Hong Kong corporation that would be in charge of dispersing them to full node implementations and other critical infrastructure.
This proposal wasn’t received too well by the community so Zhuoer quickly issued an updated proposal where miners would send funds directly to the projects they wanted to support, bypassing the Hong Kong corporation. It would be activated by miner vote and there would be a pilot period. To “avoid the tragedy of the commons” it was also necessary to let miners burn their funds if they wanted to.
ABC, having complained often and loudly about the lack of funding, jumped on the opportunity and announced their own version of the IFP. It differed from the other proposals, the most significant change was that funds could only go to one of four projects: Bitcoin ABC, Electron Cash, BCHD and a “General Fund” (which wasn’t explained further) and it did not allow miners to burn their funds.
I wasn’t a fan of the IFP and the unhealthy incentives that would lead to centralization, while failing to solve the tragedy of the commons and it also wouldn’t prevent the Blockstream takeover. Or how the proposal would only send money to Amaury and his friends, using arbitrary rules to disqualify competing projects such as Flowee or BU.
Neither was the community and the IFP caused a bunch of developers who had grown so tired of ABC that they launched another full-node implementation called BCHN, which would be a drop-in replacement to ABC. If the IFP was activated BCHN would also follow it, but it presented a very easy way for miners to switch away from ABC and it quickly become the biggest alternative to ABC.
The IFP was ultimately rejected by the community and all miners (only a few blocks voted for it by accident) and even Zhuoer himself vowed to vote against it.
Flipstarter
The IFP debate did raise an important issue: how would Bitcoin Cash infrastructure be funded? If not by the IFP, what then?
Enter Flipstarter. It was a non-custodial Kickstarter where projects would only get the money if it was successful. During the IFP debate the full-node campaigns of BCHD, Bitcoin Verde, BCHN and Knuth were successfully funded, showing that projects can be supported without the IFP.
Notably ABC ran a Flipstarter of their own, but it failed to complete. Maybe because people didn’t think they’ve done a good job so far or because the hate against the IFP was so strong.
Grasberg
After three years of large blocktime variance, with them becoming worse as more miners started to abuse the DAA, some developers had decided that enough was enough. Their efforts culminated with Jonathan Toomim’s proposal to use ASERT as the new DAA.
It was an excellent proposal and incredibly well researched. Bitcoin Cash developers all over praised the effort and were happy that we might finally be able solve the problem with blocktime variance. It was even looking like Jonathan would be able to convince ABC of the importance to fix this issue, even if he had to “talk privately” with them about it.
But out of the blue ABC announced that they were “moving forward with the Grasberg DAA”. And it was different from ASERT. The reason given was that “no concrete proposal has reached ABC at the time of this writing”, despite them being obviously aware of the work Jonathan and others had been doing. (They even copied parameters from Jonathan’s proposal.) This is the Not Invented Here Syndrome in action.
Remember how ABC shut down OP_GROUP because they said it was made with zero feedback and that it was too rushed? Notice the parallels to how ABC announced Grasberg.
Except for how the development was handled, there were other serious problems with Grasberg:
It changed the blocktime to target 11.25 minute for the next 6.5 years, even after Amaury himself wrote a long article that explained why we shouldn’t change the blocktime.
It changed the coin emission schedule which would weaken the sound money properties of Bitcoin Cash.
ABC forced many people to waste a lot of time to argue against Grasberg. If you want to see their arguments in video form I can recommend the Bitcoin Cash DAA Development meetings: #1, #2, #3. (If you want drama then watch how Amaury rage quits in the middle of the third meeting.)
If the arguments are too technical for you then just look at how Jonathan produced incredibly detailed research of ASERT, Grasberg and numerous other algorithms, but ABC produced nothing. The only argument was that they “had already run simulations” and that we should take their word for it (or not, because they had already decided to deploy Grasberg regardless of input).
This might be good enough in kindergarten, but it’s woefully inadequate for a project that aims to provide peer-to-peer digital cash for the world.
Many different people recognized how bad Grasberg was and they issued a statement that said they would go forward with ASERT. This included all other node implementations and major infrastructure like Electron Cash, CashShuffle and SLP.
The IFP bait-and-switch
ABC continued to spend an excruciating amount of effort to defend Grasberg despite all it’s flaws and it was really looking like this was the hill ABC wanted to die on. No matter the argument, they just wouldn’t budge.
And then they silently dropped it, never explaining why or mentioning it again.
Success! Everything is awesome! BCH can stay together and we’ll all live happily ever after! Wooo!
… Unfortunately not. ABC announced that they would implement a 8% coinbase rule that diverts miner rewards to themselves. Because the miners didn’t activate it the last time, this time it will just activate regardless of support.
If you’ve been following ABC’s behavior then this shouldn’t be terribly surprising. NilacTheGrim even called it exactly:
ABC will do something incredibly wreckless to almost guarantee a split of BCH come Nov. 15th 2020. And the most likely thing they could possibly do is push a consensus change that pays them directly from coinbase, as they attempted to do last time, but this time it will have no BIP9 voting/activation – it will just automatically activate Nov. 15th.
This will indeed almost guarantee a split in November, and it was pushed through in an incredibly reckless manner without care for the harm done to Bitcoin Cash.
What can we learn from this history lesson?
For me these events teach us two very important things:
Amaury and ABC doesn’t collaborate well, if at all.
They present their solutions, without research to show why it’s good, and threatens a chainsplit if anyone disagrees. They also act as a blocker against other improvements, again threatening a chainsplit to get their way.
They do not have the best interest of Bitcoin Cash in mind.
If they did they wouldn’t threaten a chainsplit all the time and instead they’d recognize that splitting the community is the worst case scenario. They would acknowledge that something like the IFP has extreme resistance, and would back away.
This is why a split was inevitable, because it was bound to come a point when ABC would recklessly push for something that would be important enough for the community to risk a split over. The trigger could’ve been Avalanche, it could’ve been Grasberg and it ended up being the IFP, but ABC is the root cause of the split.
Where do we stand?
It’s impossible to say with 100% certainty what will happen in November, but we can try to make an educated guess. Because all metrics we can come up with show the same thing:
57.4% of all blocks the last 7 days are signaling for BCHN and 0% for ABC.
98.75% of coins support BCHN against ABC, and only 0.02% support ABC against BCHN.
Users on social media have overwhelmingly declared against IFP.
This also includes all other full node implementations (BCHN, Flowee, Verde, BCHD, Knuth, BU) and all wallets except the wallet built into ABC itself.
Therefore it’s overwhelmingly likely that ABC will receive minority hash and fork away to their own new coin.
If you read the marketing material ABC has produced you might get a sense that it’s not so clear cut. But as Josh Ellithorpe, developer of BCHD, says ABC is being dishonest:
Thanks. Appreciate the kind words. To be very clear if the IFP chain is the majority chain I am leaving BCH and taking down all my public infra. The SLP devs are also anti IFP. I am quite upset that ABC is trying to frame us as supporters…
They didn’t even talk to us about this article. Their current marketing and social media presence is super dishonest to make it appear the IFP has support when it doesn’t. Yet another instance of ABC losing my trust.
In the referenced article ABC praises BCHD and SLP and that they would receive some of the IFP money, but the reality as that both BCHD and SLP have declared against the IFP.
To infinity and beyond
After no longer having to abide by ABC’s approval suddenly loads of improvements that were paused or abandoned have started development again:
Significantly raising or removing the unconfirmed transaction limit.
On-chain tokens are being considered again.
Block propagation tech like XThinner that would allow us to raise the blocksize limit much higher.
Double-spend proofs that will improve 0-conf security.
BCHN will focus on optimizing the poor ABC performance.
Actual research into the feasibility of pre-consensus solutions.
And more.
You might be worried that Bitcoin Cash will have to suffer through yet another split, but I’m instead more bullish for Bitcoin Cash than ever, and after we replace the reference implementation in November we can show the world that the development in Bitcoin Cash is truly decentralized.
Explained, very extensive, but I honestly enjoyed reading the text, which is great 👍👍