Now that people seem to be discussing alternatives to the developer fund solution, may I suggest a few rules to follow in the future so that we don't end up in the same, admittedly creative, mess.

1) If it is technically possible, chose to hard-fork instead of soft-fork

If you think there a rule change is valuable, own up to it, convince everyone it's good, and do it as a hard fork. Soft-forks can be unavoidable by others if you want them to be unavoidable, because your blocks will be valid according to the old rules as well. Even if someone like BU tries to manually invalidate the donating blocks, (and correct me here if I am wrong) you just have to hide the fact that you are donating in this block. For example you could use spendable-by-all addresses to receive funds while refusing to accept blocks that spend from these addresses unless they spend to some hidden set of addresses that your fund committee has decided. (SegWit also does something similar with spendable-by-all addresses to confuse old clients to view segwit transactions as valid while not allowing anyone to spend them by orphaning blocks that do so, but again, I may be wrong on this one, if you know more please tell me in the comments) In the end the only way to avoid the soft fork is having some observer looking for blocks to that are orphaning non-donating blocks after an unjustified-by-lag delay, which seems messy and sounds like an even more extreme version of the rolling checkpoints that ABC implemented and which caused quite a backlash.

If others are willing to hard-fork away from your soft-fork and you are willing to allow them to do so, why soft-fork instead of hard-forking in the first place? So don't soft-fork unless you are willing to play this cat and mouse game of trying to hide your soft-forked blocks to make it impossible for others (like BU) to try and hard fork away from you.

2) Do not try to force changes that entail risks that *you* would be unwilling to take

So many people have been calling miners selfish for not wanting to help fund the development of the coin that gives them their income. They were (still are) trying to portray the donation as a wise investement that the stupid selfish miners do not understand.

Lets assume that you are right. That this is indeed a wise donation. Would you be willing to take a loan in your name and pay the miners that currently refuse to invest their 12.5%, all the money that they will lose in the next 6 months by being forced to donate, if in six months they paid you back the money you gave them plus interest at an interest rate equal to the percentile increase of their profits after 6 months compared to the amount they expected to earn if the dev fund did not exist? If your donation plan is such a great investment opportunity, then you should expect to earn money by doing what I suggested above. If it is not a good plan, then you will lose money. Are you willing to take that risk with your own money? If not, then you are just as selfish as those miners are and you shouldn't be trying to force them to take the risk of investing in development just like the miners are not forcing you to do anything.

Put your money where your mouth is or stop trying to guilt trip people, in other words.

3) Suggest soft-forks only when they *clearly* do not violate the spirit of the whitepaper

As I said in my previous article, there are soft-forks that are reasonable because there is no way to implement them as a hard-fork and because they are not going against what Bitcoin has been all this time.

Avalance is one example of a good idea for a soft-fork. It cannot really be hard-forked because the voting process about which transactions should go into the next block happens after the previous block is published and before the new block is mined, and therefore cannot be deduced by looking at the previous block or the history of the blockchain. The Avalanche state is at least partially "outside" the blockchain and thus cannot be enforced by hard-forking new rules. Once more, correct me if I am wrong in the comments. Avalanche also does not go against the spirit of what Bitcoin is supposed to be. The purpose of Avalanche is to help oust miners who break the "first-seen" rule. It is purpose is to give confidence that once you see an unconfirmed transaction in your wallet, there is very little chance of a miner including a different transaction, and the one you see disappearing from your wallet along with the coins it brought. Avalance helps BCH be more like real cash. And it is clear as day that it does so.

The only people that would be pissed by Avalanche that would either be some sort of purists *coughBSVcough* or they people who are interested in helping thieves get away with theft.

Contrast Avalanche with the dev fund plan. The only people who would be pissed by the dev fund plan are people who think that they would rather spend their money ("their" according to the whitepaper mind you) on more mining equipment to further secure the network. Or people who want to fund only one of the developers that the fund would like to fund. Or people who think that such a scheme will become corrupted. Or people who think that this looks like Dash. Or people who think it's better to invest in better wallets or marketing. There are way too many people that will get pissed by a committee forcing them to donate to some cause.

I think that following the above three rules would make the next proposal more acceptable. Can you think of any example where some change violated one of the above but it was still "good"? (whatever "good" means for you)