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

8 824

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.

6
$ 29.60
$ 20.00 from @MarcDeMesel
$ 5.00 from @Jake
$ 1.00 from @cashdev
+ 10

Comments

This sounds like a professional social engineering article designed to split the community to me. Anyone know this developer works on BCH? His conclusion the funding implementation "is a malicious and dishonest attack on Bitcoin Cash" seems dishonest or, at a minimum, speculative negativity stated as truth.

The ABC actions have sucked and do make it hard to support them. This article hits many true problems in a very professional manner. The conclusions about intent are just what anti-BCH forces would say.

$ 0.00
4 years ago

Can this be anymore of a disaster. This whole IFP should be scrapped immediately. I can't believe ABC are trying to force this through with so much opposition. He's definitely cutting himself off from Bitcoin cash. I could never trust the guy again. It's a shame because he has such talent. But leadership is something he lacks.

$ 2.00
4 years ago

He is definitely not "cutting himself off from Bitcoin cash". These attacks on his poorly implemented attempt to let the miners donate to the developers are what it trying to split the community.

$ 0.00
4 years ago

BCHD lead developer Chris Pacia who was presumably involved in the planning

I wasn't involved in the planning. My only contribution was the suggestion to use a whitelist instead of a hong kong corporation as the hong kong corporation seemed to be point of contention. My view of a whitelist, however, would be that it would be very expansive.

$ 0.05
User's avatar cpacia
This user is who they claim to be.
We have manually verified this user via some other channel.
Proof
4 years ago

Thank you for the correction, I will edit the article accordingly. Just for the record, do you support the IFP in its current implementation or would you also prefer to be removed from the whitelist (like Jonald Fyookball)

$ 0.00
4 years ago

I'm not a fan of the specific implementation. I'm also willing to give voluntary fund raising a try first but I do worry about likelihood of success and the general community sentiment that we should just let the code sit unmaintained until adoption picks up if voluntary funding doesn't work out.

$ 0.10
User's avatar cpacia
This user is who they claim to be.
We have manually verified this user via some other channel.
Proof
4 years ago

I am not sure if that really is the general community sentiment. There are literally thousands of open source projects that flurish without a financial incentive that is an output of the product they build. I would even argue that a community built around people who develop BCH in their spare time (idealists) or as part of their day jobs is much preferable over a tax like model without roadmaps and milestones. Which code exactly is sitting unmaintained at the moment in your opinion?

I believe if we build up the eco system (e.g. like bitcoin.com is doing it) there will be a huge market pull for crypto / BCH developers to get lucrative consulting contracts or implementation bounties for things a company would require. The reward doesn't have to come out of the coinbase directly.

$ 5.02
4 years ago

Hey, you were well on the right track in this analysis. Kudos!

I have to admit this article in the Bitcoin Cash Node community because it was just too damn prescient.

$ 0.00
User's avatar freetrader
This user is who they claim to be.
We have manually verified this user via some other channel.
Proof
4 years ago