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
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 106F1118B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Feb 2016 18:29:29 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 85D992F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Feb 2016 18:29:28 +0000 (UTC)
Received: from ishibashi.localnet (unknown
[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 7459038A99F7;
Thu, 4 Feb 2016 18:29:14 +0000 (UTC)
X-Hashcash: 1:25:160204:bitcoin-dev@lists.linuxfoundation.org::fRI98Hzs9cqsL3vn:=dc5
X-Hashcash: 1:25:160204:jl2012@xbt.hk::CMobuJYVDpTy1enu:ajFOL
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
jl2012 <jl2012@xbt.hk>
Date: Thu, 4 Feb 2016 18:29:11 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.13-gentoo; KDE/4.14.8; x86_64; ; )
References: <f225318eddd0aadc71861f988f2f4674@xbt.hk>
In-Reply-To: <f225318eddd0aadc71861f988f2f4674@xbt.hk>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201602041829.13459.luke@dashjr.org>
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RCVD_IN_SBL,
RP_MATCHES_RCVD autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [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 18:29:29 -0000
On Thursday, February 04, 2016 5:14:49 PM jl2012 via bitcoin-dev wrote:
> 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.
Disagree with treating the "version" field as a number, in BIP 9 or this BIP
which reinterpret it as a bit vector.
> Among the 640 bits in the block header, this is the only one which is
> fixed and serves no purpose, ...
Minor nit (not relevant to actual proposal): This is not true. There are over
32 other bits (part of the "previous-block" field) which also serve no
purpose.
> 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).
With the current codebase, it is significantly easier to trigger on the block
timestamp rather than its height or median-time-past. Using either of the
latter would require refactoring of CBlockIndex. As a hard-fork, even if the
rules are ineffective for a few blocks following the forking point, using the
hardfork version bit in this BIP would still ensure a clean break. While I
agree that median-time-past and height are superior methods that ought to be
used for hardforks, an emergency hardfork may need to avoid them for
simplicity, and I don't think they need to be mandated as such in this BIP.
> Although a hardfork is officially deployed when flag block is generated, ...
I would avoid implying the hardfork can be "officially deployed" without
actual adoption.
> 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.
This seems vulnerable to DoS attacks by rejected hardforks.
> 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.
Rather not imply BIP 9 should be used for hardforks, or that miners have any
voice in the decision. This is already a serious misconception.
> 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.
This is not actually desirable, and would suggest a possible reason *not* to
comply with this BIP. A legitimate hardfork would never have two continued
sets of rules for miners to choose from.
Luke
|
