dtr-org
Do we want to keep Bip9-style deployments?
Bitcoin introduced a generic mechanism for deploying soft forks usig BIP9: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
It has been used to deploy CSV (Check Sequence Verify) and Segwit. In unit-e we're starting with these things off by default, so there is no deployment of a softfork, there is just the unit-e chain as it is.
In the future though bitcoin might introduce other soft forks and we might want to introduce soft forks, which might be communicated through bip9.
The support for a feature is determined by the proposers (which substitute the miners from bitcoin). Concerns have been raised that this leaves the validators out of the picture.
Validators could be able to cast their preferences by voting the blocks that show their same preferences... although this comes at the risk of voting the "wrong" branch and losing potential income.
Could be interesting to look for less "dangerous" mechanisms to explicitly state their preferences.
Validators could always also act as proposers to state their preferences, couldn't they? Or should they be differently weighted?
Validators could always also act as proposers to state their preferences, couldn't they?
Validators cannot stake their deposits. They'll have to have separate funds for staking.
Bitcoin removed the bip9 functional tests in https://github.com/bitcoin/bitcoin/pull/11818, because other tests check it (csv activation, segwit activation).
Should we decide to go on with bip9 style deployments we should maybe have a test that checks that functionality generically, i.e. not with a real deployment but with injected chainparams etc. Also the functionality needs to be patched into staking::BlockBuilder first.
Bitcoin: Bury Bip9 deployments
https://github.com/bitcoin/bitcoin/pull/16060
Bitcoin: Bury Bip9 deployments
I think the title is a bit misleading, as what they did is they hardcoded the segwit activation height, and not removed the deployment mechanism.
True, but related nevertheless. They do not get rid of BIP9 in the first place (though I wonder whether other bip9 deployments will follow), but of some bip9 deployments. I think for CSV we should do at least that too (I believe the CSV deployment is still in unit-e).
Of course we would get it eventually when merging with 0.19 probably...