summaryrefslogtreecommitdiff
path: root/bb/3cc9f6ed516cd403a952efa19c9955da37f280
blob: 6995616a5d0419c31dc2603a1fc246c752dd531d (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
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3BD069C
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  2 Jun 2017 20:04:29 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f182.google.com (mail-qt0-f182.google.com
	[209.85.216.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E70E118F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  2 Jun 2017 20:04:26 +0000 (UTC)
Received: by mail-qt0-f182.google.com with SMTP id w1so40181399qtg.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 02 Jun 2017 13:04:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to; bh=ImogCVZ35DKetv7kAdzVCh5QcAbFWR2Dp7eNeVxyrDo=;
	b=gJqgK4DxFzzcX64QrmaUR1rkeCkcjSrNqpXXPdffSGb449e2zykVhBIWe66ROewy+g
	PQ1M8hfttLOqzhuxEizE6Hjvs+rz8Pn22qC7iWvmuE9GrAv75Xg1t83PVgxtFJ+6M7w3
	U2CbBtM/S9XzAXmcUG86QRVR+tB/Evp2/qMTOBMdJkCqa/ckjSLnF1XTBqys5wXU8Q/+
	Y8xcK511eIQeiPcxYoP6EgwJEbKXflhvpSO0vRVvt55u2smltLssMhEkldTrzPWCe7Vy
	YS8xrNFv9XhTQSl6Uh/ckkFpP5Z3ONGxF3SDfX3T/MkDP5v5/putsAyzkIVIQrAaCNP+
	6mnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to;
	bh=ImogCVZ35DKetv7kAdzVCh5QcAbFWR2Dp7eNeVxyrDo=;
	b=VE9OfDegds2P7aisyRJx+8XuRbjY+0Z4k7+yZE+9LTtWROycW7zgE8iCuOvArwBbye
	A7h2gpArd3bmhvR/214rwfEqtzU/K2pPiNTxhR8qyRkodIMnW3xr1UcdI64PWTj+gYG7
	i1ZxfdiO0OC/1QyQUdwdiJ+YuRGF4Z0aNu6pbVuskKdQF2/vyLPhK3lLmGkuk9TwuMqc
	VeR/ibS19G7WytOYhhNjg3fiR4z3uovXXJ73X9jtxfqnsQGR/juIo33NKhxeAOX3TdmB
	nvFHyr/ltRxX5/pkhdfnFb3YAQOS7+2makWATXgj9D5MbZvF9itd673IqAWpeuIgk9wU
	qokA==
X-Gm-Message-State: AODbwcAhuXU5kP5s3cHQpy+//TGw//c0r6OjSmYuUhaf8iJ9d3GwAExX
	5VTTn4Xm5IlVWUjlOKAnKpDHkLxICg==
X-Received: by 10.237.62.115 with SMTP id m48mr10636824qtf.179.1496433866048; 
	Fri, 02 Jun 2017 13:04:26 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.237.48.102 with HTTP; Fri, 2 Jun 2017 13:04:25 -0700 (PDT)
In-Reply-To: <CABm2gDrAHo2P7t6SjituURqMUqs_=Lbp7X=g_j8nGoNKMKCRKQ@mail.gmail.com>
References: <CAKzdR-oN6tGvGSb04_awCf=Jsf3wgKJN5xUhCr8G2D2W9YgJww@mail.gmail.com>
	<1CF1FD5D-8D29-4783-823F-B3F588D5C5CE@mattcorallo.com>
	<CAD1TkXse5O6nEw9-EPsNp4c56YJ+OnM=F1uf8w+tyB=_+hFzFQ@mail.gmail.com>
	<CAKzdR-rFJNOZ856rA_q8C=zEUj_X561OSOwW+KZr4nRJ51w3HA@mail.gmail.com>
	<CABm2gDrAHo2P7t6SjituURqMUqs_=Lbp7X=g_j8nGoNKMKCRKQ@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Fri, 2 Jun 2017 16:04:25 -0400
X-Google-Sender-Auth: vJO3WQP5GupYyWfgjpiG5YCiIBA
Message-ID: <CAJowKg+aYUCgBu0nD9U63jm2SunGeqdqOwiMgnTSfE9JmNJAQw@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a1140c9a6040d930550ffa95b"
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
	RCVD_IN_SORBS_SPAM 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: Fri, 02 Jun 2017 21:26:41 +0000
Subject: Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For
	Comments
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: Fri, 02 Jun 2017 20:04:29 -0000

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

From me to you ...this proposal doesn't lock in anything.   We could just
merge it with some small pushback - allow segwit to activate in Aug, then
"upgrade" the hard fork to be "spoonet in 18 months" instead.

On Sat, Apr 1, 2017 at 8:33 AM, Jorge Tim=C3=B3n via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Segwit replaces the 1 mb size limit with a weight limit of 4 mb. After
> segwit there's no need for MAX_BLOCK_BASE_SIZE anymore, let alone
> MAX_BLOCK2_BASE_SIZE.
> Thus, by "hf to 2 mb" it seems you just really mean hardforking from 4
> mb weight to 8 mb weight.
>
> I would also use the hardfork bit (sign bit in block.nNersion) as matt
> comments.
>
> > We're in a deadlock and it seems we can't go forward adding more
> functionality to segwit without the community approval (which include
> miners). This is obvious to me.Then we have to go back.
>
> If segwit is controversial the way it is (I still don't understand why
> despite having insistently asking to users and miners who claim to
> oppose it), adding more consensus rule changes won't make it any less
> controversial. If anything, it would be removing consensus rule
> changes, not adding them that could make it less controversial.
>
> By no means I want to dissuade you from working on this bip proposal,
> but I really don't see how it helps getting out of the deadlock at
> all.
>
>
> On Sat, Apr 1, 2017 at 1:44 PM, Sergio Demian Lerner via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Some people have asked me for the current implementation of this patch =
to
> > review. I remind you that the current patch does not implement the
> hard-fork
> > signaling, as requested by Matt.
> >
> > The Segwit2Mb patch can be found here:
> > https://github.com/SergioDemianLerner/bitcoin/commits/master
> >
> > For now, the segwit2mb repo has a single test file using the old intern=
al
> > blockchain building method (test/block_size_tests.cpp). This must be
> > replaced soon with a better external test using the bitcoin/qa/rpc-test=
s
> > tests, which I will begin to work on now after I collect all comments
> from
> > the community.
> >
> >
> > regards
> >
> >
> >
> > On Sat, Apr 1, 2017 at 3:55 AM, Jared Lee Richardson <jaredr26@gmail.co=
m
> >
> > wrote:
> >>
> >> > Remember that the "hashpower required to secure bitcoin" is determin=
ed
> >> > as a percentage of total Bitcoins transacted on-chain in each block
> >>
> >> Can you explain this statement a little better?  What do you mean by
> >> that?  What does the total bitcoins transacted have to do with
> >> hashpower required?
> >>
> >>
> >> On Fri, Mar 31, 2017 at 2:22 PM, Matt Corallo via bitcoin-dev
> >> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >> > Hey Sergio,
> >> >
> >> > You appear to have ignored the last two years of Bitcoin hardfork
> >> > research and understanding, recycling instead BIP 102 from 2015. The=
re
> >> > are many proposals which have pushed the state of hard fork research
> >> > much further since then, and you may wish to read some of the posts =
on
> >> > this mailing list listed at https://bitcoinhardforkresearch.
> github.io/
> >> > and make further edits based on what you learn. Your goal of "avoid
> >> > technical changes" appears to not have any basis outside of perceive=
d
> >> > compromise for compromise sake, only making such a hardfork riskier
> >> > instead.
> >> >
> >> > At a minimum, in terms of pure technical changes, you should probabl=
y
> >> > consider (probably among others):
> >> >
> >> > a) Utilizing the "hard fork signaling bit" in the nVersion of the
> block.
> >> > b) Either limiting non-SegWit transactions in some way to fix the n*=
*2
> >> > sighash and FindAndDelete runtime and memory usage issues or fix the=
m
> by
> >> > utilizing the new sighash type which many wallets and projects have
> >> > already implemented for SegWit in the spending of non-SegWit outputs=
.
> >> > c) Your really should have replay protection in any HF. The clever f=
ix
> >> > from
> >> > Spoonnet for poor scaling of optionally allowing non-SegWit outputs =
to
> >> > be spent with SegWit's sighash provides this all in one go.
> >> > d) You may wish to consider the possibility of tweaking the witness
> >> > discount and possibly discounting other parts of the input - SegWit
> went
> >> > a long ways towards making removal of elements from the UTXO set
> cheaper
> >> > than adding them, but didn't quite get there, you should probably
> finish
> >> > that job. This also provides additional tuneable parameters to allow
> you
> >> > to increase the block size while not having a blowup in the worst-ca=
se
> >> > block size.
> >> > e) Additional commitments at the top of the merkle root - both for
> >> > SegWit transactions and as additional space for merged mining and
> other
> >> > commitments which we may wish to add in the future, this should like=
ly
> >> > be implemented an "additional header" ala Johnson Lau's Spoonnet
> >> > proposal.
> >> >
> >> > Additionally, I think your parameters here pose very significant ris=
k
> to
> >> > the Bitcoin ecosystem broadly.
> >> >
> >> > a) Activating a hard fork with less than 18/24 months (and even
> then...)
> >> > from a fully-audited and supported release of full node software to
> >> > activation date poses significant risks to many large software
> projects
> >> > and users. I've repeatedly received feedback from various folks that=
 a
