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
|
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 8AC0DDFC
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Feb 2016 19:27:35 +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 7A247E1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 7 Feb 2016 19:27:31 +0000 (UTC)
Received: from 119246245241.ctinets.com ([119.246.245.241]:53400 helo=2012R2)
by server47.web-hosting.com with esmtpsa
(TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86)
(envelope-from <jl2012@xbt.hk>)
id 1aSUzZ-001ZBS-LZ; Sun, 07 Feb 2016 14:27:30 -0500
From: <jl2012@xbt.hk>
To: "'Gavin Andresen'" <gavinandresen@gmail.com>,
"'Gregory Maxwell'" <greg@xiph.org>
References: <f225318eddd0aadc71861f988f2f4674@xbt.hk> <CAAS2fgT_f858GFVY9RAN1skd8_9Q_T1ZFoUXCQiC3o3B+z4oXw@mail.gmail.com>
<CABsx9T1AdWPAtGHkhMAGtnWtthE+oienUBm0iXEfUG05S6ko-Q@mail.gmail.com>
In-Reply-To: <CABsx9T1AdWPAtGHkhMAGtnWtthE+oienUBm0iXEfUG05S6ko-Q@mail.gmail.com>
Date: Mon, 8 Feb 2016 03:27:48 +0800
Message-ID: <232901d161dd$a35f8d30$ea1ea790$@xbt.hk>
MIME-Version: 1.0
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHbMrTCecyH04NftjxoC3dSKJ6yWAIfgCv5AT+pZiae8lanIA==
Content-Language: en-hk
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,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] 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: Sun, 07 Feb 2016 19:27:35 -0000
From: Gavin Andresen [mailto:gavinandresen@gmail.com]=20
Sent: Friday, 5 February, 2016 06:16
To: Gregory Maxwell <greg@xiph.org>
Cc: jl2012 <jl2012@xbt.hk>; Bitcoin Dev =
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hardfork bit BIP
>It is always possible I'm being dense, but I still don't understand how =
this proposal makes a chain-forking situation better for anybody.
>If there are SPV clients that don't pay attention to versions in block =
headers, then setting the block version negative doesn't directly help =
them, they will ignore it in any case.
It is unfortunate SPV clients are not following that. However, they =
SHOULD follow that. It becomes a self fulfilling prophecy if we decide =
not to do that if SPV are not following that.
>If the worry is full nodes that are not upgraded, then a block with a =
negative version number will, indeed, fork them off the the chain, in =
exactly the same way a block with new hard-forking consensus rules =
would. And with the same consequences (if there is any hashpower not =
paying attention, then a worthless minority chain might continue on with =
the old rules).
It will distinguish between a planned hardfork and an accidental =
hardfork, and full nodes may react differently. Particularly, a planned =
unknown hardfork is a strong indication that the original chain has =
become economic minority and the non-upgraded full node should stop =
accepting incoming tx immediately.
>If the worry is not-upgraded SPV clients connecting to the old, =
not-upgraded full nodes, I don't see how this proposed BIP helps.
Same for not-upgraded full nodes following not-upgraded full nodes. =
Anyway, the header with enough PoW should still be propagated.
>I think a much better idea than this proposed BIP would be a BIP that =
recommends that SPV clients to pay attention to block version numbers in =
the headers that they download, and warn if there is a soft OR hard fork =
that they don't know about.
Normal version number only suggests softforks, which is usually not a =
concern for SPV clients. An unknown hardfork is a completely different =
story as the values of the forks are completely unknown.
>It is also a very good idea for SPV clients to pay attention to =
timestamps in the block headers that the receive, and to warn if blocks =
were generated either much slower or faster than statistically likely. =
Doing that (as Bitcoin Core already does) will mitigate Sybil attacks in =
general.
Yes, they should.
--=20
--
Gavin Andresen
|
