BCH plans to divert 12.5% of its new block rewards (specifically, coinbase) to funding its developers. Further, the miners will orphan blocks that do not comply with this plan.
My quick take on this.
My quick take on this.
From a principled perspective, it's highly unusual to enforce compliance with an unpopular proposal through a soft fork.
But it's misleading to compare this proposal to the way BTC rammed Segwit via a soft-fork. Segwit was a protocol change visible to the public. This policy redirects miners' income, it does not have any protocol consequences for end users (modulo the issues below).
From a financial perspective, there's something clever going on: the costs are borne mostly by BTC. This cost-shifting will continue to work as long as BTC is hashrate dominant.
From a security perspective, The trade off here is slightly lower hash rate for BCH, in exchange for developer funding. This is sensible: empirically, more attacks have been due to underfunded devs than to malicious hashrate.
From a practical perspective, it's much better to see devs funded and incentive aligned, than to watch them make protocol changes to divert fees and income to layers they control. And much better to fund them than to watch them use sock puppets to steer their community astray.
But there are three unpalatable aspects to this proposal.
First, it's coercive on miners. Practically, the orphaning is a way to force Calvin Ayre to pay. There isn't a single person who cares about Calvin, probably not even his mother, assuming she's alive and has seen his pictures from the Caribbean.
The orphaning will not practically impact any other miners' decisions about which chain to mine on. They will follow their income, and we already discussed how the plan cleverly shifts costs to BTC as long as there's a price/hashrate difference between the tokens.
The second, and substantive, problem is the way the proposal came out of nowhere. Springing such a proposal, with orphaning built in, on a community with no prior discussion was terrible PR and community management.
And this alone is grounds for pressing the pause button.
It's very clear that this is a proposal in good faith, by people who care about BCH. It's not a bad proposal.
But the way in which it was sprung up on the community without discussion sets a bad precedent and bad optics
It's very clear that this is a proposal in good faith, by people who care about BCH. It's not a bad proposal.
But the way in which it was sprung up on the community without discussion sets a bad precedent and bad optics
The principle of "no debate" is a terrible one. It is antithetical to the crypto ethos.
Third and final problem is that there are many underspecified aspects to the proposal. Specifically, who will manage the collected funds and how will they be distributed? This is exactly when some much needed community discussion would have been useful.
So, overall, what to make of this:
It's a clever proposal, with good intent. The 6 month sunset clause makes it even better.
But it needs to be debated and made concrete. Any attempt to foreshorten discussion and debate is a terrible idea and sets a bad precedent.
It's a clever proposal, with good intent. The 6 month sunset clause makes it even better.
But it needs to be debated and made concrete. Any attempt to foreshorten discussion and debate is a terrible idea and sets a bad precedent.
Clarification: "attacks due to underfunded devs" really means "attacks that could have been prevented by better funded dev teams." Not attacks by devs themselves, though we've seen suspected insider attacks on certain coins as well.
And here's some very insightful discussion on why this soft fork will need to adopted and enforced by clients.
To clarify the historical record: this idea came up a few years ago, to fund development work on BCH. It enjoyed support from the miners behind the scenes, but seemed to die during the community discussion stage. This week's resurgence of the fund was sudden and unexpected.
