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
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E3218F67
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Feb 2016 17:36:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com
[209.85.217.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 33FC81B2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Feb 2016 17:36:08 +0000 (UTC)
Received: by mail-lb0-f169.google.com with SMTP id x4so36190055lbm.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 04 Feb 2016 09:36:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=Oe1u6+HUAU8cKeqkcGOyWUGKzgxqFiXgaPlauT0lfLc=;
b=TNwt3ew8/9L9z6NYkfqT8iLhEHETZ0zWYD5Ef0lPoOavodnyt6ML91mz2ofxzpAsNd
172serJiQIw8nqM+D8+Oh6+9Czjfm5cWgJ5eY6dgjqPm8v2GaQp7PEreBq7XYJ1ec72L
hEY8KpAA+QxxawkHMx3nbaTLTixji8wIeQhxw1ey70MMpol0QEAWN3fd8Gq4KBIrq7Na
etLvCZdpso78/qI1Ljb7U33TjhtZRnvnIvQXevSEGvOTbmWAzpiOBOXKsAM12teCFz+u
34ouIkuuExwKAhEuwg4PtCgy8XyuAr6K7ogsbnDoqtLguuZCL3EZCymsrKCW7Xu5pmAb
VuXg==
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:date
:message-id:subject:from:to:cc:content-type;
bh=Oe1u6+HUAU8cKeqkcGOyWUGKzgxqFiXgaPlauT0lfLc=;
b=dYZ94Xfw5rJCM/WTCZm3U+ehXLw7oFlOlL4M/NdnYNCtCOPl5oCVjdmw4SlOdMjU/L
BNfuo6TdVFWta76KjvSCm9YWEJphxKnm2PJevA8Ta4fx8eL1Nk9s0iZY5iGIScEHeMoJ
BynU6yfxX4klMdM9Oil14PUdw/8KaLRAUI6zsz5eXBKUGcDIVKmJ6UZSA7a9xMaXkslt
xwggLI4FbwSzcP+4+3ljmJ+eT7Lo6z08o76PXoy9Nr5jp2So4TDX8H667CvEvYNr9HaB
WHsZgn3Giu+NYn/jGNbsQPKiMtRSajmNVThFGJ7+j/vf2LbTFQrdch21WdjJX6UGYeKi
rGZQ==
X-Gm-Message-State: AG10YOQHJ4D+MoMA8kEWJ9el7R/klHB9hDXM7V8eVdfrAbkwvCcu7PV3Yuz3TKIN0Pcs4UjRf46+leL3QH4vgA==
MIME-Version: 1.0
X-Received: by 10.112.147.41 with SMTP id th9mr3970026lbb.74.1454607366449;
Thu, 04 Feb 2016 09:36:06 -0800 (PST)
Received: by 10.25.79.208 with HTTP; Thu, 4 Feb 2016 09:36:06 -0800 (PST)
In-Reply-To: <f225318eddd0aadc71861f988f2f4674@xbt.hk>
References: <f225318eddd0aadc71861f988f2f4674@xbt.hk>
Date: Thu, 4 Feb 2016 12:36:06 -0500
Message-ID: <CABsx9T2VoWm04i_vQv7u0vXM6hdMBM29bnMSuv8RmMFMGxOdpg@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: jl2012 <jl2012@xbt.hk>
Content-Type: multipart/alternative; boundary=047d7b3a84c45d73cf052af52bf5
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
X-Mailman-Approved-At: Thu, 04 Feb 2016 17:37:05 +0000
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: Thu, 04 Feb 2016 17:36:09 -0000
--047d7b3a84c45d73cf052af52bf5
Content-Type: text/plain; charset=UTF-8
This BIP is unnecessary, in my opinion.
I'm going to take issue with items (2) and (3) that are the motivation for
this BIP:
" 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."
If a hardfork is deployed by increasing the version number in blocks (as is
done for soft forks), then there is no risk-- Full and SPV nodes should
notice that they are seeing up-version blocks and warn the user that they
are using obsolete software.
It doesn't matter if the software is obsolete because of hard or soft fork,
the difference in risks between those two cases will not be understood by
the typical full node or SPV node user.
" 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."
If a hard or soft fork uses a 'grace period' (as described in BIP 9 or BIP
101) then there is essentially no risk that a reorg will happen past the
triggering block. A block-chain re-org of two thousand or more blocks on
the main Bitcoin chain is unthinkable-- the economic chaos would be
massive, and the reaction to such a drastic (and extremely unlikely) event
would certainly be a hastily imposed checkpoint to get everybody back onto
the chain that everybody was using for economic transactions.
Since I don't agree with the motivations for this BIP, I don't think the
proposed mechanism (a negative-version-number-block) is necessary. And
since it would simply add more consensus-level code, I believe the
keep-it-simple principle applies.
--
--
Gavin Andresen
--047d7b3a84c45d73cf052af52bf5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>This BIP is unnecessary, in my opinion.</div><div><br=
></div>I'm going to take issue with items (2) and (3) that are the moti=
vation for this BIP:<br><div class=3D"gmail_extra"><br></div>" 2.=C2=
=A0Full nodes and SPV nodes following original consensus rules may not be a=
ware of the deployment of a hardfork. They may stick to an economic-minorit=
y fork and unknowingly accept devalued legacy tokens."<div class=3D"gm=
ail_extra"><br></div><div class=3D"gmail_extra">If a hardfork is deployed b=
y increasing the version number in blocks (as is done for soft forks), then=
there is no risk-- Full and SPV nodes should notice that they are seeing u=
p-version blocks and warn the user that they are using obsolete software.</=
div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">It does=
n't matter if the software is obsolete because of hard or soft fork, th=
e difference in risks between those two cases will not be understood by the=
typical full node or SPV node user.</div><div class=3D"gmail_extra"><br></=
div><div class=3D"gmail_extra">" 3.=C2=A0<span style=3D"font-family:Ve=
rdana,Geneva,sans-serif;font-size:13.3333px">In the case which the original=
consensus rules are also valid under the new consensus rules, users follow=
ing the new chain may unexpectedly reorg back to the original chain if it g=
rows faster than the new one. People may find their confirmed transactions =
becoming unconfirmed and lose money."</span></div><div class=3D"gmail_=
extra"><span style=3D"font-family:Verdana,Geneva,sans-serif;font-size:13.33=
33px"><br></span></div><div class=3D"gmail_extra"><span style=3D"font-famil=
y:Verdana,Geneva,sans-serif;font-size:13.3333px">If a hard or soft fork use=
s a 'grace period' (as described in BIP 9 or BIP 101) then there is=
essentially no risk that a reorg will happen past the triggering block. A =
block-chain re-org of two thousand or more blocks on the main Bitcoin chain=
is unthinkable-- the economic chaos would be massive, and the reaction to =
such a drastic (and extremely unlikely) event would certainly be a hastily =
imposed checkpoint to get everybody back onto the chain that everybody was =
using for economic transactions.</span></div><div class=3D"gmail_extra"><sp=
an style=3D"font-family:Verdana,Geneva,sans-serif;font-size:13.3333px"><br>=
</span></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra=
"><font face=3D"Verdana, Geneva, sans-serif"><span style=3D"font-size:13.33=
33px">Since I don't agree with the motivations for this BIP, I don'=
t think the proposed mechanism (a negative-version-number-block) is necessa=
ry. And since it would simply add more consensus-level code, I believe the =
keep-it-simple principle applies.</span></font></div><div class=3D"gmail_ex=
tra"><br></div><div class=3D"gmail_extra"><div><br></div>-- <br><div class=
=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>--<br>Gavi=
n Andresen<br></div><div><br></div></div></div></div></div>
</div></div>
--047d7b3a84c45d73cf052af52bf5--
|