> >> > year or more is likely required in any hard fork to limit this risk,
> and
> >> > limited pushback on that given the large increase which SegWit
> provides
> >> > itself buying a ton of time.
> >> >
> >> > b) Having a significant discontinuity in block size increase only
> serves
> >> > to confuse and mislead users and businesses, forcing them to rapidly
> >> > adapt to a Bitcoin which changed overnight both by hardforking, and =
by
> >> > fees changing suddenly. Instead, having the hard fork activate
> technical
> >> > changes, and then slowly increasing the block size over the followin=
g
> >> > several years keeps things nice and continuous and also keeps us fro=
m
> >> > having to revisit ye old blocksize debate again six months after
> >> > activation.
> >> >
> >> > c) You should likely consider the effect of the many technological
> >> > innovations coming down the pipe in the coming months. Technologies
> like
> >> > Lightning, TumbleBit, and even your own RootStock could significantl=
y
> >> > reduce fee pressure as transactions move to much faster and more
> >> > featureful systems.
> >> >
> >> > Commitments to aggressive hard fork parameters now may leave miners
> >> > without much revenue as far out as the next halving (which current
> >> > transaction growth trends are indicating we'd just only barely reach
> 2MB
> >> > of transaction volume, let alone if you consider the effects of user=
s
> >> > moving to systems which provide more features for Bitcoin
> transactions).
> >> > This could lead to a precipitous drop in hashrate as miners are no
> >> > longer sufficiently compensated.
> >> >
> >> > Remember that the "hashpower required to secure bitcoin" is determin=
ed
> >> > as a percentage of total Bitcoins transacted on-chain in each block,
> so
> >> > as subsidy goes down, miners need to be paid with fees, not just pri=
ce
> >> > increases. Even if we were OK with hashpower going down compared to
> the
> >> > value it is securing, betting the security of Bitcoin on its price
> >> > rising exponentially to match decreasing subsidy does not strike me
> as a
> >> > particularly inspiring tradeoff.
> >> >
> >> > There aren't many great technical solutions to some of these issues,
> as
> >> > far as I'm aware, but it's something that needs to be incredibly
> >> > carefully considered before betting the continued security of Bitcoi=
n
> on
> >> > exponential on-chain growth, something which we have historically
> never
> >> > seen.
> >> >
> >> > Matt
> >> >
> >> >
> >> > On March 31, 2017 5:09:18 PM EDT, Sergio Demian Lerner via bitcoin-d=
ev
> >> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >> >>Hi everyone,
> >> >>
> >> >>Segwit2Mb is the project to merge into Bitcoin a minimal patch that
> >> >>aims to
> >> >>untangle the current conflict between different political positions
> >> >>regarding segwit activation vs. an increase of the on-chain blockcha=
in
> >> >>space through a standard block size increase. It is not a new
> solution,
> >> >>but
> >> >>it should be seen more as a least common denominator.
> >> >>
> >> >>Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ with a 2MB
> >> >>block
> >> >>size hard-fork activated ONLY if segwit activates (95% of miners
> >> >>signaling), but at a fixed future date.
> >> >>
> >> >>The sole objective of this proposal is to re-unite the Bitcoin
> >> >>community
> >> >>and avoid a cryptocurrency split. Segwit2Mb does not aim to be best
> >> >>possible technical solution to solve Bitcoin technical limitations.
> >> >>However, this proposal does not imply a compromise to the future
> >> >>scalability or decentralization of Bitcoin, as a small increase in
> >> >>block
> >> >>size has been proven by several core and non-core developers not to
> >> >>affect
> >> >>Bitcoin value propositions.
> >> >>
> >> >>In the worst case, a 2X block size increase has much lower economic
> >> >>impact
> >> >>than the last bitcoin halving (<10%), which succeeded without proble=
m.
> >> >>
> >> >>On the other side, Segwit2Mb primary goal is to be minimalistic: in
> >> >>this
> >> >>patch some choices have been made to reduce the number of lines
> >> >>modified in
> >> >>the current Bitcoin Core state (master branch), instead of
> implementing
> >> >>the
> >> >>most elegant solution. This is because I want to reduce the time it
> >> >>takes
> >> >>for core programmers and reviewers to check the correctness of the
> >> >>code,
> >> >>and to report and correct bugs.
> >> >>
> >> >>The patch was built by forking the master branch of Bitcoin Core,
> >> >>mixing a
> >> >>few lines of code from Jeff Garzik's BIP102,  and defining a second
> >> >>versionbits activation bit (bit 2) for the combined activation.
> >> >>
> >> >>The combined activation of segwit and 2Mb hard-fork nVersion bit is =
2
> >> >>(DEPLOYMENT_SEGWIT_AND_2MB_BLOCKS).
> >> >>
> >> >>This means that segwit can still be activated without the 2MB
> hard-fork
> >> >>by
> >> >>signaling bit 1 in nVersion  (DEPLOYMENT_SEGWIT).
> >> >>
> >> >>The tentative lock-in and hard-fork dates are the following:
> >> >>
> >> >>Bit 2 signaling StartTime =3D 1493424000; // April 29th, 2017
> >> >>
> >> >>Bit 2 signaling Timeout =3D 1503964800; // August 29th, 2017
> >> >>
> >> >>HardForkTime =3D 1513209600; // Thu, 14 Dec 2017 00:00:00 GMT
> >> >>
> >> >>
> >> >>The hard-fork is conditional to 95% of the hashing power has approve=
d
> >> >>the
> >> >>segwit2mb soft-fork and the segwit soft-fork has been activated (whi=
ch
> >> >>should occur 2016 blocks after its lock-in time)
> >> >>
> >> >>For more information on how soft-forks are signaled and activated, s=
ee
> >> >>https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki
> >> >>
> >> >>This means that segwit would be activated before 2Mb: this is
> >> >>inevitable,
> >> >>as versionbits have been designed to have fixed activation periods a=
nd
> >> >>thresholds for all bits. Making segwit and 2Mb fork activate togethe=
r
> >> >>at a
> >> >>delayed date would have required a major re-write of this code, whic=
h
> >> >>would
> >> >>contradict the premise of creating a minimalistic patch. However, on=
ce
> >> >>segwit is activated, the hard-fork is unavoidable.
> >> >>
> >> >>Although I have coded a first version of the segwit2mb patch (which
> >> >>modifies 120 lines of code, and adds 220 lines of testing code), I
> >> >>would
> >> >>prefer to wait to publish the source code until more comments have
> been
> >> >>received from the community.
> >> >>
> >> >>To prevent worsening block verification time because of the O(N^2)
> >> >>hashing
> >> >>problem, the simple restriction that transactions cannot be larger
> than
> >> >>1Mb
> >> >>has been kept. Therefore the worse-case of block verification time h=
as
> >> >>only
> >> >>doubled.
> >> >>
> >> >>Regarding the hard-fork activation date, I want to give enough time =
to
> >> >>all
> >> >>active economic nodes to upgrade. As of Fri Mar 31 2017,
> >> >>https://bitnodes.21.co/nodes/ reports that 6332 out of 6955 nodes
> (91%)
> >> >>have upgraded to post 0.12 versions. Upgrade to post 0.12 versions c=
an
> >> >>be
> >> >>used to identify economic active nodes, because in the 0.12 release
> >> >>dynamic
> >> >>fees were introduced, and currently no Bitcoin automatic payment
> system
> >> >>can
> >> >>operate without automatic discovery of the current fee rate. A
> pre-0.12
> >> >>would require constant manual intervention.
> >> >>Therefore I conclude that no more than 91% of the network nodes
> >> >>reported by
> >> >>bitnodes are active economic nodes.
> >> >>
> >> >>As Bitcoin Core 0.12 was released on February 2016, the time for thi=
s
> >> >>91%
> >> >>to upgrade has been around one year (under a moderate pressure of
> >> >>operational problems with unconfirmed transactions).
> >> >>Therefore we can expect a similar or lower time to upgrade for a
> >> >>hard-fork,
> >> >>after developers have discussed and approved the patch, and it has
> been
> >> >>reviewed and merged and 95% of the hashing power has signaled for it
> >> >>(the
> >> >>pressure not to upgrade being a complete halt of the operations).
> >> >>However I
> >> >>suggest that we discuss the hard-fork date and delay it if there is =
a
> >> >>real
> >> >>need to.
> >> >>
> >> >>Currently time works against the Bitcoin community, and so is delayi=
ng
> >> >>a
> >> >>compromise solution. Most of the community agree that halting the
> >> >>innovation for several years is a very bad option.
> >> >>
> >> >>After the comments collected by the community, a BIP will be written
> >> >>describing the resulting proposal details.
> >> >>
> >> >>If segwit2mb locks-in, before hard-fork occurs all bitcoin nodes
> should
> >> >>be
> >> >>updated to a Segwit2Mb enabled node to prevent them to be forked-awa=
y
> >> >>in a
> >> >>chain with almost no hashing-power.
> >> >>
> >> >>The proof of concept patch was made for Bitcoin Core but should be
> >> >>easily
> >> >>ported to other Bitcoin protocol implementations that already suppor=
t
> >> >>versionbits. Lightweight (SPV) wallets should not be affected as the=
y
> >> >>generally do not check the block size.
> >> >>
> >> >>I personally want to see the Lightning Network in action this year,
> use
> >> >>the
> >> >>non-malleability features in segwit, see the community discussing
> other
> >> >>exciting soft-forks in the scaling roadmap, Schnorr sigs, drivechain=
s
> >> >>and
> >> >>MAST.
> >> >>
> >> >>I want to see miners, developers and industry side-by-side pushing
> >> >>Bitcoin
> >> >>forward, to increase the value of Bitcoin and prevent high transacti=
on
> >> >>fees
> >> >>to put out of business use-cases that could have high positive socia=
l
> >> >>impact.
> >> >>
> >> >>I believe in the strength of a unified Bitcoin community. If you're =
a
> >> >>developer, please give your opinion, suggest changes, audit it, and
> >> >>take a
> >> >>stand with me to unlock the current Bitcoin deadlock.
> >> >>
> >> >>Contributions to the segwit2mb project are welcomed and awaited. The
> >> >>only
> >> >>limitation is to stick to the principle that the patch should be as
> >> >>simple
> >> >>to audit as possible. As an example, I wouldn't feel confident if th=
e
> >> >>patch
> >> >>modified more than ~150 lines of code.
> >> >>
> >> >>Improvements unrelated to a 2 Mb increase or segwit, as beneficial a=
s
> >> >>it
> >> >>may be to Bitcoin, should not be part of segwit2Mb.
> >> >>
> >> >>This proposal should not prevent other consensus proposals to be
> >> >>simultaneously merged: segwit2mb is a last resort solution in case w=
e
> >> >>can
> >> >>not reach consensus on anything better.
> >> >>
> >> >>Again, the proposal is only a starting point: community feedback is
> >> >>expected and welcomed.
> >> >>
> >> >>Regards,
> >> >>Sergio Demian Lerner
> >> > _______________________________________________
> >> > 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
>

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

