path: root/df/142ce938bb4a4f025723a7f0133db8011a74c3

Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3BF9EF72
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <jl2012@xbt.hk>) 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 <jl2012@xbt.hk>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <f225318eddd0aadc71861f988f2f4674@xbt.hk>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
<html><body style=3D'font-size: 10pt; font-family: Verdana,Geneva,sans-seri=
f'>
<pre>https://github.com/bitcoin/bips/pull/317
</pre>
<h2>Abstract</h2>
<p>This document specifies a proposed change to the semantics of the sign b=
it of the &ldquo;version&rdquo; 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 &ldquo;point of no return&rdquo; =
in the blockchain. This is a general mechanism which should be employed by =
any planned hardfork in the future.</p>
<h2><a id=3D"user-content-motivation" class=3D"anchor" href=3D"https://gith=
ub.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#motivation"></a><=
a name=3D"user-content-Motivation"></a>Motivation</h2>
<p>Hardforks in Bitcoin are usually considered as difficult and risky, beca=
use:</p>
<p>&nbsp;</p>
<ol>
<li>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&nbsp;<a href=3D"https://github.com/jl2012/bi=
ps/blob/hardforkbit/bip-0034.mediawiki">BIP 34</a>&nbsp;or&nbsp;<a href=3D"=
https://github.com/jl2012/bips/blob/hardforkbit/bip-0009.mediawiki">BIP 9</=
a>&nbsp;are not enough for introducing hardforks safely.</li>
<li>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.</li>
<li>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.</li>
</ol>
<pre><span>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.</span></pre>
<p>&nbsp;</p>
<h2><a id=3D"user-content-definitions" class=3D"anchor" href=3D"https://git=
hub.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#definitions"></a=
><a name=3D"user-content-Definitions"></a>Definitions</h2>
<p>See&nbsp;<a href=3D"https://github.com/jl2012/bips/blob/hardforkbit/bip-=
0099.mediawiki">BIP99</a></p>
<h2><a id=3D"user-content-specification" class=3D"anchor" href=3D"https://g=
ithub.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#specification"=
></a><a name=3D"user-content-Specification"></a>Specification</h2>
<p><strong>Hardfork bit</strong>&nbsp;The sign bit in nVersion is defined a=
s the hardfork bit. Currently, blocks with this header bit setting to 1 are=
 invalid, since&nbsp;<a href=3D"https://github.com/jl2012/bips/blob/hardfor=
kbit/bip-0065.mediawiki">BIP65</a>&nbsp;interprets nVersion as a signed num=
ber and requires it to be &ge; 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.</p>
<p><strong>Flag block</strong>&nbsp;Any planned hardfork must have one and =
only one flag block which is the &ldquo;point of no return&rdquo;. 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).</p>
<p>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</p>
<ol>
<li>have the hardfork bit setting to 1, and</li>
<li>follow any other rules required by the hardfork</li>
</ol>
<pre><span>If these conditions are not fully satisfied, upgraded nodes shal=
l reject the block.</span></pre>
<p>&nbsp;</p>
<p>The hardfork bit must be turned off in the successors of the flag block,=
 until the deployment of the next hardfork.</p>
<p>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</p>
<p><strong>Concurrent hardfork proposals</strong>&nbsp;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.</p>
<p>In the case that the version bits mechanism is used in deploying a hardf=
ork, height of the flag block should take a value of<code>32N + B</code>, w=
here&nbsp;<code>N</code>&nbsp;is a positive integer and&nbsp;<code>B</code>=
&nbsp;is the position of&nbsp;<code>bit B</code>&nbsp;defined in&nbsp;<a hr=
ef=3D"https://github.com/jl2012/bips/blob/hardforkbit/bip-0009.mediawiki#Me=
chanism">BIP9</a>. This guarantees that no clash may happen with another ha=
rdfork proposal using BIP9.</p>
<p><strong>Uncontroversial subtle hardforks</strong>&nbsp;Hardforks may som=
etimes be totally uncontroversial and make barely noticeable change (<a hre=
f=3D"https://github.com/jl2012/bips/blob/hardforkbit/bip-0050.mediawiki">BI=
P50</a>, 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.</p>
<p><strong>Automatic warning system</strong>&nbsp;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.</p>
<h2><a id=3D"user-content-compatibility" class=3D"anchor" href=3D"https://g=
ithub.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#compatibility"=
></a><a name=3D"user-content-Compatibility"></a>Compatibility</h2>
<p>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.</p>
<p><strong>Hardfork involving change in block header format</strong>&nbsp;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</p>
<p><strong>Version bits</strong>&nbsp;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.</p>
<p><strong>Point of no return</strong>&nbsp;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.</p>
<h2><a id=3D"user-content-copyright" class=3D"anchor" href=3D"https://githu=
b.com/jl2012/bips/blob/hardforkbit/hardforkbit.mediawiki#copyright"></a><a =
name=3D"user-content-Copyright"></a>Copyright</h2>
<p>This document is placed in the public domain.</p>
</body></html>

--=_26b5fbc8b08433c5dd22a61e9d78421f--