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
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
|
Return-Path: <hampus.sjoberg@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CB935AEF
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Jun 2017 22:16:02 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f181.google.com (mail-qt0-f181.google.com
[209.85.216.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CD3FC1F2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Jun 2017 22:16:01 +0000 (UTC)
Received: by mail-qt0-f181.google.com with SMTP id u19so144541152qta.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Jun 2017 15:16:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=MgHQtpFKVpvjGE/bsULH4lt0/cJvTbkSK2ti9+T9Vbo=;
b=d2cmdE3S6z0bFu9Fyu9EbcDv0XAzAs5p3M1VK8+ZekiMD+vHFIOLDA0Qknyp0o6MGA
JunFTZxkyLsLvzs/TJl55Fz/q0CSPgRRdUO4FoiqklTgbj0Q65KhXnt5hb7xZ82qWHGX
m3m1GYH0Z/z6Vt0yj7HwKN7x1nRrSPRHNw970LGXUGoGIspr9YtB5q1OnOOea122D9Ny
BJ34RxuCvSNOtrUo+x6aWVd5leMjoFL12GSqIpDfWH+/LSWnFTCq1/zCvGWYyzrdkNKi
518xHVc/fp9exIlwppb7ta5R1jbu4C0torpQAzwrTGTf7TxXSTiY17ib9e/OqcDrWjyj
a7sQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=MgHQtpFKVpvjGE/bsULH4lt0/cJvTbkSK2ti9+T9Vbo=;
b=aFfLO6uC5B9m3H5bymSIn3xkGIZERorVmrHMDMDYGB65QCAJYcceCMrWCLSRYxqQZU
/fAqyk5fhHpzKcI9SmKZvZcU8EBhrz4rMqP5Ey5UyEGMC5l0llUV5dQfM5pHREurUVdZ
QIayvoaxUy0jVZ942kJumfbn6wiuDtOMBx9Cty7YlXSFnR1+F2H5Fy4lHQSxcjYIqHEp
SpISKi5d2SOuPzyMXsTFYr2EvSq4pa/b1f7Tb/OOcdMFF7jE5j28fMB8hMfRr530JIqD
8Q8jFFOa6Qdq/xX9tQ7RB27FSU+R8Ymr97O48VDjPIcNDgSuNbLGVaOt0gcdGGHBQFOS
oYag==
X-Gm-Message-State: AKS2vOwr9WZhLf5oqprmnZMPDOiapeIcHRCuD4oyg1L9HZo22iPM1cDJ
PAGeF78yfhVKJSS23j1nY6SRJ1gZYg==
X-Received: by 10.237.44.166 with SMTP id g35mr38172257qtd.212.1497996960966;
Tue, 20 Jun 2017 15:16:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.155.140 with HTTP; Tue, 20 Jun 2017 15:15:59 -0700 (PDT)
In-Reply-To: <CAAS2fgSZ_X3G7j3-S6tAGPe2TOTT2umBB8a0RHpD-wAHN9aPgw@mail.gmail.com>
References: <CAJowKgLtu-HUDuakk4DDU53nyChbQk_zY=f5OO2j1Za95PdL7w@mail.gmail.com>
<CAAS2fgSZ_X3G7j3-S6tAGPe2TOTT2umBB8a0RHpD-wAHN9aPgw@mail.gmail.com>
From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= <hampus.sjoberg@gmail.com>
Date: Wed, 21 Jun 2017 00:15:59 +0200
Message-ID: <CAFMkqK_73RrpaS2oJQ-0o6oC29m6a1h411_P7HmVcAyX712Sgw@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
Content-Type: multipart/alternative; boundary="94eb2c12526abbaf1605526b98a5"
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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Miners forced to run non-core code in order to
get segwit activated
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: Tue, 20 Jun 2017 22:16:02 -0000
--94eb2c12526abbaf1605526b98a5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> Ironically, it looks like most of the segwit2x signaling miners are
> faking it (because they're not signaling segwit which it requires).
> It'll be unfortunate if some aren't faking it and start orphaning
> their own blocks because they are failing to signal segwit.
Well, they're doing some kind of "pre-signaling" in the coinbase at the
moment, because the segwit2x project is still in alpha-phase according to
the timeline. They're just showing commitment.
I'm sure they will begin signaling on version bit 4/BIP91 as well as
actually running a segwit2x node when the time comes.
> As far as prevent a chain split goes, all those things
> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
> don't think that holds.
Segwit2x/BIP91/BIP148 will orphan miners that do not run a Segwit2x (or
BIP148) node, because they wouldn't have the new consensus rule of
requiring all blocks to signal for segwit.
I don't believe there would be any long lasting chainsplit though (because
of the ~80% hashrate support on segwit2x), perhaps 2-3 blocks if we get
unlucky.
Hampus
2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:
> On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Because a large percentage of miners are indifferent, right now miners
> have
> > to choose between BIP148 and Segwit2x if they want to activate Segwit.
>
> Miners can simply continuing signaling segwit, which will leave them
> at least soft-fork compatible with BIP148 and BIP91 (and god knows
> what "segwit2x" is since they keep changing the actual definition and
> do not have a specification; but last I saw the near-term behavior the
> same as BIP91 but with a radically reduced activation window, so the
> story would be the same there in the near term).
>
> Ironically, it looks like most of the segwit2x signaling miners are
> faking it (because they're not signaling segwit which it requires).
> It'll be unfortunate if some aren't faking it and start orphaning
> their own blocks because they are failing to signal segwit.
>
> I don't think the rejection of segwit2x from Bitcoin's developers
> could be any more resolute than what we've already seen:
> https://en.bitcoin.it/wiki/Segwit_support
>
> On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > I think it is very na=C3=AFve to assume that any shift would be tempora=
ry.
> > We have a hard enough time getting miners to proactively upgrade to
> > recent versions of the reference bitcoin daemon. If miners interpret
> > the situation as being forced to run non-reference software in order
> > to prevent a chain split because a lack of support from Bitcoin Core,
> > that could be a one-way street.
>
> I think this is somewhat naive and sounds a lot like the repeat of the
> previously debunked "XT" and "Classic" hysteria.
>
> There is a reason that segwit2x is pretty much unanimously rejected by
> the technical community. And just like with XT/Classic/Unlimited
> you'll continue to see a strong correlation with people who are
> unwilling and unable to keep updating the software at an acceptable
> level of quality-- esp. because the very founding on their fork is
> predicated on discarding those properties.
>
> If miners want to go off and create an altcoin-- welp, thats something
> they can always do, and nothing about that will force anyone to go
> along with it.
>
> As far as prevent a chain split goes, all those things
> (148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I
> don't think that holds.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--94eb2c12526abbaf1605526b98a5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div>> Ironically, it looks like most of=
the segwit2x signaling miners are<br>> faking it (because they're n=
ot signaling segwit which it requires).<br>
> It'll be unfortunate if some aren't faking it and start orphan=
ing<br>
> their own blocks because they are failing to signal segwit.<br><br></d=
iv>Well, they're doing some kind of "pre-signaling" in the co=
inbase at the moment, because the segwit2x project is still in alpha-phase =
according to the timeline. They're just showing commitment.<br>I'm =
sure they will begin signaling on version bit 4/BIP91 as well as actually r=
unning a segwit2x node when the time comes.<br><br>> As far as prevent a=
chain split goes, all those things<br>> (148/91/segwit2x(per today)) ef=
fectively guarantee a chainsplit-- so I<br>> don't think that holds.=
<br><br></div> Segwit2x/BIP91/BIP148 will orphan miners that do not run a S=
egwit2x (or BIP148) node, because they wouldn't have the new consensus =
rule of requiring all blocks to signal for segwit.<br></div>I don't bel=
ieve there would be any long lasting chainsplit though (because of the ~80%=
hashrate support on segwit2x), perhaps 2-3 blocks if we get unlucky.<br><b=
r></div>Hampus<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev <span dir=
=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span>:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><span class=3D"">On Tue, Jun 20, 2017 at 3:44 PM,=
Erik Aronesty via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.<wbr>linuxfoundation.org</a>> wrote:<br>
> Because a large percentage of miners are indifferent, right now miners=
have<br>
> to choose between BIP148 and Segwit2x if they want to activate Segwit.=
<br>
<br>
</span>Miners can simply continuing signaling segwit, which will leave them=
<br>
at least soft-fork compatible with BIP148 and BIP91 (and god knows<br>
what "segwit2x" is since they keep changing the actual definition=
and<br>
do not have a specification; but last I saw the near-term behavior the<br>
same as BIP91 but with a radically reduced activation window, so the<br>
story would be the same there in the near term).<br>
<br>
Ironically, it looks like most of the segwit2x signaling miners are<br>
faking it (because they're not signaling segwit which it requires).<br>
It'll be unfortunate if some aren't faking it and start orphaning<b=
r>
their own blocks because they are failing to signal segwit.<br>
<br>
I don't think the rejection of segwit2x from Bitcoin's developers<b=
r>
could be any more resolute than what we've already seen:<br>
<a href=3D"https://en.bitcoin.it/wiki/Segwit_support" rel=3D"noreferrer" ta=
rget=3D"_blank">https://en.bitcoin.it/wiki/<wbr>Segwit_support</a><br>
<br>
On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitcoin-dev<br>
<span class=3D""><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
> I think it is very na=C3=AFve to assume that any shift would be tempor=
ary.<br>
> We have a hard enough time getting miners to proactively upgrade to<br=
>
> recent versions of the reference bitcoin daemon. If miners interpret<b=
r>
> the situation as being forced to run non-reference software in order<b=
r>
> to prevent a chain split because a lack of support from Bitcoin Core,<=
br>
> that could be a one-way street.<br>
<br>
</span>I think this is somewhat naive and sounds a lot like the repeat of t=
he<br>
previously debunked "XT" and "Classic" hysteria.<br>
<br>
There is a reason that segwit2x is pretty much unanimously rejected by<br>
the technical community.=C2=A0 And just like with XT/Classic/Unlimited<br>
you'll continue to see a strong correlation with people who are<br>
unwilling and unable to keep updating the software at an acceptable<br>
level of quality-- esp. because the very founding on their fork is<br>
predicated on discarding those properties.<br>
<br>
If miners want to go off and create an altcoin-- welp, thats something<br>
they can always do,=C2=A0 and nothing about that will force anyone to go<br=
>
along with it.<br>
<br>
As far as prevent a chain split goes, all those things<br>
(148/91/segwit2x(per today)) effectively guarantee a chainsplit-- so I<br>
don't think that holds.<br>
<div class=3D"HOEnZb"><div class=3D"h5">______________________________<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>
</div></div></blockquote></div><br></div>
--94eb2c12526abbaf1605526b98a5--
|
