[bitcoin-dev] BIP draft: Hardfork bit
jl2012 at xbt.hk
jl2012 at xbt.hk
Thu Jul 23 16:23:21 UTC 2015
Please feel free to comment, for technical issues and language
Title: Hardfork bit
Author: jl2012 <jl2012 at xbt.hk>
Type: Standard Track
This document specifies a proposed change to the semantics of the most
significant bit of the “version” field in Bitcoin block headers, as a
mechanism to indicate a hardfork is deployed. It alleviates certain
risks related to a hardfork by introducing an explicit “point of no
return” in the blockchain. This is a general mechanism which should be
employed by any planned hardfork in the future.
Hardforks in Bitcoin are usually considered as difficult and risky, because:
1) Hardforks require not only support of miners, but also, most
importantly, supermajority support of the Bitcoin economy. As a
result, softfork deployment mechanisms described in BIP 34 or BIP XX
“Version bits” (https://gist.github.com/sipa/bf69659f43e763540550) are
not enough for introducing hardforks safely.
2) Full nodes and SPV nodes following original consensus rules may not
be aware of the deployment of a hardfork. They may stick to an
economic-minority fork and unknowingly accept devalued legacy tokens.
3) In the case which the original consensus rules are also valid under
the new consensus rules, users following the new chain may
unexpectedly reorg back to the original chain if it grows faster than
the new one. People may find their confirmed transactions becoming
unconfirmed and lose money.
The first issue involves soliciting support for a hardfork proposal,
which is more a political topic than a technical one. This proposal
aims at alleviating the risks related to the second and third issues.
It should be employed by any planned hardfork in the future.
See BIP YY “Motivation and deployment of consensus rules changes”
Hardfork bit: The most significant bit in nVersion is defined as the
hardfork bit. Currently, blocks with this header bit setting to 1 are
invalid, since BIP34 interprets nVersion as a signed number and
requires it to be >=2 (with BIP66, >=3). Among the 640 bits in the
block header, this is the only one which is fixed and serves no
purpose, and therefore the best way to indicate the deployment of a
Flag block: Any planned hardfork must have one and only one flag block
which is the “point of no return”. To ensure monotonicity, flag block
should be determined by block height, or as the first block with
GetMedianTimePast() greater than a threshold. Other mechanisms could
be difficult for SPV nodes to follow. The height/time threshold could
be a predetermined value or relative to other events (e.g. 1000 blocks
/ 10 days after 75% of miner support). The exact mechanism is out of
the scope of this BIP. No matter what mechanism is used, the threshold
is consensus critical. It must be publicly verifiable with only
blockchain data and the programme source code, and preferably
Flag block is constructed in a way that nodes with the original
consensus rules must reject. On the other hand, nodes with the new
consensus rules must reject a block if it is not a flag block while it
is supposed to be. To achieve these goals, the flag block must 1) have
the hardfork bit setting to 1, 2) include a short predetermined unique
description of the hardfork anywhere in its coinbase, and 3) follow
any other rules required by the hardfork. If these conditions are not
fully satisfied, upgraded nodes shall reject the block.
The hardfork bit must be turned off in the decedents of the flag
block, until the deployment of the next hardfork. The requirement of
coinbase message is also limited to the flag block. In the rare case
that multiple hardforks share the same flag block, the coinbase shall
include all relevant messages and the order/position of the messages
shall not be consensus critical.
Although a hardfork is officially deployed after the flag block, the
exact behavioural change is out of the scope of this BIP. For example,
a hardfork may not be fully active until certain time after the flag
Automatic warning system: When a flag block is found on the network,
full nodes and SPV nodes should look into its coinbase. They should
alert their users and/or stop accepting incoming transactions if it is
an unknown hardfork. It should be noted that the warning system could
become a DoS vector if the attacker is willing to give up the block
reward. Therefore, the warning may be issued only if a few blocks are
built on top of the flag block in a reasonable time frame. This will
in turn increase the risk in case of a real planned hardfork so it is
up to the wallet programmers to decide the optimal strategy. Human
warning system (e.g. the emergency alert system in Bitcoin Core) could
fill the gap.
As a mechanism to indicate hardfork deployment, this BIP breaks
backward compatibility intentionally. However, without further changes
in the block header format, full nodes and SPV nodes could still
verify the PoW of a flag block and its descendants.
This proposal is also compatible with the BIP XX “Version bits”. The
version bits mechanism could be employed to measure miner support
towards a hardfork proposal, and to determine the height or time
threshold of the flag block. Also, miners of the flag block may still
cast votes for other concurrent softfork or hardfork proposals as
After the flag block is generated, a miner may support either fork but
not both. It is not possible for miners in one fork to attack or
overtake the other fork because the forks are mutually exclusive.
More information about the bitcoin-dev