<div dir=3D"ltr">From me to you ...this proposal doesn&#39;t lock in anythi=
ng. =C2=A0 We could just merge it with some small pushback - allow segwit t=
o activate in Aug, then &quot;upgrade&quot; the hard fork to be &quot;spoon=
et in 18 months&quot; instead.<br></div><div class=3D"gmail_extra"><br><div=
 class=3D"gmail_quote">On Sat, Apr 1, 2017 at 8:33 AM, Jorge Tim=C3=B3n via=
 bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.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">Segwit replaces the 1=
 mb size limit with a weight limit of 4 mb. After<br>
segwit there&#39;s no need for MAX_BLOCK_BASE_SIZE anymore, let alone<br>
MAX_BLOCK2_BASE_SIZE.<br>
Thus, by &quot;hf to 2 mb&quot; it seems you just really mean hardforking f=
rom 4<br>
mb weight to 8 mb weight.<br>
<br>
I would also use the hardfork bit (sign bit in block.nNersion) as matt comm=
ents.<br>
<span class=3D""><br>
&gt; We&#39;re in a deadlock and it seems we can&#39;t go forward adding mo=
re functionality to segwit without the community approval (which include mi=
ners). This is obvious to me.Then we have to go back.<br>
<br>
</span>If segwit is controversial the way it is (I still don&#39;t understa=
nd why<br>
despite having insistently asking to users and miners who claim to<br>
oppose it), adding more consensus rule changes won&#39;t make it any less<b=
r>
controversial. If anything, it would be removing consensus rule<br>
changes, not adding them that could make it less controversial.<br>
<br>
By no means I want to dissuade you from working on this bip proposal,<br>
but I really don&#39;t see how it helps getting out of the deadlock at<br>
all.<br>
<br>
<br>
On Sat, Apr 1, 2017 at 1:44 PM, Sergio Demian Lerner via bitcoin-dev<br>
<div class=3D"HOEnZb"><div class=3D"h5">&lt;<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt=
; wrote:<br>
&gt; Some people have asked me for the current implementation of this patch=
 to<br>
