On January 22, 2020, a group of BCH mining pool operators (including Jihan Wu of Bitmain) came out with an announcement to establish a mandatory dev tax in the Bitcoin Cash (BCH) network. For a trial period of six months, these pools will allocate 12.5% of all BCH block rewards to a developer fund. To prevent free-riding from other miners, they further announced they will orphan any block that doesn’t donate to the fund.
Source: Infrastructure Funding Plan for Bitcoin Cash — Jiang Zhuoer (BTC.TOP)
An orphaned block is an otherwise valid block (including sufficient PoW) that did not make it into the canonical chain. Orphaning can happen organically when two miners find blocks at the same time and only one of them can win. Blocks can also be orphaned by an attacker when he replaces the previously canonical chain with one that the attacker made.
Orphaning allows a miner (or group of miners) with >50% hashpower to allocate themselves 100% of the block reward if they want to. To do that, they must simply refuse to build on any blocks by minority miners, knowing that their own chain has more hash power behind it and will always outgrow the minority chain in the long-run.
It is possible to enforce all kinds of other rule changes that way. For example, the cartel could establish rules for groups of users or transactions that ought to be censored. Minority miners would have to adopt the same censorship rules if they want their blocks to be part of the canonical chain. The orphaning is hence the credible threat that allows the hashpower majority to command hashpower minority as well.
In the case of BCH, the new rule is to donate 12.5% of the block reward to a developer fund. Because old nodes are fully compatible with this change, it has been described as a miner-activated soft-fork (MASF).
While one could think that this change is purely the business of the BCH community, the effects are more far-reaching because BCH shares its mining algorithm, SHA256, with BTC and BSV. We will show why all SHA256 miners are equally subject to this tax if it becomes a reality, and what options users and miners have at their disposal.
The developer tax affects all SHA256 miners
Imagine there’s a pool of SHA256 rewards that consists of the block rewards of all SHA256 mineable coins: Rewards(SHA256) = BlockReward(BTC) + BlockReward(BCH) + BlockReward(BSV).
A pool of SHA256 hashpower chases this pool of rewards:
As others have shown, mining is effectively a dollar bill auction. This has proven to be the case in theory as well as in practice.
If block rewards are worth $1, miners will spend up to $1 in hashpower to earn it (MC=MR). If they would spend less, there would be room for more miners to come online and make an easy profit. If they would spend more, the least profitable miners would go out of business until the marginal miner breaks even.
Miners are free to allocate their hashpower to any chain they want. If BTC appreciates against BCH, more hashpower will migrate toward BTC. In the game of mining, ideology is a cost that miners can’t afford: Whether Bitmain/Jihan Wu of BCH or Coingeek/Calvin Ayre of BSV, they all actively mine the BTC chain because it offers the highest rewards.
Now, what is the impact of this BCH tax? The pool of BlockReward(BCH) shrinks, shrinking Rewards(SHA256) along with it. There are now fewer SHA256 rewards to go around for the same SHA256 hashrate.
As a consequence, some miners have to shut down their machines. Intuition would say, the least profitable BCH miners will now shut off their machines. But what actually happens is that the least profitable SHA256 miners will have to shut off their machines.
This must be true because hash power can move freely between chains. The least profitable BTC miners are not protected from competitive inflows of more profitable hashpower from the BCH and BSV networks.
Before the tax, BCH contributed around 2.6% to the SHA256 reward pool. After lowering this by 12.5%, it will then contribute 2.275% (2.6% * 0.875). As a result, only 2.275% of SHA256 hashrate should be allocated to BCH as well. Therefore, some number of BCH miners who are still cashflow-profitable will reallocate their hashpower to BTC and BSV.
Their entrance will make difficulty on BTC and BSV go up and difficulty on BCH go down. If difficulty increases at equal price + hashing capacity, the ROI of all SHA256 miners goes down. We can thus see the cost of the tax is born by all SHA miners equally, making the least profitable SHA256 miners go out of business, not the least profitable BCH miners.
The role of BCH users
While it may seem that this change happens entirely on the mining layer and doesn’t affect users, let us recall the role of miners according to the protocol.
Users pay miners to establish a stable consensus in the network.
If this change takes effect, only 87.5% of the user funds that were initially dedicated to establishing a stable consensus will be used for that goal. The other 12.5% will go to developers instead.
A developer fund can be a good decision because the maintenance and development of public goods like blockchains are subject to the free-rider problem. But it is highly questionable that this decision should be miners alone to decide. They are making a decision about the users’ money after all. So why not involve the community in the consensus process here?
There’s one caveat to that. Both Bitmain and Bitcoin.com have played a large role in the creation of BCH. They also hold a large percent of the supply. So in practice it would be wrong to see “users” and “miners” as two distinct groups — they overlap in all systems, but especially so in BCH. So this decision has involved users who are also miners, just not users who are not also miners, and that is a problem.
Is this decision final?
Absolutely not. Both (non-mining) users and miners have options at their disposal.
If BCH users want to protest against the change, they can use all the typical tools:
They can vote with their money by selling coins and motivate others to sell their coins along with them, e.g. by making a stink on social media.
they could respond with an UASF (user-activated soft fork: run custom clients that will themselves orphan any block that contribute to the fund).
Finally, they could (threaten to) change the PoW algorithm, thereby “firing” all current miners.
Both of the latter options seem excessively unlikely, given that one of the main properties of the BCH project is that they want decisions to be made by miners.
What about BTC and BSV miners? After all, we have shown how this change cuts into the bottom line of all SHA256 miners equally.
In theory, other SHA miners could allocate hashpower to BCH and orphan any block that allocates block rewards away from miners. This indicates that the “BCH cartel” is not really a cartel after all — it is more like a small local gang inside a much larger country-wide gang.
In practice, it’s not obvious that SHA256 miners will see this change as an attack at all. Let’s look at the logic behind that.
SHA256 miners care about maximizing the value of SHA256 block rewards. That is right. BTC miners are happy if BCH and BSV increase in value, as long as it’s not at the cost of BTC increasing in value. This is true even if they don’t intend to allocate their hashpower to these chains, simply because they passively benefit from the reallocation of others.
Many in the BCH community seem to think this developer fund will improve the project in the medium-term. Maybe they are right? So SHA256 miners have to decide if the short-term revenue loss from the dev fund will grow the pie of SHA256 rewards over a time period that still benefits them (and not future miners).
If they think it doesn’t grow the pie, they can attempt to stop the cartel. This doesn’t come without risk, because an open conflict between miners could lead to an unstable consensus in BCH — defeating the point of why users pay miners in the first place. This could further erode market confidence in BCH and lead to an even smaller SHA256 reward pool.
If they think there is a reasonable chance that it will grow the pie, they might take a wait-and-see approach. We think the latter is more likely at this point.