Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8DCF45AA for ; Thu, 23 Jul 2015 16:23:24 +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 F0AD724D for ; Thu, 23 Jul 2015 16:23:22 +0000 (UTC) Received: from localhost ([::1]:56682 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1ZIJHG-003mtS-4t for bitcoin-dev@lists.linuxfoundation.org; Thu, 23 Jul 2015 12:23:22 -0400 Received: from 119.246.245.241 ([119.246.245.241]) by server47.web-hosting.com (Horde Framework) with HTTP; Thu, 23 Jul 2015 16:23:21 +0000 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" 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 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-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW 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] BIP draft: Hardfork bit 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, 23 Jul 2015 16:23:24 -0000 Please feel free to comment, for technical issues and language BIP: ?? Title: Hardfork bit Author: jl2012 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.