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
|
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 DF237A87
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Dec 2016 01:42:48 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f178.google.com (mail-ua0-f178.google.com
[209.85.217.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6239E167
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Dec 2016 01:42:48 +0000 (UTC)
Received: by mail-ua0-f178.google.com with SMTP id 51so267387092uai.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 01 Dec 2016 17:42:48 -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;
bh=qiiVkkkqFXyMnHTuXuwcPLKcKVB0AvKCWApO2FCSEr4=;
b=1n4d3w9zXTgoG4fQUgsmmijWD74SkZEKhBDzx+2r3dDl9ys0Qo/NL+CXzhPG85mTEg
byKQY0mon/80jb+5hafYlDBP1UCEaM6boaF0CYrfdU2XdrH8SiLrL96X0Q5TD463k0n6
Mwjan6ru5CwF5/nUZgxfi0qsvA//HV4014KVp7gmrhvVMSVomS5zMUHXQP6sDmX4tU3o
RMPjeayQcaVnMIRSvfukHJn/rjvCnW8fXEL/MprTJ/zvJmIXUQPvLslbBaCnhEn085oT
6/khKYW+mFQT4O0xxwVCXF7s6VJNRBdXgCICe8SCj8Wx/Bt7+aXtmMWS50av+Qzw1C0d
EV3Q==
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;
bh=qiiVkkkqFXyMnHTuXuwcPLKcKVB0AvKCWApO2FCSEr4=;
b=WfAwXGPFLopsznM8kyI0/UXTIJ1Hh2tjfwwNaXFyXLH4iv+U7WbEueaBBudjRvrute
KYDIG1ZhyxaPaQEW573gbKD+c4jxWRSUj5AXK4CX4z0dzWfH/pcCO3GCjW5URLYUJLPO
HUgHICwqWod/cu+IuGjeZMVkYR6tWKqixn7APd09+Yyts0Jr4CkPqlYt3hwvJEzrg8M4
LQJHQbNQeLZmLO8MYs9Kex5/WG8s0Dy7kI/Nd8oUGLKaRD9XKoeeV7fbWNqZn7OgfYxZ
zLa+xTpViZfYIRSTLuydOjoHxqvvSgXn77J4MEbP2AbFr7n3aLbyGXu6UKXUumyljwQt
24Mw==
X-Gm-Message-State: AKaTC00evSVKUXRW07ZMR/20YU2pZGrnW8Vwu15432LgoYOaTHdExhoe3OV050N6/JMy8Re/iTjZ4stEMWBDmA==
X-Received: by 10.159.48.65 with SMTP id i1mr30597262uab.12.1480642967532;
Thu, 01 Dec 2016 17:42:47 -0800 (PST)
MIME-Version: 1.0
Received: by 10.31.137.20 with HTTP; Thu, 1 Dec 2016 17:42:46 -0800 (PST)
In-Reply-To: <08F5E788-8680-4BBE-8871-73FF022C52DB@xbt.hk>
References: <08F5E788-8680-4BBE-8871-73FF022C52DB@xbt.hk>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Fri, 2 Dec 2016 02:42:46 +0100
Message-ID: <CABm2gDoQ8_Wpc+zCwf-sbUhLYYy-cjdO2dgvzADQX9PAq+yYnw@mail.gmail.com>
To: Johnson Lau <jl2012@xbt.hk>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM 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] 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 01:42:49 -0000
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). 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 do). 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.
Your softfork would result in soft hardforks being hardforks for nodes
that upgraded to this softfork, but softforks for older nodes.
Is this the intended behaviour? if so, why?
I would rather have a simpler BIP that doesn't require a softfork
(whether it recommends soft-hardforks to use one of the currently
invalid bits, but a different one than from hardforks or not, but I
also don't see the reason why soft-hardforks should appear as invalid
blocks for older nodes instead of using regular softfork warning
[besides, in this case, after the "unkown softfork" warning you will
get only empty blocks, which may make you suspicious]).
|
