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
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 50C01A58
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Dec 2016 06:35:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com
[209.85.217.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 869D215E
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Dec 2016 06:35:38 +0000 (UTC)
Received: by mail-ua0-f181.google.com with SMTP id 20so272403811uak.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 01 Dec 2016 22:35:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-transfer-encoding;
bh=F8/ir1QA7Q8+e2rP5NV8qe86UW306I+zEQ1beMDq1iM=;
b=GFAptrxbK8YyuFkuNUxf/JfcNHY8luKeyNl3JjpNDN4Opt6PPEJaAKmQsYVkm3sVUW
fUOZTBA/ILiT79r6DiNRSvmdbfK2fLoTqhV6GiFh1PJiroCm7RuyYT6xEkt3ax5l4S5l
gsDuFcjFfxbaMPMWai+jkIQ47A6RqhqSU3IOsI06uq6Mv32MeCXa4eWGSeBI4C6hheIm
lgDr/QnkQJbK6b9qshTNU+SSEn7IQFTRIn808xg+myFI2Ab6cg7MA7ILbWEIabWWruxX
Cgi4F7jRO9TXcMu+69BhU+QOnTTTdQNpqpspcYuClctWmLRHMQgXa9obyBMK8Q3dxRBm
QeZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-transfer-encoding;
bh=F8/ir1QA7Q8+e2rP5NV8qe86UW306I+zEQ1beMDq1iM=;
b=YAhu0yhIkJDkV+t/kh6Ut3gideff6JWlFRRWMI/KaDELxqTVP9Po3xj/tHp0jKBMON
4SMbHH2YK+6BrnrQKZRZyzH/7NtWtdjQimL2yxFxnaD6MSHbmOpYAi2cc3YTVf+8uwSn
GbuMLeUUUCSmPaZMUHGgV0PYrevn9gwWnQ0E6eeXQTVBX07sckJAoWGsTJsVYt6X85c6
eOmloTVzMHXnxlArV9cQqW8HgBdKW9074eGnn++kBj8bTiwiLKmlfDkhswBFdbPraMV8
YQPZR/KovdwEW0i1dfUJwaYXcsqwfpdidJeC7eZko/Qz6LI7kWRasUOQm/X95w4dbvi1
ZRIQ==
X-Gm-Message-State: AKaTC039dPBVPXv4AHn0lbarBvJaD28teWemiUnGrnJJpncJa5BYzbVenmJ2aMy25d4cttpr0XX/0jy5NsccHQ==
X-Received: by 10.176.83.151 with SMTP id k23mr32783696uaa.90.1480660537589;
Thu, 01 Dec 2016 22:35:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.137.20 with HTTP; Thu, 1 Dec 2016 22:35:36 -0800 (PST)
In-Reply-To: <201612020418.23011.luke@dashjr.org>
References: <08F5E788-8680-4BBE-8871-73FF022C52DB@xbt.hk>
<CABm2gDoQ8_Wpc+zCwf-sbUhLYYy-cjdO2dgvzADQX9PAq+yYnw@mail.gmail.com>
<201612020418.23011.luke@dashjr.org>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Fri, 2 Dec 2016 07:35:36 +0100
Message-ID: <CABm2gDqwtG-7yeT4CesSh=-CPuwpDy99E8qNO0Rz3C=MirNr7Q@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] New BIP: Hardfork warning system
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Fri, 02 Dec 2016 06:35:39 -0000
On Fri, Dec 2, 2016 at 5:18 AM, Luke Dashjr <luke@dashjr.org> wrote:
> On Friday, December 02, 2016 1:42:46 AM Jorge Tim=C3=B3n via bitcoin-dev =
wrote:
>> We can already warn users of a hardfork when a block is invalid (at
>> least) because of the highest bit in nVersion (as you say, because it
>> is forbidden since bip34 was deployed).
>
> The difference is that right now, full nodes will happily follow a shorte=
r
> best-valid chain. This BIP would require them to hold back at the best-co=
mmon
> block between the best-valid chain and the invalid chain, forcing the use=
r to
> make a decision whether to reject the invalid chain permanently, or upgra=
de to
> a version which can understand that chain as valid.
Ok, so the goal of the softfork then is to hold on is there is to
"hold on" on the most-work valid chain while there's an even-more-work
invalid chain and for new nodes force a response from the user. This
could be clearer in the motivation section.
We can still notify and force a response from the user with a single
invalid block (or N, or W accumulated work). Note that we don't need
to "hold on" while waiting for the user's response. Therefore I insist
there could be a PIB with all the recommended warnings but not
softfork (which this one could extend from).
Thinking as a full node user, I'm not sure I want my node to "hold on"
on validating new valid blocks just because there's some "longest"
invalid chain out there and I may chose to follow that instead later.
Before paying or copying another address to receive, I would
definitely would want the warning though.
Particularly as a miner (not that I'm one), I think validationless
mining shows us that some miners prefer to throw energy to the abyss
of validation uncertainty rather than stop their mining hardware.
What if when I give the response to the system I decide to pass on the
HF but it means my hardware have been not mining in the valid chain
for hours?
I would account that as "money lost thanks to a 'friendly' interface".
Specially if we're talking about a controversial hardfork.
If we're talking about an uncontroversial hardfork, I would definitely
prefer BIP9 coordination.
I would prefer to receive the warning when, say, 30% of the hashrate
is supporting an unknown change to the consensus rules (regardless of
it being a softfork or a hardfork, which I don't know yet until the hf
bit is used because the change is unknown to me), way before I need to
decide what branch to mine.
In fact, if I was a miner but not a user at the same time, after
knowing about the unknown hardfork and if I consider the hardfork to
be potentially controversial, I would try to coordinate with exchanges
(and pools if no solo mining) to be able to write a program that
chooses the chain likely to be most profitable depending on difficulty
and price feeds for every block.
In the case of a SHF, even more reason to keep mining on the old
chain, perhaps I mine one empty block (assuming that's a rule in the
SHF) out of luck, or maybe I should just start mining empty blocks
whenever I see the SHF bit active for a block whose chain keeps
growing.
Perhaps for a SHF we should use a valid bit instead of an invalid one
(clearing all possible fears with old and older nodes perceiving SHFs
differently as HFs and SFs respectively). We can trivially make old an
older nodes coincide in their perception of good-willing SHFs as
either HFs or SFs as we wish. Choosing divergence of perception from
the 2 versions we're considering makes no sense to me.
I'm reserving my judgement for which one I prefer just in case there's
actually an advantage in this divergence, but I've missed it.
>> It seems the softfork serves only to warn about soft-hardforks, assuming=
it
>> chooses to use this mechanism (which a malicious soft hardfork may not d=
o).
>
> Note: a malicious "SHF" is not a SHF at all, but an "evil fork".
Terminology, I think you get my point. I'm all for formalizing
definitions but please let's not slow down discussion unnecessarily.
I'm fine saying "evil fork" instead of "malicious SHF" if you prefer
that, but they're just the same thing.
>> In fact, you could reuse another of the prohibited bits to signal a soft=
-
>> hardfork while distinguishing it from a regular hardfork. And this will =
also
>> serve for old nodes that have not upgraded to the softfork. But, wait,
>> if you signal a soft-hardfork with an invalid bit, it's not a
>> soft-hardfork anymore, is it? It's simply a hardfork.
>
> Nodes implementing this BIP will see it as a simple hardfork, but will
> intentionally provide equivalent behaviour as older nodes which see it as=
a
> soft-hardfork. In other words, all [compatible] hardforks will now behave=
like
> a soft-hardfork without any special DMMS design.
Right, and those same mechanisms could be implemented using one of the
already prohibited bits (for example, just like the higher weight bit
in nHeight, the lowest value one was prohibited when BIP34 was
activated).
There's no need to invalidate another bit in the softfork (repeat: bit
1 got invalidated when bip34 was activated as well; or we could just
use a valid bit for SHFs).
> If Bitcoin's eventual hardfork is far enough down the road (such that no =
nodes
> remain from before this BIP are adopted), the SHF design could be safely =
done
> away with entirely. And either way, it makes it easier to resist an un-
> consented-to hardfork.
Right, I'm also under the assumption that a HF (or a SHF) would give
plenty of/enough time (to be defined, I suggest at least 1 year but we
really shouldn't get into this in this thread) in their
BIP9Deployment::nStartTime (or equivalent if BIP9 is not reused for
HF/SHF). Otherwise I would consider any HF or SHF controversial in
itself regardless of what it does (for not giving enough time to users
to adapt).
Therefore we can assume that all the warnings would be deployed in
advance to any HF or SHF, with or without a previous softfork.
I strongly disagree that the proposed softfork "[makes] it easier to
resist an un-consented-to hardfork". If anything, it makes it easier
to disrupt the old network if it doesn't fully consent to the HF. For
"un-consented-to SHFs" (or "evil HFs" if you prefer) I don't think
it's a safe to assume they will use an invalid bit to signal their
intend. At least if I was an "evil softhardforker" just interested in
disruption, I wouldn't do it (just like if I was an "evil hardforker"
I wouldn't use the normal hardfork bit).
|
