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
|
Return-Path: <morcos@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 82FD95AC
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 14:32:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f52.google.com (mail-it0-f52.google.com
[209.85.214.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5B330286
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 14:32:26 +0000 (UTC)
Received: by mail-it0-f52.google.com with SMTP id l8so66717285iti.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Nov 2016 06:32:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=z261v7BmfYofnQIYBmI+tgrueSlc4N7kiFY162Oxoc4=;
b=A/0fNCkL1QaFBku+JvZ/dQwzk34Iw4Eogy/m0ll1BpJY4ASiRumt1UlSl5CXLGrw9M
SvCKx2yDlm1f2ozWHPd9RoFDVwEG8UAn/QPeWunDjipDDRDVOGq1DPM24wQbiS21iQlO
yUqi+ObIMVWwreL4QxKEEiWHFvbIjlK0tUDDfvNuPFyd+fTFUq7/PlmWTa5BvVtLmYrU
qfu0wrIhiSGgZdJRjwuLxreNTdfKkeT5XdZgkDbMlSe9W/8HXIi6qphzQH8CswvVtFOg
5IRNsSk/qheiOaMhb6JP0nxArJ1I8UXCBOO1tDvijTdvofZYA7yvxlAdut9u0bpbD8aj
5n0g==
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=z261v7BmfYofnQIYBmI+tgrueSlc4N7kiFY162Oxoc4=;
b=QUelTUq2ouL6lKdm4wVUbiqYWU/W8vAxw6O+RKymF+lq/X+5H08pipSsm/w1sANePO
6vVGcQvbOYsGKVD8xbS53pnZvPMzHKaJcGf5jvb4S1nK+Khdpaucixd+isiGSu4HBKZC
bjO6IaPAJ4Hq5CVtIvULiLvmzG3jlXa9ZkrWZRKzMfdHfBhQSavxvupZTdJ2Wy3Dxi0D
k0WWAKlCKXMYGrIwXtU7dNQIgU/0ExuVQbi47O1HtWsE/qIiaJcfMTGL93/48I4QYElG
V/rodebhF3Xf5CZ/xV8Yb3JKWrgtJrH7MgBBkh6vK9jO/Fz8qz56FIGD++B6TfWW6Ysa
xF1Q==
X-Gm-Message-State: ABUngvczMMRy8CBCAZ8U3x7sdRAdZ12X8VxNkGpRGwSdhPPhlCPD283/QCKzVd79BLvXd673XIC1V5rdlHALcA==
X-Received: by 10.107.23.134 with SMTP id 128mr2547654iox.162.1479306745666;
Wed, 16 Nov 2016 06:32:25 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.119.199 with HTTP; Wed, 16 Nov 2016 06:32:24 -0800 (PST)
In-Reply-To: <CAE-z3OXdiyS_5HEFu1VLG1DH_K1QUBTSy49nXh1M4tcuoi6D_w@mail.gmail.com>
References: <CAFp6fsGmynRXLCqKAA+iBXObGOZ2h3DVW8k5L9kSfbPmL1Y-QQ@mail.gmail.com>
<CEDAD65E-512A-43CA-9BD6-56F7D9E6897C@voskuil.org>
<CADJgMzunxU2-7Z_ZPafNY4BPRu0x9oeh6v2dg0nUYqxJbXeGYA@mail.gmail.com>
<33BFC318-0BB4-48DB-B5DC-08247FAC6E5A@voskuil.org>
<CADL_X_dJ8YuDevKR4xA+PTy9D089dAeZ1F3ZwSYG6MrMvkLweg@mail.gmail.com>
<A98BB7F2-7AE2-4D84-9F38-7E7E9D5D3210@voskuil.org>
<CAE-z3OXdiyS_5HEFu1VLG1DH_K1QUBTSy49nXh1M4tcuoi6D_w@mail.gmail.com>
From: Alex Morcos <morcos@gmail.com>
Date: Wed, 16 Nov 2016 09:32:24 -0500
Message-ID: <CAPWm=eUQjpELFB2A9vJ8j6Y5Zvts9YqkZYNCO0aDnNSb+VwFvg@mail.gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c05b14a16e4d905416bf1d4
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
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] [BIP Proposal] Buried Deployments
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: Wed, 16 Nov 2016 14:32:27 -0000
--94eb2c05b14a16e4d905416bf1d4
Content-Type: text/plain; charset=UTF-8
I think we are misunderstanding the effect of this change.
It's still "OK" for a 50k re-org to happen.
We're just saying that if it does, we will now have potentially introduced
a hard fork between new client and old clients if the reorg contains
earlier signaling for the most recent ISM soft fork and then blocks which
do not conform to that soft fork before the block height encoded activation.
I think the argument is this doesn't substantially add to the confusion or
usability of the system as its likely that old software won't even handle
50k block reorgs cleanly anyway and there will clearly have to be human
coordination at the time of the event. In the unlikely event that the new
chain does cause such a hard fork, that coordination can result in everyone
upgrading to software that supports the new rules anyway.
So no, I don't think we should add a checkpoint. I think we should all
just agree to a hard fork that only has a very very slim chance of any
practical effect.
In response to Thomas' email. I think ideally we would treat these soft
forks the way we did BIP30 which is to say that we're just introducing a
further soft fork that applies to all blocks except for the historical
exceptions. So then its a almost no-op soft fork with no risk of hard
fork. This however isn't practical with at least BIP 34 without storing
the hashes of all 200K blocks that don't meet the requirement.
On Wed, Nov 16, 2016 at 9:18 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Nov 16, 2016 at 1:58 PM, Eric Voskuil via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Are checkpoints good now? Are hard forks okay now?
>>
>
> I think that at least one checkpoint should be included. The assumption
> is that no 50k re-orgs will happen, and that assumption should be directly
> checked.
>
> Checkpointing only needs to happen during the headers-first part of the
> download.
>
> If the block at the BIP-65 height is checkpointed, then the comparisons
> for the other ones are automatically correct. They are unnecessary, since
> the checkpoint protects all earlier block, but many people would like to be
> able to verify the legacy chain.
>
> This makes the change a soft-fork rather than a hard fork. Chains that
> don't go through the checkpoint are rejected but no new chains are allowed.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--94eb2c05b14a16e4d905416bf1d4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think we are misunderstanding the effect of this change.=
<div>It's still "OK" for a 50k re-org to happen.</div><div>We=
're just saying that if it does, we will now have potentially introduce=
d a hard fork between new client and old clients if the reorg contains earl=
ier signaling for the most recent ISM soft fork and then blocks which do no=
t conform to that soft fork before the block height encoded activation.</di=
v><div><br></div><div>I think the argument is this doesn't substantiall=
y add to the confusion or usability of the system as its likely that old so=
ftware won't even handle 50k block reorgs cleanly anyway and there will=
clearly have to be human coordination at the time of the event.=C2=A0 In t=
he unlikely event that the new chain does cause such a hard fork, that coor=
dination can result in everyone upgrading to software that supports the new=
rules anyway.</div><div><br></div><div>So no, I don't think we should =
add a checkpoint.=C2=A0 I think we should all just agree to a hard fork tha=
t only has a very very slim chance of any practical effect.</div><div><br><=
/div><div>In response to Thomas' email.=C2=A0 I think ideally we would =
treat these soft forks the way we did BIP30 which is to say that we're =
just introducing a further soft fork that applies to all blocks except for =
the historical exceptions.=C2=A0 So then its a almost no-op soft fork with =
no risk of hard fork. =C2=A0 This however isn't practical with at least=
BIP 34 without storing the hashes of all 200K blocks that don't meet t=
he requirement.</div><div><br></div><div><br></div></div><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote">On Wed, Nov 16, 2016 at 9:18 AM, Ti=
er Nolan via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfound=
ation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=
=3D"">On Wed, Nov 16, 2016 at 1:58 PM, Eric Voskuil via bitcoin-dev <span d=
ir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" tar=
get=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>></span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div></div>Are che=
ckpoints good now? Are hard forks okay now?</div></blockquote><div><br></di=
v></span><div>I think that at least one checkpoint should be included.=C2=
=A0 The assumption is that no 50k re-orgs will happen, and that assumption =
should be directly checked.<br><br>Checkpointing only needs to happen durin=
g the headers-first part of the download.<br><br></div><div>If the block at=
the BIP-65 height is checkpointed, then the comparisons for the other ones=
are automatically correct.=C2=A0 They are unnecessary, since the checkpoin=
t protects all earlier block, but many people would like to be able to veri=
fy the legacy chain.<br></div><div><br></div><div></div><div>This makes the=
change a soft-fork rather than a hard fork.=C2=A0 Chains that don't go=
through the checkpoint are rejected but no new chains are allowed.<br></di=
v></div></div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>
--94eb2c05b14a16e4d905416bf1d4--
|
