Author: Rusty Russell 2015-09-13 18:56:01
Published on: 2015-09-13T18:56:01+00:00
The proposed Version bits with timeout and delay is a change to the semantics of Bitcoin blocks' version field, allowing multiple backward-compatible changes (soft forks) to be deployed in parallel. The version field is interpreted as a bit vector with each bit representing an independent change that can be tallied every retarget period. Bit flags are assigned to permit several independent soft forks to be deployed in parallel. A state is associated with each soft fork proposal, which starts at defined and transitions after each retarget period to locked-in, activated, or failed. If the lock-in threshold is met for a proposed change, miners should stop setting the associated bit. After another retarget period, the rules related to the locked-in soft fork will be enforced. If the GetMedianTimePast() of a block following a retarget period is at or past the timeout, miners should cease setting this bit. The mechanism described above is very generic, and variations are possible for future soft forks. This allows support for multi-stage soft forks and conflicting soft forks. The failure timeout allows eventual reuse of bits even if a soft fork was never activated, so it's clear that the new use of the bit refers to a new BIP. It also allows detection of buggy clients and time for warnings and software upgrades for successful soft forks.
Updated on: 2023-06-10T22:21:12.541524+00:00