[bitcoin-dev] Hardfork bit BIP

jl2012 jl2012 at xbt.hk
Thu Feb 4 17:14:49 UTC 2016


 

https://github.com/bitcoin/bips/pull/317

ABSTRACT

This document specifies a proposed change to the semantics of the sign
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. 

 [1]MOTIVATION

Hardforks in Bitcoin are usually considered as difficult and risky,
because: 

 	* 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 [2] or BIP 9 [3] are
not enough for introducing hardforks safely.
 	* 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.
 	* 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.

 [4]DEFINITIONS

See BIP99 [5] 

 [6]SPECIFICATION

HARDFORK BIT The sign bit in nVersion is defined as the hardfork bit.
Currently, blocks with this header bit setting to 1 are invalid, since
BIP65 [7] interprets nVersion as a signed number and requires it to be ≥
4. 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 hardfork. 

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. 10000 blocks / 100
days after 95% 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 preferably SPV-friendly (i.e. verifiable with block headers
only, without downloading any transaction). 

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 

 	* have the hardfork bit setting to 1, and
 	* 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 successors of the flag block,
until the deployment of the next hardfork. 

Although a hardfork is officially deployed when flag block is generated,
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 block. 

CONCURRENT HARDFORK PROPOSALS To avoid confusion and unexpected
behaviour, a flag block should normally signify the deployment of only
one hardfork. Therefore, a hardfork proposal has to make sure that its
flag block threshold is not clashing with other ongoing hardfork
proposals. 

In the case that the version bits mechanism is used in deploying a
hardfork, height of the flag block should take a value of32N + B, where
N is a positive integer and B is the position of bit B defined in BIP9
[8]. This guarantees that no clash may happen with another hardfork
proposal using BIP9. 

UNCONTROVERSIAL SUBTLE HARDFORKS Hardforks may sometimes be totally
uncontroversial and make barely noticeable change (BIP50 [9], for
example). In such cases, the use of hardfork bit may not be needed as it
may cause unnecessary disruption. The risk and benefit should be
evaluated case-by-case. 

AUTOMATIC WARNING SYSTEM When a flag block for an unknown hardfork is
found on the network, full nodes and SPV nodes should alert their users
and/or stop accepting/sending transactions. It should be noted that the
warning system could become a denial-of-service 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. 

 [10]COMPATIBILITY

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
Proof-of-Work of a flag block and its successors. 

HARDFORK INVOLVING CHANGE IN BLOCK HEADER FORMAT If a hardfork involves
a new block header format, the original format should still be used for
the flag block and a reasonable period afterwards, to make sure existing
nodes realize that an unknown hardfork has been deployed. 

VERSION BITS This proposal is also compatible with the BIP9. 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 normal. 

POINT OF NO RETURN After the flag block is generated, a miner may
support either the original rules or the new rules, but not both. It is
not possible for miners in one fork to attack or overtake the other fork
without giving up the mining reward of their preferred fork. 

 [11]COPYRIGHT

This document is placed in the public domain. 

Links:
------
[1]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#motivation
[2] https://github.com/jl2012/bips/blob/hardforkbit/bip-0034.mediawiki
[3] https://github.com/jl2012/bips/blob/hardforkbit/bip-0009.mediawiki
[4]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#definitions
[5] https://github.com/jl2012/bips/blob/hardforkbit/bip-0099.mediawiki
[6]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#specification
[7] https://github.com/jl2012/bips/blob/hardforkbit/bip-0065.mediawiki
[8]
https://github.com/jl2012/bips/blob/hardforkbit/bip-0009.mediawiki#Mechanism
[9] https://github.com/jl2012/bips/blob/hardforkbit/bip-0050.mediawiki
[10]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#compatibility
[11]
https://github.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#copyright
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160204/d4208f4f/attachment.html>


More information about the bitcoin-dev mailing list