Join 53,901 users and earn money for participation

3 rules for changing the rules

21 344 boost
Avatar for ZeusOnPills
Written by   36
1 year ago

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.

Sponsors of ZeusOnPills
empty
empty
empty

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)

14
$ 201.45
$ 200.00 from @MarcDeMesel
$ 1.00 from @btcfork
$ 0.25 from @Read.Cash
+ 2
Avatar for ZeusOnPills
Written by   36
1 year ago
Enjoyed this article?  Earn Bitcoin Cash by sharing it! Explain
...and you will also help the author collect more tips.

Comments

👉👉 great article my dear That would exactly measure the majority of the voting holders. That's not necessarily the same as the overall majority, nor is there a reason to believe that there is no correlation between the tendency to vote, and the tendency to accept various plans. If you get 100% in support then yeah, you can probably bet that the majority is in favor, but if you get a 60% you really have no idea if the majority is in favor. You have to take the voting cost into account and there is always a voting cost which in this case is actually big: I assume that to vote you need to have the voting coins in a hot wallet so that you can sign something with their private keys, but big savers don't keep their coins in hot wallets, they keep them in cold storage, so they'd have to waste time every time they want to vote to move the coins, which also involves a risk that they may be unwilling to take.

$ 0.00
3 months ago

Great article .I follow you

$ 0.00
3 months ago

Thanks for this guide ..i finally understand the difference of the two.

$ 0.00
3 months ago

I love your post realy thank's

$ 0.00
3 months ago

I seem to be lost here please, what does this article really refer to?

$ 0.00
3 months ago

I wrote this back when ABC had first proposed the IFP. It's relevant again now that the date when ABC will be splitting off BCH is coming closer.

$ 0.00
3 months ago

good guide, hopefully some key players take note

$ 0.00
1 year ago

Thank you MarcDeMesel for the compliment and the crazy tips. :-) I expect they will take notice, not necessarily from my post but because at least there is a lot of discussion going on in /r/btc about this, so I doubt any arguments are buried like they would be in /r/bitcoin for example.

$ 0.00
1 year ago

welcome, your article being discussed there, if yes, link?

$ 0.00
1 year ago
$ 0.00
1 year ago

2 rules are enough:

Measure if the majority of SHA256 miners agree.

Measure if the majority of BCH holders agree.

$ 0.00
1 year ago

And risk losing the minority? Not a great idea in general, although it depends on how certain you are that the plan is necessary. If you think that the coin will not survive unless you implement the plan, then go ahead even if you have support just from 1/5th of the miners and holders. You can still hard fork and take that 1/5th with you.

Also, how do you measure if the majority of holders agree? You can't measure that...

$ 0.00
1 year ago

Of course you can exactly measure that. There was even a platform for coin voting, now sadly defunct. We need a new one.

$ 0.00
1 year ago

That would exactly measure the majority of the voting holders. That's not necessarily the same as the overall majority, nor is there a reason to believe that there is no correlation between the tendency to vote, and the tendency to accept various plans. If you get 100% in support then yeah, you can probably bet that the majority is in favor, but if you get a 60% you really have no idea if the majority is in favor. You have to take the voting cost into account and there is always a voting cost which in this case is actually big: I assume that to vote you need to have the voting coins in a hot wallet so that you can sign something with their private keys, but big savers don't keep their coins in hot wallets, they keep them in cold storage, so they'd have to waste time every time they want to vote to move the coins, which also involves a risk that they may be unwilling to take.

For example if you asked people to vote on a plan that would tax coins that have not recently moved, your coin voting system would probably overestimate the number of people in support of the plan. Or do you expect Satoshi to wake up and vote with his coins? And when you try to implement the plan, you'll then wake up all the big hodlers who will sell everything to move to another coin.

$ 0.00
1 year ago

There should be an option to delegate of course. Same as it is on BMP.

$ 0.00
1 year ago

How do you delegate without moving the private key of your coins from your cold wallet? Delegation would make more people "vote" but it doesn't fully solve the issue that you are not sampling the holders, but the voters and those who bother to delegate.

$ 0.00
1 year ago

What is cold wallet? Paper or trezor?

$ 0.00
1 year ago

Any way of storing your coins without having the private key touching a device that is connected to a network. Paper and trezor do count as cold storage unless trezor has bugs.

$ 0.00
1 year ago

it is easy to vote or delegate using trezor. Not with paper.

$ 0.00
1 year ago

That would also help with the vote, although not everyone trusts trezor and some prefer to use paper wallets.

$ 0.00
1 year ago