&gt; review. I remind you that the current patch does not implement the har=
d-fork<br>
&gt; signaling, as requested by Matt.<br>
&gt;<br>
&gt; The Segwit2Mb patch can be found here:<br>
&gt; <a href=3D"https://github.com/SergioDemianLerner/bitcoin/commits/maste=
r" rel=3D"noreferrer" target=3D"_blank">https://github.com/<wbr>SergioDemia=
nLerner/bitcoin/<wbr>commits/master</a><br>
&gt;<br>
&gt; For now, the segwit2mb repo has a single test file using the old inter=
nal<br>
&gt; blockchain building method (test/block_size_tests.cpp). This must be<b=
r>
&gt; replaced soon with a better external test using the bitcoin/qa/rpc-tes=
ts<br>
&gt; tests, which I will begin to work on now after I collect all comments =
from<br>
&gt; the community.<br>
&gt;<br>
&gt;<br>
&gt; regards<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Sat, Apr 1, 2017 at 3:55 AM, Jared Lee Richardson &lt;<a href=3D"ma=
ilto:jaredr26@gmail.com">jaredr26@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; Remember that the &quot;hashpower required to secure bitcoin&=
quot; is determined<br>
&gt;&gt; &gt; as a percentage of total Bitcoins transacted on-chain in each=
 block<br>
