summaryrefslogtreecommitdiff
path: root/ac/2b2f9847e3faf106be8fbe7e44e164f2965de7
blob: 130f6b4ca43351b975e354d18d68934c386945fa (plain)
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
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5C4538E3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 27 Jun 2017 15:43:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com
	[209.85.220.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 80A80184
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 27 Jun 2017 15:43:34 +0000 (UTC)
Received: by mail-qk0-f180.google.com with SMTP id d78so28334499qkb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 27 Jun 2017 08:43:34 -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=vMd2UcFsv7PW8XMClusc4XEAcp+v4KERa6lCrZbuoyM=;
	b=IXwH3bjcRAuxjPqJj6MqAVFBgR3n6ePgCID6EQ7WMJVyvowcL5Om8nN8q+ifyLBgc0
	RXU/skr5orSgnIy+ngzlkcDBW+XZPIUUKdbPErJFifimO4wYBcZOtucc0/5CaHYBAyV3
	Aw2tb7+SWUWARsTKbhFv3szfp4GbYk2BDRxVppyHbzyMOu/7I6g9GYsNY2lPoTYYDxqz
	aKqQanGFYKSU4M9oeLiwDsxo3MH2SFXU/VPJja4bC4ohocktz+kc95o8dtPqgU2I1uij
	IhKQklE4it42l+NB67oNJuDtGZdccCN0oAwOABRk29gczTuX1Nrtnr5Q85fJ8aZMponi
	rUlw==
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=vMd2UcFsv7PW8XMClusc4XEAcp+v4KERa6lCrZbuoyM=;
	b=eorVzn5sy8L6NgHiNvZ6HEazaczbFgGLA5ZiGrjcYyBNQ3CA+oPgPaJUKw5ful318Q
	A7le0JSoek3HNzilnx+8gu8Kmt+C7cVzPQ3yVux9DfzS/ifs5GecEbPue4zzHtm91NAi
	p90H3xpsEU2vm6zyMq0NSFULd5xn9cNSi66kgeCBPXEZaKrDDc8Q7Sm8rucrtd1CNfra
	DLBbhYHtKVvl/ukXghg21p0slP8bUguco4W842ANm0OBD3eW6X3uT8kO8afrJ3UvLY7v
	kxQFFxwyVNNf3w05/mWLMxDZaGMfZlvrA8IJrUwzmTl/B08IWst8gPTFzp85BYHwtm2f
	JFlg==
X-Gm-Message-State: AKS2vOz9JFruSf5n566lo0S4veh3IcFcVnzXK+MLyfCJILrKRY6RzoUo
	S71b9RLnlZ6PfSw1tEybLVzRmP9i/g==
X-Received: by 10.55.186.66 with SMTP id k63mr7358506qkf.243.1498578213588;
	Tue, 27 Jun 2017 08:43:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.135.113 with HTTP; Tue, 27 Jun 2017 08:42:53 -0700 (PDT)
In-Reply-To: <CAAUaCyijF1eHSffUYf9Mrv+KP5H+NLBcy5MEhMUyT6Rxcbx93g@mail.gmail.com>
References: <CAJowKgLtu-HUDuakk4DDU53nyChbQk_zY=f5OO2j1Za95PdL7w@mail.gmail.com>
	<CAAS2fgSZ_X3G7j3-S6tAGPe2TOTT2umBB8a0RHpD-wAHN9aPgw@mail.gmail.com>
	<CAFMkqK_73RrpaS2oJQ-0o6oC29m6a1h411_P7HmVcAyX712Sgw@mail.gmail.com>
	<CAAUaCyg2Nmsa2UaO2msBqSFeHLetUUN+cTETvSSmB7c=nH9ZhQ@mail.gmail.com>
	<BC758648-BD4F-4DEF-8B79-7E8E0A887033@friedenbach.org>
	<CAAUaCyh+4m+t9d4yOoEOf6VUDyJ=sUpDT3hD3cDmd9dcBQZ+nw@mail.gmail.com>
	<CAJowKgJcp7d30LsrDZ5iR6-k9Ncz0N90pxs2GmJkuG1qYDG6GQ@mail.gmail.com>
	<CAOG=w-tPgJ5baaNiZC5rTs_y=eV7AU+F=aGaH+uObqaB-VgL2w@mail.gmail.com>
	<CAAUaCyijF1eHSffUYf9Mrv+KP5H+NLBcy5MEhMUyT6Rxcbx93g@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Tue, 27 Jun 2017 12:42:53 -0300
Message-ID: <CAKzdR-rvP9RLJ=qGDMVyOT3WVqp7q2tUPpzbaQZ=wStsFSCbWA@mail.gmail.com>
To: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c0454fa16d4d10552f2eeb1"
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	HTML_OBFUSCATE_05_10, 
	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
Cc: Bitcoin Dev <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, 27 Jun 2017 15:43:36 -0000

--94eb2c0454fa16d4d10552f2eeb1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Currently the only implementation that fulfills the requirements of the NYA
agreement is the segwit2x/btc1 implementation, which is being finalized
this week.

Segwit2mb does not fulfill the NYA agreement.

I'm asking now the segwit2x development team when a BIP will be ready so
that Core has the opportunity to evaluate the technical proposal.




On Wed, Jun 21, 2017 at 1:05 AM, Jacob Eliosoff via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Well, this Saturday's "Chinese roundtable" statement from a bunch of
> miners (https://pastebin.com/b3St9VCF) says they intend "NYA" in the
> coinbase as support for "the New York consensus SegWit2x program btc1 (
> https://github.com/btc1)", whose code includes the (accelerated
> 336-block) BIP 91 change.  So, other facts or interpretations could come =
to
> light, but until they do we should probably assume that's what the "NYA"
> (which just broke 80% over the last 24h) means.
>
>
> On Tue, Jun 20, 2017 at 10:11 PM, Mark Friedenbach <mark@friedenbach.org>
> wrote:
>
>> 80% have set "NYA" in their coinbase string. We have no idea what that
>> means. People are equating it to BIP 91 -- but BIP 91 did not exist at
>> the time of the New York agreement, and differs from the actual text
>> of the NYA in substantive ways. The "Segwit2MB" that existed at the
>> time of the NYA, and which was explicitly referenced by the text is
>> the proposal by Sergio Demian Lerner that was made to this mailing
>> list on 31 March. The text of the NYA grants no authority for
>> upgrading this proposal while remaining compliant with the agreement.
>> This is without even considering the fact that in the days after the
>> NYA there was disagreement among those who signed it as to what it
>> meant.
>>
>> I feel it is a very dangerous and unwarranted assumption people are
>> making that what we are seeing now is either 80% support for BIP-91 or
>> for the code in the btc1 repo.
>>
>> On Tue, Jun 20, 2017 at 6:36 PM, Erik Aronesty <erik@q32.com> wrote:
>> > # Jacob Eliosoff:
>> >
>> >>  will start orphaning non-bit-1 blocks before Aug 1, and we avoid a
>> split.
>> >
>> > Correct.  There are 2 short activation periods in BIP91 either of whic=
h
>> > would avoid a split.
>> >
>> > # Gregory Maxwell:
>> >
>> >> unclear to me _exactly_ what it would need to implement to be
>> consistent.
>> >
>> > This is the relevant pull req to core:
>> >
>> > https://github.com/bitcoin/bitcoin/pull/10444
>> >
>> > Seems OK.  It's technically running now on testnet5.   I think it (or =
a
>> > -bip148 option) should be merged as soon as feasible.
>> >
>> >> previously debunked "XT" and "Classic" hysteria.
>> >
>> > apples vs oranges, imo.   segwit is not a contentious feature.   the
>> > "bundling" in segwit2x is, but that's not the issue here.   the issue
>> is we
>> > are indirectly requiring miners that strongly support segwit to instal=
l
>> > consensus protocol changes outside of bitcoin's standard reference.
>>  80% of
>> > them have signaled they will do so.   these are uncharted waters.
>> >
>> >
>> > On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff via bitcoin-dev
>> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>
>> >> I could be wrong, but the latest BIP91 implementation (also included =
in
>> >> Segwit2x) cuts the activation period to 336 blocks (2.33 days).  (Thi=
s
>> has
>> >> been updated at
>> >> https://github.com/bitcoin/bips/blob/master/bip-0091.mediawiki.)  So
>> if 80%
>> >> of hashpower is actually running that code and signaling on bit 4 by
>> July 25
>> >> or so, then those 80+% will start orphaning non-bit-1 blocks before
>> Aug 1,
>> >> and we avoid a split.
>> >>
>> >> There may still be a few non-bit-1 blocks that get orphaned after Aug
>> 1,
>> >> because they're mined by old BIP141 nodes.  But it seems like very fe=
w
>> >> miners won't be signaling either Segwit2x *or* BIP141 by then...
>> >>
>> >> Make sense?
>> >>
>> >>
>> >> On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach <
>> mark@friedenbach.org>
>> >> wrote:
>> >>>
>> >>> Why do you say activation by August 1st is likely? That would requir=
e
>> an
>> >>> entire difficulty adjustment period with >=3D95% bit1 signaling. Tha=
t
>> seems a
>> >>> tall order to organize in the scant few weeks remaining.
>> >>>
>> >>> On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev
>> >>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>>
>> >>> If segwit is activated before Aug 1, as now seems likely, there will
>> be
>> >>> no split that day.  But if activation is via Segwit2x (also likely),
>> and at
>> >>> least some nodes do & some don't follow through with the HF 3mo late=
r
>> >>> (again, likely), agreed w/ Greg that *then* we'll see a split -
>> probably in
>> >>> Sep/Oct.  How those two chains will match up and how the split will
>> play out
>> >>> is anyone's guess...
>> >>>
>> >>>
>> >>>
>> >>> On Jun 20, 2017 6:16 PM, "Hampus Sj=C3=B6berg via bitcoin-dev"
>> >>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>>
>> >>> > Ironically, it looks like most of the segwit2x signaling miners ar=
e
>> >>> > 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 the=
m
>> >>>> at least soft-fork compatible with BIP148 and BIP91 (and god knows
>> >>>> what "segwit2x" is since they keep changing the actual definition a=
nd
>> >>>> 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 th=
e
>> >>>> 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
>> temporary.
>> >>>> > 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-- s=
o
>> I
>> >>>> don't think that holds.
>> >>>> _______________________________________________
>> >>>> bitcoin-dev mailing list
>> >>>> bitcoin-dev@lists.linuxfoundation.org
>> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> bitcoin-dev mailing list
>> >>> bitcoin-dev@lists.linuxfoundation.org
>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> bitcoin-dev mailing list
>> >>> bitcoin-dev@lists.linuxfoundation.org
>> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev@lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>
>> >
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--94eb2c0454fa16d4d10552f2eeb1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Currently the only implementation that fulfills the requir=
ements of the NYA agreement is the segwit2x/btc1 implementation, which is b=
eing finalized this week.=C2=A0<div><br></div><div>Segwit2mb does not fulfi=
ll the NYA agreement.=C2=A0<div><br></div><div>I&#39;m asking now the segwi=
t2x development team when a BIP will be ready so that Core has the opportun=
ity to evaluate the technical proposal.=C2=A0</div><div><br></div><div><br>=
<div><div><br></div></div></div></div></div><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">On Wed, Jun 21, 2017 at 1:05 AM, Jacob Eliosoff =
via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org=
</a>&gt;</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">W=
ell, this Saturday&#39;s &quot;Chinese roundtable&quot; statement from a bu=
nch of miners=C2=A0(<a href=3D"https://pastebin.com/b3St9VCF" target=3D"_bl=
ank">https://pastebin.com/<wbr>b3St9VCF</a>) says they intend &quot;NYA&quo=
t; in the coinbase as support for &quot;the New York consensus SegWit2x pro=
gram btc1 (<a href=3D"https://github.com/btc1" target=3D"_blank">https://gi=
thub.com/btc1</a>)&quot;, whose code includes the (accelerated 336-block) B=
IP 91 change.=C2=A0 So, other facts or interpretations could come to light,=
 but until they do we should probably assume that&#39;s what the &quot;NYA&=
quot; (which just broke 80% over the last 24h) means.<div><br></div></div><=
div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On Tue, Jun 20, 2017 at 10:11 PM, Mark Friedenbach <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:mark@friedenbach.org" target=3D"_blan=
k">mark@friedenbach.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">80% have set &quot;NYA&quot; in their coinbase string. We have no idea=
 what that<br>
means. People are equating it to BIP 91 -- but BIP 91 did not exist at<br>
the time of the New York agreement, and differs from the actual text<br>
of the NYA in substantive ways. The &quot;Segwit2MB&quot; that existed at t=
he<br>
time of the NYA, and which was explicitly referenced by the text is<br>
the proposal by Sergio Demian Lerner that was made to this mailing<br>
list on 31 March. The text of the NYA grants no authority for<br>
upgrading this proposal while remaining compliant with the agreement.<br>
This is without even considering the fact that in the days after the<br>
NYA there was disagreement among those who signed it as to what it<br>
meant.<br>
<br>
I feel it is a very dangerous and unwarranted assumption people are<br>
making that what we are seeing now is either 80% support for BIP-91 or<br>
for the code in the btc1 repo.<br>
<div class=3D"m_7368660441183520488HOEnZb"><div class=3D"m_7368660441183520=
488h5"><br>
On Tue, Jun 20, 2017 at 6:36 PM, Erik Aronesty &lt;<a href=3D"mailto:erik@q=
32.com" target=3D"_blank">erik@q32.com</a>&gt; wrote:<br>
&gt; # Jacob Eliosoff:<br>
&gt;<br>
&gt;&gt;=C2=A0 will start orphaning non-bit-1 blocks before Aug 1, and we a=
void a split.<br>
&gt;<br>
&gt; Correct.=C2=A0 There are 2 short activation periods in BIP91 either of=
 which<br>
&gt; would avoid a split.<br>
&gt;<br>
&gt; # Gregory Maxwell:<br>
&gt;<br>
&gt;&gt; unclear to me _exactly_ what it would need to implement to be cons=
istent.<br>
&gt;<br>
&gt; This is the relevant pull req to core:<br>
&gt;<br>
&gt; <a href=3D"https://github.com/bitcoin/bitcoin/pull/10444" rel=3D"noref=
errer" target=3D"_blank">https://github.com/bitcoin/bit<wbr>coin/pull/10444=
</a><br>
&gt;<br>
&gt; Seems OK.=C2=A0 It&#39;s technically running now on testnet5.=C2=A0 =
=C2=A0I think it (or a<br>
&gt; -bip148 option) should be merged as soon as feasible.<br>
&gt;<br>
&gt;&gt; previously debunked &quot;XT&quot; and &quot;Classic&quot; hysteri=
a.<br>
&gt;<br>
&gt; apples vs oranges, imo.=C2=A0 =C2=A0segwit is not a contentious featur=
e.=C2=A0 =C2=A0the<br>
&gt; &quot;bundling&quot; in segwit2x is, but that&#39;s not the issue here=
.=C2=A0 =C2=A0the issue is we<br>
&gt; are indirectly requiring miners that strongly support segwit to instal=
l<br>
&gt; consensus protocol changes outside of bitcoin&#39;s standard reference=
.=C2=A0 =C2=A080% of<br>
&gt; them have signaled they will do so.=C2=A0 =C2=A0these are uncharted wa=
ters.<br>
&gt;<br>
&gt;<br>
&gt; On Tue, Jun 20, 2017 at 6:57 PM, Jacob Eliosoff via bitcoin-dev<br>
&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I could be wrong, but the latest BIP91 implementation (also includ=
ed in<br>
&gt;&gt; Segwit2x) cuts the activation period to 336 blocks (2.33 days).=C2=
=A0 (This has<br>
&gt;&gt; been updated at<br>
&gt;&gt; <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0091.me=
diawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bitcoin/bi=
p<wbr>s/blob/master/bip-0091.mediawi<wbr>ki</a>.)=C2=A0 So if 80%<br>
&gt;&gt; of hashpower is actually running that code and signaling on bit 4 =
by July 25<br>
&gt;&gt; or so, then those 80+% will start orphaning non-bit-1 blocks befor=
e Aug 1,<br>
&gt;&gt; and we avoid a split.<br>
&gt;&gt;<br>
&gt;&gt; There may still be a few non-bit-1 blocks that get orphaned after =
Aug 1,<br>
&gt;&gt; because they&#39;re mined by old BIP141 nodes.=C2=A0 But it seems =
like very few<br>
&gt;&gt; miners won&#39;t be signaling either Segwit2x *or* BIP141 by then.=
..<br>
&gt;&gt;<br>
&gt;&gt; Make sense?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Tue, Jun 20, 2017 at 6:48 PM, Mark Friedenbach &lt;<a href=3D"m=
ailto:mark@friedenbach.org" target=3D"_blank">mark@friedenbach.org</a>&gt;<=
br>
&gt;&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Why do you say activation by August 1st is likely? That would =
require an<br>
&gt;&gt;&gt; entire difficulty adjustment period with &gt;=3D95% bit1 signa=
ling. That seems a<br>
&gt;&gt;&gt; tall order to organize in the scant few weeks remaining.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Jun 20, 2017, at 3:29 PM, Jacob Eliosoff via bitcoin-dev<br=
>
&gt;&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<=
br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; If segwit is activated before Aug 1, as now seems likely, ther=
e will be<br>
&gt;&gt;&gt; no split that day.=C2=A0 But if activation is via Segwit2x (al=
so likely), and at<br>
&gt;&gt;&gt; least some nodes do &amp; some don&#39;t follow through with t=
he HF 3mo later<br>
&gt;&gt;&gt; (again, likely), agreed w/ Greg that *then* we&#39;ll see a sp=
lit - probably in<br>
&gt;&gt;&gt; Sep/Oct.=C2=A0 How those two chains will match up and how the =
split will play out<br>
&gt;&gt;&gt; is anyone&#39;s guess...<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Jun 20, 2017 6:16 PM, &quot;Hampus Sj=C3=B6berg via bitcoin=
-dev&quot;<br>
&gt;&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wrote:<=
br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &gt; Ironically, it looks like most of the segwit2x signaling =
miners are<br>
&gt;&gt;&gt; &gt; faking it (because they&#39;re not signaling segwit which=
 it requires).<br>
&gt;&gt;&gt; &gt; It&#39;ll be unfortunate if some aren&#39;t faking it and=
 start orphaning<br>
&gt;&gt;&gt; &gt; their own blocks because they are failing to signal segwi=
t.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Well, they&#39;re doing some kind of &quot;pre-signaling&quot;=
 in the coinbase at the<br>
&gt;&gt;&gt; moment, because the segwit2x project is still in alpha-phase a=
ccording to<br>
&gt;&gt;&gt; the timeline. They&#39;re just showing commitment.<br>
&gt;&gt;&gt; I&#39;m sure they will begin signaling on version bit 4/BIP91 =
as well as<br>
&gt;&gt;&gt; actually running a segwit2x node when the time comes.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &gt; As far as prevent a chain split goes, all those things<br=
>
&gt;&gt;&gt; &gt; (148/91/segwit2x(per today)) effectively guarantee a chai=
nsplit-- so I<br>
&gt;&gt;&gt; &gt; don&#39;t think that holds.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Segwit2x/BIP91/BIP148 will orphan miners that do not run a Seg=
wit2x (or<br>
&gt;&gt;&gt; BIP148) node, because they wouldn&#39;t have the new consensus=
 rule of requiring<br>
&gt;&gt;&gt; all blocks to signal for segwit.<br>
&gt;&gt;&gt; I don&#39;t believe there would be any long lasting chainsplit=
 though<br>
&gt;&gt;&gt; (because of the ~80% hashrate support on segwit2x), perhaps 2-=
3 blocks if we<br>
&gt;&gt;&gt; get unlucky.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Hampus<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; 2017-06-20 23:49 GMT+02:00 Gregory Maxwell via bitcoin-dev<br>
&gt;&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt;:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Tue, Jun 20, 2017 at 3:44 PM, Erik Aronesty via bitcoin=
-dev<br>
&gt;&gt;&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wro=
te:<br>
&gt;&gt;&gt;&gt; &gt; Because a large percentage of miners are indifferent,=
 right now miners<br>
&gt;&gt;&gt;&gt; &gt; have<br>
&gt;&gt;&gt;&gt; &gt; to choose between BIP148 and Segwit2x if they want to=
 activate Segwit.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Miners can simply continuing signaling segwit, which will =
leave them<br>
&gt;&gt;&gt;&gt; at least soft-fork compatible with BIP148 and BIP91 (and g=
od knows<br>
&gt;&gt;&gt;&gt; what &quot;segwit2x&quot; is since they keep changing the =
actual definition and<br>
&gt;&gt;&gt;&gt; do not have a specification; but last I saw the near-term =
behavior the<br>
&gt;&gt;&gt;&gt; same as BIP91 but with a radically reduced activation wind=
ow, so the<br>
&gt;&gt;&gt;&gt; story would be the same there in the near term).<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Ironically, it looks like most of the segwit2x signaling m=
iners are<br>
&gt;&gt;&gt;&gt; faking it (because they&#39;re not signaling segwit which =
it requires).<br>
&gt;&gt;&gt;&gt; It&#39;ll be unfortunate if some aren&#39;t faking it and =
start orphaning<br>
&gt;&gt;&gt;&gt; their own blocks because they are failing to signal segwit=
.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I don&#39;t think the rejection of segwit2x from Bitcoin&#=
39;s developers<br>
&gt;&gt;&gt;&gt; could be any more resolute than what we&#39;ve already see=
n:<br>
&gt;&gt;&gt;&gt; <a href=3D"https://en.bitcoin.it/wiki/Segwit_support" rel=
=3D"noreferrer" target=3D"_blank">https://en.bitcoin.it/wiki/Seg<wbr>wit_su=
pport</a><br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Tue, Jun 20, 2017 at 5:22 PM, Mark Friedenbach via bitc=
oin-dev<br>
&gt;&gt;&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.or=
g" target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt; wro=
te:<br>
&gt;&gt;&gt;&gt; &gt; I think it is very na=C3=AFve to assume that any shif=
t would be temporary.<br>
&gt;&gt;&gt;&gt; &gt; We have a hard enough time getting miners to proactiv=
ely upgrade to<br>
&gt;&gt;&gt;&gt; &gt; recent versions of the reference bitcoin daemon. If m=
iners interpret<br>
&gt;&gt;&gt;&gt; &gt; the situation as being forced to run non-reference so=
ftware in order<br>
&gt;&gt;&gt;&gt; &gt; to prevent a chain split because a lack of support fr=
om Bitcoin Core,<br>
&gt;&gt;&gt;&gt; &gt; that could be a one-way street.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I think this is somewhat naive and sounds a lot like the r=
epeat of the<br>
&gt;&gt;&gt;&gt; previously debunked &quot;XT&quot; and &quot;Classic&quot;=
 hysteria.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; There is a reason that segwit2x is pretty much unanimously=
 rejected by<br>
&gt;&gt;&gt;&gt; the technical community.=C2=A0 And just like with XT/Class=
ic/Unlimited<br>
&gt;&gt;&gt;&gt; you&#39;ll continue to see a strong correlation with peopl=
e who are<br>
&gt;&gt;&gt;&gt; unwilling and unable to keep updating the software at an a=
cceptable<br>
&gt;&gt;&gt;&gt; level of quality-- esp. because the very founding on their=
 fork is<br>
&gt;&gt;&gt;&gt; predicated on discarding those properties.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; If miners want to go off and create an altcoin-- welp, tha=
ts something<br>
&gt;&gt;&gt;&gt; they can always do,=C2=A0 and nothing about that will forc=
e anyone to go<br>
&gt;&gt;&gt;&gt; along with it.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; As far as prevent a chain split goes, all those things<br>
&gt;&gt;&gt;&gt; (148/91/segwit2x(per today)) effectively guarantee a chain=
split-- so I<br>
&gt;&gt;&gt;&gt; don&#39;t think that holds.<br>
&gt;&gt;&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
&gt;&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listi=
nfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfo=
undation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/=
bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfounda=
tion.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
&gt;&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/=
bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfounda=
tion.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; bitcoin-dev mailing list<br>
&gt;&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D=
"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
&gt;&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitc=
oin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation=
.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
&gt;&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></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>

--94eb2c0454fa16d4d10552f2eeb1--