Push Here To Split Chain

1. The current situation

If you've been following my posts here and on Reddit, you know that I've been somewhat torn about the IFP concept. I think there is some merit in discussion of the topic, and hoped that discussion could be allowed to continue to allow consensus to clearly form for or against the plan.

But then Bitcoin ABC, in a move that can only be described as a Mexican Standoff, implemented the IFP anyway, even though the proposal was clearly extraordinarily controversial.

Unsurprisingly for those who understand permissionless innovation, the BCH community immediately began routing around the controversial hardfork, creating Bitcoin Cash Node which will allow miners, exchange, and users to run a highly ABC-compliant client while rejecting the IFP and refusing to pay into it. It's likely that other key implementations of BCH will also reject the IFP plan.

It is my view that the current situation will almost surely lead to a chain split.

Here's why.

• The activation threshold for IFP is quite low: 66%. This means that it will activate even if just under 1/3 of the hashpower rejects it.

• Going into the IFP activation, BCH will have on the order of 1.5-3% of total SHA256 hashpower. This makes it fairly trivial for malicious pools or miners to game the signalling to activate it, then mine either pro or con IFP blocks to cause the different rules to diverge.

• This is amplified by the fact that both ABC and BCN have the famous 10-block reorg protection in place. This means that if IFP activates, and chain lengths start diverging, the chain can more easily split and will not magically reorg back to a unified chain even if a longer, unifying chain is published. The implication is that exchanges can more safely start trading a split token once such a divergence takes place, because they can be more confident the chains will stay separated.

• On top of this, the reader is reminded that all exchanges have a natural incentive to see a token split, as token splits are very good for the trading business. Once the split token starts trading on exchanges, it'll be much harder to manually override the 10-block reorg protection, because it can cause exchange losses.

All of these factors taken together are tantamount to creating a giant red button that reads PUSH HERE TO SPLIT CHAIN.

2. Who bears responsibility for this situation?

Whatever the motivations for the IFP, if/when the token splits, both the proximal cause and the ultimate blame for said split must fall entirely on Bitcoin ABC and anyone else responsible for putting controversial consensus breaking code into the current reference client at the last minute, clearly without community consensus. This is the most contentious change ever introduced to BCH and it wasn't even on the roadmap as of the last Nov hardfork.

(Edit: this just in -- Bitcoin ABC has attempted to retroactively add the IFP to the May 2020 Feature Spec after the feature freeze. This is an unacceptable move to rewrite the history of this "feature" which was never part of the May 2020 spec. This decision, at best, is extremely unprofessional; at worse, is outright malfeasance. Although it has been pointed out that this "spec" is not an "official" spec, the fact that ABC developers are attempting to present disinformation is an unconscionable act that is absolutely not acceptable in a "reference implementation.")

And if the IFP activates, and there results a split between BCN and ABC, it won't be BCN that is the proximal cause of the split. BCN will not orphan a block that pays to the IFP. ABC will orphan blocks that don't. So the "splitting client" is ABC, not BCN.

At this point there is only one way to avoid a chain split given where we are today, and that is massive, overwhelming hashpower either for, or ideally against, IFP. Only by absolutely overwhelming the opposition with extremely dominant hashpower can the risk of a chain split be prevented. Fortunately at this point it does not appear to me that there is enough hashpower to activate IFP, but all we can do right now is wait and keep our fingers crossed unless something else changes.

3. What can be done now to improve the situation?

In my view, the only thing that would really help at this point is for Bitcoin ABC to pull all the IFP code from ABC, [edit: this part is not really needed - update the poison pill magic so that v0.21.2 will not follow blocks created by v0.21.0/1], and declare the effort a misfire /not ready for production, so that no current client actually supports it.

That's really the only thing that would truly prevent splitting at this point, past that we have to wait and hope that massive hashpower floats down from the sky to push so hard for IFP, or against IFP, that there is absolutely no contention. I rate the odds of this happening organically TOO LOW FOR COMFORT.

Past that all we can do is ask miners, pools, and exchanges to reject Bitcoin ABC altogether, and run BCN or another IFP-rejecting client.

4. Conclusion

I'm sure some people might find this analysis harsh. I have tried to stay neutral for some time now, arguing both sides of the issue to find truth where there is any, and hoping to get the community - at least the bit of it around me - to come to an agreement one way or another. But I think the situation is going to require everyone in the BCH community to choose a side in the coming weeks, and be clear and up-front about it. While I have been ambiguously supportive of the general idea of an inflation-funded development fund, I have reached the conclusion that the IFP, in its current form, is an unacceptably controversial change that is much too likely to cause a chain split, and needs to be blocked if at all possible.

I hope that everyone in the community can take the events of the last six weeks as a learning experience and resume working together going forward.

Note 1: the article incorrectly listed the affected releases as Bitcoin ABC 0.12.x; in fact the correct releases are Bitcoin ABC 0.21.x. I have edited the document to remove the mistake.

Note 2: it has been pointed out that there is no "official" BCH spec. The "edit: this just in" section has been updated to reflect this.

Note 3: it has been correctly pointed out that changing the "poison pill" magic is mostly irrelevant and just complicates issues for BCHN. The article has been updated to reflect this.