&gt;&gt;<br>
&gt;&gt; Can you explain this statement a little better?=C2=A0 What do you =
mean by<br>
&gt;&gt; that?=C2=A0 What does the total bitcoins transacted have to do wit=
h<br>
&gt;&gt; hashpower required?<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Fri, Mar 31, 2017 at 2:22 PM, Matt Corallo via bitcoin-dev<br>
&gt;&gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt; &gt; Hey Sergio,<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; You appear to have ignored the last two years of Bitcoin hard=
fork<br>
&gt;&gt; &gt; research and understanding, recycling instead BIP 102 from 20=
15. There<br>
&gt;&gt; &gt; are many proposals which have pushed the state of hard fork r=
esearch<br>
&gt;&gt; &gt; much further since then, and you may wish to read some of the=
 posts on<br>
&gt;&gt; &gt; this mailing list listed at <a href=3D"https://bitcoinhardfor=
kresearch.github.io/" rel=3D"noreferrer" target=3D"_blank">https://<wbr>bit=
coinhardforkresearch.<wbr>github.io/</a><br>
&gt;&gt; &gt; and make further edits based on what you learn. Your goal of =
&quot;avoid<br>
&gt;&gt; &gt; technical changes&quot; appears to not have any basis outside=
 of perceived<br>
&gt;&gt; &gt; compromise for compromise sake, only making such a hardfork r=
iskier<br>
&gt;&gt; &gt; instead.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; At a minimum, in terms of pure technical changes, you should =
probably<br>
&gt;&gt; &gt; consider (probably among others):<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; a) Utilizing the &quot;hard fork signaling bit&quot; in the n=
Version of the block.<br>
&gt;&gt; &gt; b) Either limiting non-SegWit transactions in some way to fix=
 the n**2<br>
&gt;&gt; &gt; sighash and FindAndDelete runtime and memory usage issues or =
fix them by<br>
&gt;&gt; &gt; utilizing the new sighash type which many wallets and project=
s have<br>
&gt;&gt; &gt; already implemented for SegWit in the spending of non-SegWit =
outputs.<br>
&gt;&gt; &gt; c) Your really should have replay protection in any HF. The c=
lever fix<br>
&gt;&gt; &gt; from<br>
&gt;&gt; &gt; Spoonnet for poor scaling of optionally allowing non-SegWit o=
utputs to<br>
&gt;&gt; &gt; be spent with SegWit&#39;s sighash provides this all in one g=
o.<br>
&gt;&gt; &gt; d) You may wish to consider the possibility of tweaking the w=
itness<br>
&gt;&gt; &gt; discount and possibly discounting other parts of the input - =
SegWit went<br>
&gt;&gt; &gt; a long ways towards making removal of elements from the UTXO =
set cheaper<br>
&gt;&gt; &gt; than adding them, but didn&#39;t quite get there, you should =
probably finish<br>
&gt;&gt; &gt; that job. This also provides additional tuneable parameters t=
o allow you<br>
&gt;&gt; &gt; to increase the block size while not having a blowup in the w=
orst-case<br>
&gt;&gt; &gt; block size.<br>
&gt;&gt; &gt; e) Additional commitments at the top of the merkle root - bot=
h for<br>
&gt;&gt; &gt; SegWit transactions and as additional space for merged mining=
 and other<br>
&gt;&gt; &gt; commitments which we may wish to add in the future, this shou=
ld likely<br>
&gt;&gt; &gt; be implemented an &quot;additional header&quot; ala Johnson L=
au&#39;s Spoonnet<br>
&gt;&gt; &gt; proposal.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Additionally, I think your parameters here pose very signific=
ant risk to<br>
&gt;&gt; &gt; the Bitcoin ecosystem broadly.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; a) Activating a hard fork with less than 18/24 months (and ev=
en then...)<br>
&gt;&gt; &gt; from a fully-audited and supported release of full node softw=
are to<br>
&gt;&gt; &gt; activation date poses significant risks to many large softwar=
e projects<br>
&gt;&gt; &gt; and users. I&#39;ve repeatedly received feedback from various=
 folks that a<br>
