Date: Thu, 23 Jul 2015 16:23:21 +0000
Message-ID: <20150723162321.Horde.bphh__8AhyXa_m-YAYpiyw1@server47.web-hosting.com>
From: jl2012@xbt.hk
To: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
User-Agent: Internet Messaging Program (IMP) H5 (6.1.4)
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Subject: [bitcoin-dev] BIP draft: Hardfork bit
Precedence: list

Please feel free to comment, for technical issues and language

BIP: ??
Title: Hardfork bit
Author: jl2012 <jl2012@xbt.hk>
Status: Draft
Type: Standard Track
Created: 2015-07-23

Abstract

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.

Motivation

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.

Definitions

See BIP YY “Motivation and deployment of consensus rules changes”
https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org

Specification

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  
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. 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  
SPV-friendly.

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  
block.

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.

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 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  
normal.

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.