Create a Bitcoin ABC spin-off now - A developer's analysis

Disclaimer: This article is calling for an unofficial software modification of the Bitcoin ABC software. In the developer world, the process of making a modified copy of an open source project is also called "forking". This is very different from a coin/network fork which we should prevent at all costs.

Today Bitcoin ABC released version 0.21 which includes support for Amaury Séchet's Infrastructure Fund Plan.

It forces miners to give 5% of all block rewards and fees to Amaury or projects hand picked by him or to an unknown "General fund", presumably a Hong Kong company.

A lot of articles have been written about why this is a bad idea, today I want to highlight the way this was implemented in a very deceitful way.

While Amaury claims that he was only implementing wishes from an unknown miner, there are multiple concerns with the way it was chosen to be implemented:

No Time Limit

Nothing in the implementation has a time limit on the funding period for the IFP. It is unlimited until Amaury decides to release a new version that disables it and thus stops funding to himself.

A non-malicious developer would code an automatic end to the IFP, at the very least to make the intention of removal in the next version clear.

Modified BIP-9 Threshold

The article ABC posted , the one presumably agreed upon with BCHD, lists BIP-9 as the method of decision. BIP-9 is a concensus method that specifies a threshold of 95% agreement to prevent a chain split due to contention. In the actual implementation however, a lower threshold of 66% has been implemented. It becomes obvious how misleading this is if even the whitelisted BCHD lead developer Chris Pacia who was presumably involved in the planning was surprised to learn that the implementation only requires 66% agreement instead of 95%.

A non-malicious developer would stick to the the specification of a well thought out proposal in order to find out if there is enough agreement for a proposal to prevent a chain split.

Hardcoded Whitelist

ABC has unilaterally decided which hard coded wallet addresses are allowed to benefit from taxation:

• Their own (does anyone know which individuals have ultimate control over it and how funds will be split amongst ABC developers?)

• Electron Cash (despite its lead developer Jonald Fyookball withdrawing his support for the IFP in its current form and asking for removal from the whitelist here )

• BCHD (their lead developer Chris Pacia was expecting the proposal to require 95% BIP-9 consensus, not 66% )

• a "General Fund" - an unknown, unmonitored and non-transparent entity, presumably a Hong Kong company with an unknown shareholder structure, unknown management, unknown rules, unknown intentions

Corresponding source code is here .

Notably, other valuable open source projects like Bitcoin Unlimited, Bitcoin Verde, bitcoin.com wallet and many others have been omitted from this list. There is no way to get them on this list unless Amaury decides to include them.

A non-malicious developer would not hard code their own wallet address in this way. A non-malicious developer would search consensus on the list first and then implement it in a way that can be easily accessed by other implementations and updated to include new projects. A non-malicious developer would not add any entry to this list that is not community reviewed (General Fund).

Misleading Parameter Name

They introduced a new parameter called enableminerfund. This name is very misleading because this parameter is not required at all to enable the miner fund. If it is omitted, the fund still gets activated and blocks without taxation get ignored after modified BIP-9 activation. You have to call bitcoind with -enableminerfund 0 in order to get it to accept blocks without taxation (after modified BIP9 activation).

Hiding the Parameter

Unlike most other parameters, the parameter was added as a hidden parameter. This means it will not show up if you call bitcoind with --help and there is no way to find it unless you inspect the source code.

A non-malicious developer would not choose to hide such a contentius feature.

Omission of the Parameter from Documentation

The new parameter enableminerfund was not included in the documentation update.

This could be an oversight but is more likely intentional because previous updates did include new parameters in the man pages, see for example the addition of -enablebip61 .

A non-malicious developer would recognize the controversy around this feature, add the parameter to the documentation and clearly highlight its importance in the release notes.

Automatic Consensus

Even if you go through the source code, find the parameter and set it correctly, your ABC mining node still will NOT vote against the IFP. Consensus to the IFP is hard coded as you can see here .

There is NO way to configure ABC to vote against the IFP unless you change the source code and compile a modified version.

If enough miners run an unmodified version 0.21 of Bitcoin ABC, the modified BIP-9 consensus (66% of blocks consent over any 14 day window) will be ensured way before the May upgrade.

A non-malicious developer would give the user a way to set this consensus decision.

Conclusion

In conclusion, the way this was implemented is a malicious and dishonest attack on Bitcoin Cash.

If we want to stop the IFP, we have to:

• Create a modified copy (software fork) of Bitcoin ABC in order to create a version that is compatible to ABC but forces the user to make their own choice regarding IFP

• Develop an easy upgrade path for miners from the corrupted project to the clean one

• Publish these upgrade pathes and spread awareness for the need of the modified version

A more agressive approach would include a hard coded vote against the IFP and the removal of the malicious IFP code. However I fear that this would be open to similar criticism as Amaury's approach and would risk the modified version not following the "correct" chain in case the malicious attack succeeds. On the other hand, people could still pick between running ABC 0.21 or the new modified version of it.

A last resort would be a hard fork of the entire Bitcoin Cash network but we should all strive to prevent that.

Edits:

20200219 Fixed incorrect presumption about BCHD participation in the planning.

20200220 Replaced the word fork where sensible to avoid misleading those who are not familiar with its usage in the software world

20200220 Fixed gammar mistakes and added the fact that miner choice could be accomplished by choosing between untouched ABC and the modified version.

20200220 Clarified that Jonald Fyookball withdrew support for the current form, it is unclear if he is against the IFP completely. Since the time of writing, Jonald also wrote an article that sounds like he is rejecting the idea altogether.