&gt;&gt; &gt; year or more is likely required in any hard fork to limit thi=
s risk, and<br>
&gt;&gt; &gt; limited pushback on that given the large increase which SegWi=
t provides<br>
&gt;&gt; &gt; itself buying a ton of time.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; b) Having a significant discontinuity in block size increase =
only serves<br>
&gt;&gt; &gt; to confuse and mislead users and businesses, forcing them to =
rapidly<br>
&gt;&gt; &gt; adapt to a Bitcoin which changed overnight both by hardforkin=
g, and by<br>
&gt;&gt; &gt; fees changing suddenly. Instead, having the hard fork activat=
e technical<br>
&gt;&gt; &gt; changes, and then slowly increasing the block size over the f=
ollowing<br>
&gt;&gt; &gt; several years keeps things nice and continuous and also keeps=
 us from<br>
&gt;&gt; &gt; having to revisit ye old blocksize debate again six months af=
ter<br>
&gt;&gt; &gt; activation.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; c) You should likely consider the effect of the many technolo=
gical<br>
&gt;&gt; &gt; innovations coming down the pipe in the coming months. Techno=
logies like<br>
&gt;&gt; &gt; Lightning, TumbleBit, and even your own RootStock could signi=
ficantly<br>
&gt;&gt; &gt; reduce fee pressure as transactions move to much faster and m=
ore<br>
&gt;&gt; &gt; featureful systems.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Commitments to aggressive hard fork parameters now may leave =
miners<br>
&gt;&gt; &gt; without much revenue as far out as the next halving (which cu=
rrent<br>
&gt;&gt; &gt; transaction growth trends are indicating we&#39;d just only b=
arely reach 2MB<br>
&gt;&gt; &gt; of transaction volume, let alone if you consider the effects =
of users<br>
&gt;&gt; &gt; moving to systems which provide more features for Bitcoin tra=
nsactions).<br>
&gt;&gt; &gt; This could lead to a precipitous drop in hashrate as miners a=
re no<br>
&gt;&gt; &gt; longer sufficiently compensated.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Remember that the &quot;hashpower required to secure bitcoin&=
quot; is determined<br>
&gt;&gt; &gt; as a percentage of total Bitcoins transacted on-chain in each=
 block, so<br>
&gt;&gt; &gt; as subsidy goes down, miners need to be paid with fees, not j=
ust price<br>
&gt;&gt; &gt; increases. Even if we were OK with hashpower going down compa=
red to the<br>
&gt;&gt; &gt; value it is securing, betting the security of Bitcoin on its =
price<br>
&gt;&gt; &gt; rising exponentially to match decreasing subsidy does not str=
ike me as a<br>
&gt;&gt; &gt; particularly inspiring tradeoff.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; There aren&#39;t many great technical solutions to some of th=
ese issues, as<br>
&gt;&gt; &gt; far as I&#39;m aware, but it&#39;s something that needs to be=
 incredibly<br>
&gt;&gt; &gt; carefully considered before betting the continued security of=
 Bitcoin on<br>
&gt;&gt; &gt; exponential on-chain growth, something which we have historic=
ally never<br>
&gt;&gt; &gt; seen.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Matt<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On March 31, 2017 5:09:18 PM EDT, Sergio Demian Lerner via bi=
tcoin-dev<br>
&gt;&gt; &gt; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">=
bitcoin-dev@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt; &gt;&gt;Hi everyone,<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Segwit2Mb is the project to merge into Bitcoin a minimal p=
atch that<br>
&gt;&gt; &gt;&gt;aims to<br>
&gt;&gt; &gt;&gt;untangle the current conflict between different political =
positions<br>
&gt;&gt; &gt;&gt;regarding segwit activation vs. an increase of the on-chai=
n blockchain<br>
&gt;&gt; &gt;&gt;space through a standard block size increase. It is not a =
new solution,<br>
&gt;&gt; &gt;&gt;but<br>
&gt;&gt; &gt;&gt;it should be seen more as a least common denominator.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Segwit2Mb combines segwit as it is today in Bitcoin 0.14+ =
with a 2MB<br>
&gt;&gt; &gt;&gt;block<br>
&gt;&gt; &gt;&gt;size hard-fork activated ONLY if segwit activates (95% of =
miners<br>
&gt;&gt; &gt;&gt;signaling), but at a fixed future date.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;The sole objective of this proposal is to re-unite the Bit=
coin<br>
&gt;&gt; &gt;&gt;community<br>
&gt;&gt; &gt;&gt;and avoid a cryptocurrency split. Segwit2Mb does not aim t=
o be best<br>
&gt;&gt; &gt;&gt;possible technical solution to solve Bitcoin technical lim=
itations.<br>
&gt;&gt; &gt;&gt;However, this proposal does not imply a compromise to the =
future<br>
&gt;&gt; &gt;&gt;scalability or decentralization of Bitcoin, as a small inc=
rease in<br>
&gt;&gt; &gt;&gt;block<br>
&gt;&gt; &gt;&gt;size has been proven by several core and non-core develope=
rs not to<br>
&gt;&gt; &gt;&gt;affect<br>
&gt;&gt; &gt;&gt;Bitcoin value propositions.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;In the worst case, a 2X block size increase has much lower=
 economic<br>
