Monday, 3 September 2018

There should be only one feature added in the November fork: BIP135 - Miner voting for consensus-level changes

It's become clear in the recent weeks that the uncertainty of who supports what creates an unbearable amount of back and forth bickering, unnecessary drama, division in the community and most of all distracts to too high of a degree from the main goal: to make Bitcoin (BCH) the best money it can be - the constant bickering about what features to include or not to include overshadows almost completely all the great dev ideas about how to improve BCH (and reasonable criticism of said ideas on an individual basis).

And as Peter Rizun (BU) pointed out, it results in top-down take-it-or-leave-it "bundles" which is a worrying practice. Specific proposals should be evaluated and eventually implemented on a one-by-one basis based on miner support

This is what BIP135 does, it allows miners to vote for individual proposals, defines a threshold for lock-in and a grace period before the change is actually activated (this could be left predictable every 6mo as is now).

I believe this BIP should be implemented across all clients to facilitate this process of activating features a super-majority of miners support, BU and XT already implemented it:

"Bitcoin XT and Bitcoin Unlimited are aligned in the belief that consensus-level changes should be activated only after ratification by the miners. 'Take-it-or-leave-it' bundles, and hard-fork deadlines, are adding unnecessary stress and politicking." - Peter Rizun

ABC's Amaury is so far against this idea, he provided this reasoning for that:

I can answer that one directly. Because nakamoto consensus is better. Let's say what the whitepaper says:

They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them.

As one one can say miner do not vote for proposals. They do vote by extending the chain that contains proposal they like. There must be a chain that exists to do so to begin with.

"Miner voting" as requested doesn't match what satoshi describes as miner voting, and in fact prevents the kind of miner vote described in the whitepaper.

I think this is misguided, expressing miner preference/support in blocks they mine does not detract in any way from Nakamoto Consensus, it still happens just the same way as it always have. With BIP135, it's just more informed decision than the chaos of guessing we have right now so miners and users know what they can expect, severely lowering uncertainty and drama - that is a good thing.

The communication between community/devs/miners before miners make their final decisions with their hash is taking place anyway, it's just scattered over twitter, reddit, mailing-list, slack channels etc. resulting in incomplete and often times faulty information being spread - BIP135 makes this communication that exists anyway more effective and actually representative (and unfakable) of the miner opinion.

I hope /u/deadalnix reconsiders his position, BIP135 is just a communication tool that is solely needed, it does not replace or even affect Nakamoto Consensus in any way.

As a side-note, I believe the Satoshi quote that Amoury referenced does not concern these kinds of disagreements about the future direction of Bitcoin but rather routine operation of the Bitcoin protocol. The WP does not address the event of deliberate forks over disagreements over protocol, otherwise BTC would still be Bitcoin and BCH "just an altcoin" like BTC has claimed - this is clearly not so.

That is why I think we should make the communication of protocol changes more effective and transparent by implementing BIP135 first before anything else as division/chaos/drama or even forking BCH will only hurt the goal we're trying to achieve here

submitted by /u/mushner
[link] [comments]

source https://www.reddit.com/r/btc/comments/9ckw30/there_should_be_only_one_feature_added_in_the/

No comments:

Post a Comment