1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
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 8DCF45AA
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <jl2012@xbt.hk>) 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"
<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 <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, 23 Jul 2015 16:23:24 -0000
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.
|