&gt;&gt; &gt;&gt;impact<br>
&gt;&gt; &gt;&gt;than the last bitcoin halving (&lt;10%), which succeeded w=
ithout problem.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;On the other side, Segwit2Mb primary goal is to be minimal=
istic: in<br>
&gt;&gt; &gt;&gt;this<br>
&gt;&gt; &gt;&gt;patch some choices have been made to reduce the number of =
lines<br>
&gt;&gt; &gt;&gt;modified in<br>
&gt;&gt; &gt;&gt;the current Bitcoin Core state (master branch), instead of=
 implementing<br>
&gt;&gt; &gt;&gt;the<br>
&gt;&gt; &gt;&gt;most elegant solution. This is because I want to reduce th=
e time it<br>
&gt;&gt; &gt;&gt;takes<br>
&gt;&gt; &gt;&gt;for core programmers and reviewers to check the correctnes=
s of the<br>
&gt;&gt; &gt;&gt;code,<br>
&gt;&gt; &gt;&gt;and to report and correct bugs.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;The patch was built by forking the master branch of Bitcoi=
n Core,<br>
&gt;&gt; &gt;&gt;mixing a<br>
&gt;&gt; &gt;&gt;few lines of code from Jeff Garzik&#39;s BIP102,=C2=A0 and=
 defining a second<br>
&gt;&gt; &gt;&gt;versionbits activation bit (bit 2) for the combined activa=
tion.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;The combined activation of segwit and 2Mb hard-fork nVersi=
on bit is 2<br>
&gt;&gt; &gt;&gt;(DEPLOYMENT_SEGWIT_AND_2MB_<wbr>BLOCKS).<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;This means that segwit can still be activated without the =
2MB hard-fork<br>
&gt;&gt; &gt;&gt;by<br>
&gt;&gt; &gt;&gt;signaling bit 1 in nVersion=C2=A0 (DEPLOYMENT_SEGWIT).<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;The tentative lock-in and hard-fork dates are the followin=
g:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Bit 2 signaling StartTime =3D 1493424000; // April 29th, 2=
017<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Bit 2 signaling Timeout =3D 1503964800; // August 29th, 20=
17<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;HardForkTime =3D 1513209600; // Thu, 14 Dec 2017 00:00:00 =
GMT<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;The hard-fork is conditional to 95% of the hashing power h=
as approved<br>
&gt;&gt; &gt;&gt;the<br>
&gt;&gt; &gt;&gt;segwit2mb soft-fork and the segwit soft-fork has been acti=
vated (which<br>
&gt;&gt; &gt;&gt;should occur 2016 blocks after its lock-in time)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;For more information on how soft-forks are signaled and ac=
tivated, see<br>
&gt;&gt; &gt;&gt;<a href=3D"https://github.com/bitcoin/bips/blob/master/bip=
-0009.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/bi=
tcoin/<wbr>bips/blob/master/bip-0009.<wbr>mediawiki</a><br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;This means that segwit would be activated before 2Mb: this=
 is<br>
&gt;&gt; &gt;&gt;inevitable,<br>
&gt;&gt; &gt;&gt;as versionbits have been designed to have fixed activation=
 periods and<br>
&gt;&gt; &gt;&gt;thresholds for all bits. Making segwit and 2Mb fork activa=
te together<br>
&gt;&gt; &gt;&gt;at a<br>
&gt;&gt; &gt;&gt;delayed date would have required a major re-write of this =
code, which<br>
&gt;&gt; &gt;&gt;would<br>
&gt;&gt; &gt;&gt;contradict the premise of creating a minimalistic patch. H=
owever, once<br>
&gt;&gt; &gt;&gt;segwit is activated, the hard-fork is unavoidable.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Although I have coded a first version of the segwit2mb pat=
ch (which<br>
&gt;&gt; &gt;&gt;modifies 120 lines of code, and adds 220 lines of testing =
code), I<br>
&gt;&gt; &gt;&gt;would<br>
&gt;&gt; &gt;&gt;prefer to wait to publish the source code until more comme=
nts have been<br>
&gt;&gt; &gt;&gt;received from the community.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;To prevent worsening block verification time because of th=
e O(N^2)<br>
&gt;&gt; &gt;&gt;hashing<br>
&gt;&gt; &gt;&gt;problem, the simple restriction that transactions cannot b=
e larger than<br>
&gt;&gt; &gt;&gt;1Mb<br>
&gt;&gt; &gt;&gt;has been kept. Therefore the worse-case of block verificat=
ion time has<br>
&gt;&gt; &gt;&gt;only<br>
&gt;&gt; &gt;&gt;doubled.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Regarding the hard-fork activation date, I want to give en=
ough time to<br>
&gt;&gt; &gt;&gt;all<br>
&gt;&gt; &gt;&gt;active economic nodes to upgrade. As of Fri Mar 31 2017,<b=
r>
&gt;&gt; &gt;&gt;<a href=3D"https://bitnodes.21.co/nodes/" rel=3D"noreferre=
r" target=3D"_blank">https://bitnodes.21.co/<wbr>nodes/</a> reports that 63=
32 out of 6955 nodes (91%)<br>
&gt;&gt; &gt;&gt;have upgraded to post 0.12 versions. Upgrade to post 0.12 =
versions can<br>
&gt;&gt; &gt;&gt;be<br>
&gt;&gt; &gt;&gt;used to identify economic active nodes, because in the 0.1=
2 release<br>
&gt;&gt; &gt;&gt;dynamic<br>
&gt;&gt; &gt;&gt;fees were introduced, and currently no Bitcoin automatic p=
ayment system<br>
&gt;&gt; &gt;&gt;can<br>
&gt;&gt; &gt;&gt;operate without automatic discovery of the current fee rat=
e. A pre-0.12<br>
&gt;&gt; &gt;&gt;would require constant manual intervention.<br>
&gt;&gt; &gt;&gt;Therefore I conclude that no more than 91% of the network =
nodes<br>
&gt;&gt; &gt;&gt;reported by<br>
&gt;&gt; &gt;&gt;bitnodes are active economic nodes.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;As Bitcoin Core 0.12 was released on February 2016, the ti=
me for this<br>
&gt;&gt; &gt;&gt;91%<br>
&gt;&gt; &gt;&gt;to upgrade has been around one year (under a moderate pres=
sure of<br>
&gt;&gt; &gt;&gt;operational problems with unconfirmed transactions).<br>
&gt;&gt; &gt;&gt;Therefore we can expect a similar or lower time to upgrade=
 for a<br>
