Background
On 18th Feb 2020, Bitcoin ABC released their 0.21.0 Bitcoin Cash client which included two consensus changes to the Bitcoin Cash protocol. The highly controversial change is the Infrastructure Funding Plan mining tax (IFP Tax) . This forces miners to send 5% of their block reward to a whitelist of addresses controlled by BitcoinABC, Electron Cash, BCHD, and a ‘General Fund’ or risk losing the whole block reward. This major change was added against the wishes of the significant majority of the BCH ecosystem. Furthermore, it was done without proper development community debate, which was one of the key areas meant to differentiate the guidance of BCH from Core-controlled BTC. As at the date of this article, the bitcoincash.org website also does not carry a specification of the IFP Tax.
In response to this, a new team of BCH protocol developers was formed called Bitcoin Cash Node with a focus on reducing the new systemic risks created by Bitcoin ABC. Also, after a successful vote in favour of BUIP143_Refuse_the_coinbase_tax, BU has now released the latest version of our Bitcoin Cash client, BCH Unlimited which does not implement the IFP.
The Bitcoin Cash ecosystem is now faced with a choice on how to move forward in the face of the current crisis. We felt it would be beneficial to provide some extra clarity on what options we have and what potential scenarios could occur.
Our Options
The BCH ecosystem now has multiple options to make our voice heard.
BCH Unlimited
The new BCH Unlimited client is effectively a vote against the IFP Tax. In fact it does not recognise the tax functionality at all and instead will always follow the majority hash-rate both before and after any IFP Tax activation. If a majority of miners/pools run BCH Unlimited or BCHN then the IFP Tax will never be activated.
Bitcoin Cash Node (BHCN)
Like BCH Unlimited, the BCHN client disregards the IFP Tax and is effectively a vote against it. It will continue to follow the majority hash-rate in all scenarios.
Bitcoin ABC
BitcoinABC version 0.21 votes in favour of the IFP dev tax by default, which means that any miners who run it will be voting in support of the tax. Currently no miners are doing this. BitcoinABC version 0.21.1 votes against the IFP Tax by default. BitcoinABC is the only client that will enforce the IFP dev tax after activation. This means that BitcoinABC nodes will not consider any blocks that do not pay the tax to be valid and will fork them off the network.
Other Clients
There are other great BCH clients including Bitcoin Verde, BCHD, Flowee, Knuth but these are not currently suitable for use in mining.
Flipstarter
While this is not a way to vote with your node, Flipstarter certainly is a way to vote with your wallet. Flipstarter.cash is an excellent initiative to use the amazing tools that the Bitcoin Cash technology provides to get voluntary funding to BCH development teams. By using Flipstarter to support the projects you think are valuable you will be helping to accelerate BCH development!
Possible Outcomes
1. Development Tax Isn’t Activated
If the IFP Tax is not activated (unless it is implemented in future versions of BitcoinABC’s clients) it is likely that the immediate crisis has been averted. But this leads us to the issue of how the crisis came to occur in the first place, and that issue is the lack of decentralised development within BCH.
One of the initial goals at the creation of BCH was to escape the systemic risks of leaving all control of the protocol to a centralised development team. This was the key cause of the failure of Bitcoin BTC when it was purposely constrained so that alternative, rent-seeking funding models could be built. Unfortunately, even with a keen focus in this area, BCH has fallen prey to this faulty, centralised development model. But we now have an opportunity to change that for the better.
1.A. BCH Loses Decentralised Development
Even in the scenario where the IFP Tax is defeated, it is very possible that the status quo is maintained and that the BCH ecosystem continues to face the problems that centralised development causes. It is likely that if this occurs then crises such as these will continue to pop up and that BCH will continue to lose market share to more agile and effective cryptocurrencies. Perhaps more importantly it will continue to shed valuable and talented people as they become disenfranchised by the centralised leadership of BCH.
In effect, we will have won the battle but lost the war.
1.B. BCH Gains Decentralised Development
From all the potential scenarios this is the best outcome. Many effective development teams would be given a seat at the table. This would allow a development model where many dev teams both collaborate and compete to produce the best possible infrastructure for BCH, thereby allowing significant features to be worked on in parallel. Should a bug be found in any one client, there will be plenty of redundancy as multiple clients will be available to run. This will also mean that governance will become more decentralised making crises much less likely to occur.
To achieve the above, BCH miners, pools, businesses, and users must run and support many different clients, including BCH Unlimited, BCHN, Bitcoin Verde, BCHD, Knuth and more.
2. The IFP Tax is Activated
In this scenario the IFP Tax as implemented in the BitcoinABC client will become activated. For this to happen at least 66% of 2016 blocks before May 15th, 2020 will need to signal in support of it, i.e. will need to have been created by miners running either BitcoinABC 0.21 or BitcoinABC 0.21.1 (with default signalling changed). If this occurs then these new IFP Tax rules will be included in the protocol changes made to BCH during the next scheduled hard-fork.
Once the IFP Tax has become activated, all blocks must send 5% of their reward to one of the few whitelist addresses. If a miner does not follow this consensus rule they will be forked from the network and this creates a significant risk to BCH. At this point, any miner which is not allocating 5% of the block reward to the IFP will get its blocks orphaned.
2.A. Majority of Hash Power Remains in it
If a majority of BCH hash power remains on this new hard-fork then all major BCH clients will follow along on this chain, as will all SPV wallets. BitcoinABC has successfully implemented a tax on the BCH network and will have become the official client and development team for BCH. It is possible that if this occurs, many in the BCH ecosystem who have strongly voiced their opposition to the IFP Tax will be forced to use their final and most powerful voice, exit.
2.B. Majority of Hash Votes Against
If the IFP Tax is activated but a majority of hash power then does not follow the consensus rules of paying the 5% tax to one of the whitelisted addresses, then an unplanned hard-fork will occur in the network. If this happens it is likely to cause a huge amount of confusion and even potentially a hash war. On one side of this unplanned hard-fork will be BCH participants running BitcoinABC and on the other side will be BCH participants running all other clients (e.g. BCHUnlimited and BCHN).
The likelihood of this happening if the IFP Tax is activated is unfortunately very high. BCH currently has less than 1% of the SHA256 hash-rate. This means that a very small amount of SHA-256 hash power will be able to move to the BCH network simply to cause an unplanned hard-fork and cause chaos for the BCH ecosystem.
Summary
If the BCH ecosystem is able to take this opportunity to not only avert a major crisis, but also to fix one of its major structural problems, then it will be stronger than ever before. By running BCH Unlimited or BCHN, ecosystem participants can stop the IFP dev tax and support decentralised development.
Also, by supporting voluntary funding systems such as Flipstarter.cash and funding BCHN, BCHD, Bitcoin Verde, and Knuth, we can get funding to where it will be most effectively used, and in a way that does not corrupt the fundamental tenets of Bitcoin.
We are confident that this can happen with the amazing community and industry we have all built together.
Imagine Bitcoin Unlimited!
Update: BU as an organization is committed to forking if the IFP activates. Since the IFP so far has little support, the current BU 1.8.0.0 follows the majority hash. However, this may change as the situation evolves, up to and beyond the fork. In the case of a "surprise" IFP activation, BU is committed to immediately releasing a forking client, and existing BU nodes can be configured to reject the IFP forking block.
Update 2: The bitcoincash.org website does contain a specification of the IFP dev tax. It is worth noting that this was added to the specification against the wishes of the majority of the BCH ecosystem, including most developers.
Nice content for readers and it's very useful thanks.