Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3BF9EF72 for ; Thu, 4 Feb 2016 17:14:55 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 33F511AD for ; Thu, 4 Feb 2016 17:14:51 +0000 (UTC) Received: from [::1] (port=33314 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpa (Exim 4.86) (envelope-from ) id 1aRNUY-0042Iw-1J for bitcoin-dev@lists.linuxfoundation.org; Thu, 04 Feb 2016 12:14:50 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_26b5fbc8b08433c5dd22a61e9d78421f" Date: Thu, 04 Feb 2016 12:14:49 -0500 From: jl2012 To: bitcoin-dev@lists.linuxfoundation.org Message-ID: X-Sender: jl2012@xbt.hk User-Agent: Roundcube Webmail/1.0.6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server47.web-hosting.com X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - xbt.hk X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id: jl2012@xbt.hk X-Authenticated-Sender: server47.web-hosting.com: jl2012@xbt.hk X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Hardfork bit BIP X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 17:14:55 -0000 --=_26b5fbc8b08433c5dd22a61e9d78421f Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 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 --=_26b5fbc8b08433c5dd22a61e9d78421f Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 
https://github.com/bitcoin/bips/pull/317

Abstract

This document specifies a proposed change to the semantics of the sign b= it of the “version” field in Bitcoin block headers, as a mechan= ism 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.

<= a name=3D"user-content-Motivation">Motivation

Hardforks in Bitcoin are usually considered as difficult and risky, beca= use:

 

  1. Hardforks require not only support of miners, but also, most importantl= y, supermajority support of the Bitcoin economy. As a result, softfork depl= oyment mechanisms described in BIP 34 or BIP 9 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-minori= ty 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 propo=
sal, which is more a political topic than a technical one. This proposal ai=
ms at alleviating the risks related to the second and third issues. It shou=
ld be employed by any planned hardfork in the future.

 

Definitions

See BIP99

Specification

Hardfork bit The sign bit in nVersion is defined a= s the hardfork bit. Currently, blocks with this header bit setting to 1 are= invalid, since BIP65 interprets nVersion as a signed num= ber and requires it to be ≥ 4. Among the 640 bits in the block header, t= his 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 ensur= e monotonicity, flag block should be determined by block height, or as the = first block with GetMedianTimePast() greater than a threshold. Other mechan= isms 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 bloc= ks / 100 days after 95% of miner support). The exact mechanism is out of th= e scope of this BIP. No matter what mechanism is used, the threshold is con= sensus critical. It must be publicly verifiable with only blockchain data, = and preferably SPV-friendly (i.e. verifiable with block headers only, witho= ut downloading any transaction).

Flag block is constructed in a way that nodes with the original consensu= s 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. T= o achieve these goals, the flag block must

  1. have the hardfork bit setting to 1, and
  2. follow any other rules required by the hardfork
If these conditions are not fully satisfied, upgraded nodes shal=
l 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= =2E

Concurrent hardfork proposals To avoid confusion a= nd unexpected behaviour, a flag block should normally signify the deploymen= t of only one hardfork. Therefore, a hardfork proposal has to make sure tha= t its flag block threshold is not clashing with other ongoing hardfork prop= osals.

In the case that the version bits mechanism is used in deploying a hardf= ork, height of the flag block should take a value of32N + B, w= here N is a positive integer and B=  is the position of bit B defined in BIP9. This guarantees that no clash may happen with another ha= rdfork proposal using BIP9.

Uncontroversial subtle hardforks Hardforks may som= etimes be totally uncontroversial and make barely noticeable change (BI= P50, for example). In such cases, the use of hardfork bit may not be ne= eded 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 a= lert their users and/or stop accepting/sending transactions. It should be n= oted 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 ma= y be issued only if a few blocks are built on top of the flag block in a re= asonable 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 optima= l strategy. Human warning system (e.g. the emergency alert system in Bitcoi= n 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 Proof-of-Wo= rk of a flag block and its successors.

Hardfork involving change in block header format I= f 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 ma= ke sure existing nodes realize that an unknown hardfork has been deployed= =2E

Version bits This proposal is also compatible with= the BIP9. The version bits mechanism could be employed to measure miner su= pport towards a hardfork proposal, and to determine the height or time thre= shold of the flag block. Also, miners of the flag block may still cast vote= s for other concurrent softfork or hardfork proposals as normal.

Point of no return After the flag block is generat= ed, 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.

Copyright

This document is placed in the public domain.

--=_26b5fbc8b08433c5dd22a61e9d78421f--