&gt;&gt; &gt;&gt;hard-fork,<br>
&gt;&gt; &gt;&gt;after developers have discussed and approved the patch, an=
d it has been<br>
&gt;&gt; &gt;&gt;reviewed and merged and 95% of the hashing power has signa=
led for it<br>
&gt;&gt; &gt;&gt;(the<br>
&gt;&gt; &gt;&gt;pressure not to upgrade being a complete halt of the opera=
tions).<br>
&gt;&gt; &gt;&gt;However I<br>
&gt;&gt; &gt;&gt;suggest that we discuss the hard-fork date and delay it if=
 there is a<br>
&gt;&gt; &gt;&gt;real<br>
&gt;&gt; &gt;&gt;need to.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Currently time works against the Bitcoin community, and so=
 is delaying<br>
&gt;&gt; &gt;&gt;a<br>
&gt;&gt; &gt;&gt;compromise solution. Most of the community agree that halt=
ing the<br>
&gt;&gt; &gt;&gt;innovation for several years is a very bad option.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;After the comments collected by the community, a BIP will =
be written<br>
&gt;&gt; &gt;&gt;describing the resulting proposal details.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;If segwit2mb locks-in, before hard-fork occurs all bitcoin=
 nodes should<br>
&gt;&gt; &gt;&gt;be<br>
&gt;&gt; &gt;&gt;updated to a Segwit2Mb enabled node to prevent them to be =
forked-away<br>
&gt;&gt; &gt;&gt;in a<br>
&gt;&gt; &gt;&gt;chain with almost no hashing-power.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;The proof of concept patch was made for Bitcoin Core but s=
hould be<br>
&gt;&gt; &gt;&gt;easily<br>
&gt;&gt; &gt;&gt;ported to other Bitcoin protocol implementations that alre=
ady support<br>
&gt;&gt; &gt;&gt;versionbits. Lightweight (SPV) wallets should not be affec=
ted as they<br>
&gt;&gt; &gt;&gt;generally do not check the block size.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;I personally want to see the Lightning Network in action t=
his year, use<br>
&gt;&gt; &gt;&gt;the<br>
&gt;&gt; &gt;&gt;non-malleability features in segwit, see the community dis=
cussing other<br>
&gt;&gt; &gt;&gt;exciting soft-forks in the scaling roadmap, Schnorr sigs, =
drivechains<br>
&gt;&gt; &gt;&gt;and<br>
&gt;&gt; &gt;&gt;MAST.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;I want to see miners, developers and industry side-by-side=
 pushing<br>
&gt;&gt; &gt;&gt;Bitcoin<br>
&gt;&gt; &gt;&gt;forward, to increase the value of Bitcoin and prevent high=
 transaction<br>
&gt;&gt; &gt;&gt;fees<br>
&gt;&gt; &gt;&gt;to put out of business use-cases that could have high posi=
tive social<br>
&gt;&gt; &gt;&gt;impact.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;I believe in the strength of a unified Bitcoin community. =
If you&#39;re a<br>
&gt;&gt; &gt;&gt;developer, please give your opinion, suggest changes, audi=
t it, and<br>
&gt;&gt; &gt;&gt;take a<br>
&gt;&gt; &gt;&gt;stand with me to unlock the current Bitcoin deadlock.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Contributions to the segwit2mb project are welcomed and aw=
aited. The<br>
&gt;&gt; &gt;&gt;only<br>
&gt;&gt; &gt;&gt;limitation is to stick to the principle that the patch sho=
uld be as<br>
&gt;&gt; &gt;&gt;simple<br>
&gt;&gt; &gt;&gt;to audit as possible. As an example, I wouldn&#39;t feel c=
onfident if the<br>
&gt;&gt; &gt;&gt;patch<br>
&gt;&gt; &gt;&gt;modified more than ~150 lines of code.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Improvements unrelated to a 2 Mb increase or segwit, as be=
neficial as<br>
&gt;&gt; &gt;&gt;it<br>
&gt;&gt; &gt;&gt;may be to Bitcoin, should not be part of segwit2Mb.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;This proposal should not prevent other consensus proposals=
 to be<br>
&gt;&gt; &gt;&gt;simultaneously merged: segwit2mb is a last resort solution=
 in case we<br>
&gt;&gt; &gt;&gt;can<br>
&gt;&gt; &gt;&gt;not reach consensus on anything better.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Again, the proposal is only a starting point: community fe=
edback is<br>
&gt;&gt; &gt;&gt;expected and welcomed.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt;Regards,<br>
&gt;&gt; &gt;&gt;Sergio Demian Lerner<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">bitc=
oin-dev@lists.<wbr>linuxfoundation.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.linuxfound=
ation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt;<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>
</div></div></blockquote></div><br></div>

--001a1140c9a6040d930550ffa95b--