Create a gist now

Instantly share code, notes, and snippets.

Version bits extension with user defined activation

  BIP: ?
  Title: Version bits extension with user defined activation
  Author: Shaolin Fry <>
  Comments-Summary: No comments yet.
  Status: Draft
  Type: Informational
  Created: 2017-02-01
  License: BSD-3-Clause

Table of Contents


This document specifies an extension to BIP9 that introduces an additional activation parameter to deploy backward-compatible changes (further called "soft forks") to be activated by a deadline.


BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and is also subject to veto by a small minority of non-signalling hashrate.

This specification provides an way for full nodes to coordinate syncronized activation based on a median past time using the BIP9 state machine. Hashrate may optionally trigger activation before the user defined activation sequence triggers.


This specification adds a new per-chain deployment parameter to the existing BIP9 specification as follows:

  1. The activationtime specifies a minimum median time past of a block at which the deployment should transition to the locked-in state.

Selection guidelines

The following guidelines are suggested for selecting these parameters for a soft fork:

  1. activationtime should be set to some date in the future and must be less than the BIP9 timeout. It is recommended to have an activation time of 1 year minus 1 second (31535999 seconds).

State transitions

The state transition workflow is exactly the same as in BIP9 with an additional rule: During the STARTED state if the median time past is greater than or equal to the activationtime then the state will transition to LOCKED_IN on the next retarget after activationtime.

        case STARTED:
            // support for activationtime transition
            if (GetMedianTimePast(block.parent) >= activationtime) {
                return LOCKED_IN;
            // BIP9 specification follows
            if (GetMedianTimePast(block.parent) >= timeout) {
                return FAILED;
            int count = 0;
            walk = block;
            for (i = 0; i < 2016; i++) {
                walk = walk.parent;
                if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) {
            if (count >= threshold) {
                return LOCKED_IN;
            return STARTED;

Reference implementation


A living list of deployment proposals can be found here.


This document is placed in the public domain.


Looks nice! Would be happy to get features deployed like this... Excited to hear other opinions!

gasteve commented Mar 15, 2017

Would it make sense for nodes to stop accepting or relaying transactions that violate the soft fork rules even before the activationtime? Before the activationtime, a node would only accept such transactions if they appear in a block. In other words, transactions not satisfying the new rules would be considered non standard long before the activationtime. By trying to inject transactions that deliberately break the new rules, you might be able to ascertain the level of support for the soft fork on the p2p network.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment