Author: Eric Lombrozo 2015-09-30 04:46:25
Published on: 2015-09-30T04:46:25+00:00
The Version Bits mechanism is not a 'voting' system, but rather a deployment mechanism for fairly uncontroversial changes that aims to measure adoption of such changes before activating them. If a particular BIP stands little chance of hitting the 95% mark relatively quickly, it's probably better not to deploy it. The current controversies around features like CLTV, CSV, etc. do not seem to revolve around the features themselves - there seems to be near-unanimous agreement that these features are good. Instead, the controversies are much more likely to be around deployment strategies. This mechanism is most useful for adding fairly uncontroversial features provided as default settings in product releases. Miners will most likely continue to choose to cooperate in the interest of the health of the network (and will use recommended default settings) as long as the BIPs are relatively uncontroversial. Either a BIP is relatively quickly adopted with overwhelming support or else perhaps it is best to wait until it has sufficient support before attempting deployment or perhaps not deploy it at all and ultimately we want these transitions to run as smoothly as possible. To sum up, Version Bits is not a mechanism for vetting proposed changes and building consensus (that should take place BEFORE assigning bits).While getting some form of explicit acknowledgment from miners that a new rule is in effect would be ideal, the truth of the matter is that there still lacks a means to determine whether or not miners are actually enforcing these rules unless someone happens to mine a block that breaks the new rule. A middle ground could be required where miners set the bit for a period of time after rule enforcing begins, but don't enforce the bit, just enforce validity of the block under new rules. Thus a thin client could treat these blocks with increased skepticism.
Updated on: 2023-06-10T23:31:00.027196+00:00