Re: [bitcoin-dev] BIP proposal: Generalized version bits voting (bip-genvbvoting)

[Sancho Panza <sanch0panza@protonmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3148 bytes --]

> BIP 9 doesn't limit itself, merely acknowledges the *inherent* nature of it
> not being applicable to hardforks. BIP 9 provides a mechanism for having
> miners coordinate softforks because they can make the upgrade process smoother
> this way. But the same is not true of hardforks: miners are essentially
> irrelevant to them, and cannot make the process any smoother.

I accept that BIP9 is inherently concerned only with softforks, as it is explicit about this in every instance.
However, I see no fundamental distinction between the 'royal privilege' assigned to miners w.r.t. softfork activation and the role they would play in properly coordinated hardforks.
In either case, the majority of miners would hopefully want to wait for the right conditions to create the fork block, whether that block be the first one to contain SegWit transactions or the first one to be larger than 1MB (to give two current examples).
The advance coordination with the rest of the users in the system seems important in either case.

This is a big motivator for this BIP: the versionbits can be used as a coordination mechanism for hardforks just as much as softforks.
With the added flexibility offered by this BIP, miners could use these bits to make the process smoother for softforks as well as hardforks.

For example (this is an idea I did not write in the initial BIP draft), the period for which a fork on a particular bit remains LOCKED_IN could be made customizable too, instead of one single retargeting period.
This would allow fork implementors to specify a longer adaptation period suitable to the impacts of the feature they are planning to deploy.

> Therefore, BIP 9 and any miner signalling in general is not very useful
> for deploying these.

I think BIP9 is a very useful tool that allows a decent determination of how much of the hashing power supports a particular fork proposal.

My view is that both soft and hard forks without support from the majority of miners place themselves at high risk.
In general every soft fork can result in a counter hardfork by those who are not aligned with its objectives, just like every hardfork can result in a counter softfork for the same reason by those opposed to it.

It seems to me that this somewhat balances out the (dis)advantages and effectively puts these fork types on a similar footing.
This is a rationale for generalizing the signaling mechanism introduced by BIP9.

In practice, developers will still need to choose whether their feature is best deployed by softfork or hardfork. This proposal affords them that choice, and does not propose any arbitrary conditions (e.g. a predefined split of the versionbits range into particular categories of forks or activation levels).

> Softforks are not required to use BIP 9, and even if they do, they are not
> required to use the recommended thresholds.

This is true, but introducing more flexibility into the signaling framework of BIP9 means it will be more useful for further developments - including a potential hardfork which was on the Core roadmap to accomodate certain wishlist items that cannot easily be addressed by softforks.

[-- Attachment #2: Type: text/html, Size: 3652 bytes --]