summaryrefslogtreecommitdiff
path: root/0c/fddd44db1f040aee960b58bc09ce185fd171a2
blob: 417810242a483267102d72b9fdaf1c7934b56113 (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
Return-Path: <blinnpr@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CECAE14C5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  2 Aug 2019 16:44:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ot1-f66.google.com (mail-ot1-f66.google.com
	[209.85.210.66])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5492B7ED
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  2 Aug 2019 16:44:16 +0000 (UTC)
Received: by mail-ot1-f66.google.com with SMTP id o101so78761331ota.8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 02 Aug 2019 09:44:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=0WpwRIjyj+DZ+h4xzh6nsG5XDQiJEqjdPMaeIQovEmI=;
	b=LYzQaeC9CAPdiTqbw70NAn2RtYg4+YVW/JUmgoKeM3NX+V0NXrPsSf3TeWXGxV4chc
	jzckJpFU7mXNTKe9N5iW0m+tYaSp3KC0R8qpQ7xkGheLNYmP7Q7D5Mh6Y0iO3MnMcgJi
	uhV3cD4lZFHr8sGIYhk2timyDDW94NIKFh0L6PG9aLoHSFm86+vZMmWxw/by8/iGxaLy
	qS2lCZCEkvVjfiSaSHeClnGVFerYAuj0X7YLEooO9IdCtcX6jQP/W7BirEvW+qh9sbcS
	hlr2fDHrUmq8WndAQbbZmf88J3yB55k2OoCDfyQh3p818vAYfMS8w3q+cei7anaWY4s7
	ygRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=0WpwRIjyj+DZ+h4xzh6nsG5XDQiJEqjdPMaeIQovEmI=;
	b=P/sCZHki4Rzhab3Ri8XERaQ35W2HMRI6mt08N+RJBV6LC0K39AZR5Bq7C4sI9V9/jz
	ALwTk7WToGWYTv9QFUlqose/+BFeg+VB7tqLnFpIP2N7r2ZyezVcacovs5WiFK274EHm
	eRSb2yuR+IAe5v2M5BZLeBPRzncQYpVi6cydZ/n4TDRf1h1UaJkDFGcs8xpLhdEG3AD0
	FRtgsOVLFQkGpp/Ehi8lJQ6M/u+Y4pgZxhOUSLdAmO0yo8nmBmz7OLhqukroTRQi5B7U
	kzTFJoqiY+L5DXh/rE7j0S2vB6pC+fpah/kmiVMbI85s2UELKDLVYvaxKwnMpi7AE0dC
	pRJA==
X-Gm-Message-State: APjAAAXg0x9E28NpF3M+4HuhsHA5rdYyTc3B/uE3/ValB32vcfyKudVS
	5OHdKZWYtw4yMKv5OUlAr6P9LAOJYZxKgB0v7ytv1x8lipg=
X-Google-Smtp-Source: APXvYqzNEBNgJ9Qr7ysHdWVA0hhYGxBt9yE2FF6G/r4wqkvYtxpq73V+PX7lAPiuYnx5syb6DMEbr9FBeXheCNLv7sw=
X-Received: by 2002:a9d:6194:: with SMTP id g20mr30796385otk.149.1564764254981;
	Fri, 02 Aug 2019 09:44:14 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.712.1564748374.27056.bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <mailman.712.1564748374.27056.bitcoin-dev@lists.linuxfoundation.org>
From: Steven Blinn <blinnpr@gmail.com>
Date: Fri, 2 Aug 2019 12:44:01 -0400
Message-ID: <CAEV=t-Bgyd2kdzfmspPb+Jn2M-FcBGcK1ppM7g0JPALx9m_uAw@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="00000000000093533f058f2511b1"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE 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: Sat, 03 Aug 2019 02:25:02 +0000
Subject: Re: [bitcoin-dev] bitcoin-dev Digest, Vol 51, Issue 3
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 Aug 2019 16:44:18 -0000

--00000000000093533f058f2511b1
Content-Type: text/plain; charset="UTF-8"

Emil,

Re: [Meta] bitcoin-dev moderation (Emil Engler)

Since my coding skills are in the infancy stage and I can't contribute much
in that area, at least not yet, I'm looking for other ways to get involved
and moderating the mailing list sounds like an ideal situation.  If you
need help in this area I'm more than happy to volunteer and pick up the
slack.

Steven

On Fri, Aug 2, 2019 at 8:50 AM <
bitcoin-dev-request@lists.linuxfoundation.org> wrote:

> Send bitcoin-dev mailing list submissions to
>         bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
>         bitcoin-dev-request@lists.linuxfoundation.org
>
> You can reach the person managing the list at
>         bitcoin-dev-owner@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
>    1. [Meta] bitcoin-dev moderation (Emil Engler)
>    2. Re: Improving JoinMarket's resistance to sybil attacks using
>       fidelity bonds (Chris Belcher)
>    3. Re: Proposed Extensions to BIP 174 for Future Extensibility
>       (Dmitry Petukhov)
>    4. Re: [Meta] bitcoin-dev moderation (Bryan Bishop)
>    5. Re: Add a moving checkpoint to the Bitcoin protocol
>       (Ethan Heilman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 1 Aug 2019 21:47:40 +0200
> From: Emil Engler <me@emilengler.com>
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: [bitcoin-dev] [Meta] bitcoin-dev moderation
> Message-ID: <53b75074-59ff-9890-419d-d5e6fcb44a7c@emilengler.com>
> Content-Type: text/plain; charset="utf-8"
>
> In the last #bitcoin-core-dev IRC meeting, the mailing list moderation
> was slightly discussed. It was decided to do this discussion mainly on
> this mailing list (which makes sense).
>
> The current situation is that the moderation is slow and takes around
> >24h for a E-Mail to be on the mailing list.
>
> Jonas Schnelli proposed: "I propose that we add more moderators to
> shorten the moderation lag which has been between >24h, thus makes
> debates cumbersome"
>
> Beside this I had the idea of people who already contributed n e-mails
> to the mailing list don't need an approval for any e-mail anymore (Where
> n is the number of previous e-mails). Does this exists already?
>
> Greetings,
> Emil Engler
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: pEpkey.asc
> Type: application/pgp-keys
> Size: 3147 bytes
> Desc: not available
> URL: <
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190801/a78795b7/attachment-0001.bin
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 2 Aug 2019 10:21:57 +0100
> From: Chris Belcher <belcher@riseup.net>
> To: Dmitry Petukhov <dp@simplexum.com>,
>         bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil
>         attacks using fidelity bonds
> Message-ID: <ae32dcbb-c950-3b3f-22b9-d152d6b221cb@riseup.net>
> Content-Type: text/plain; charset=utf-8
>
> On 31/07/2019 16:50, Dmitry Petukhov wrote:
> > ? Tue, 30 Jul 2019 22:39:14 +0100
> > Chris Belcher via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> > wrote:
> >
> >> This is where a sacrifice of V bitcoins creates a
> >> bond of value V^2. The formula provides a strong incentive for
> >> profit-motivated makers to use all their fidelity bond coins with just
> >> one maker, not spread them out over many makers.
> >
> > The attacker derives additional value from the use of
> > locked utxo - the deanonimyzation capabilities.
> >
> > An entity M can use all of its locked coins to run a maker, and then
> > earn value X. It will also incur some operational expenses in the course
> > of running the maker, so the profit will be less than X.
> >
> > If these locked coins are given to the attacker A as a package, an
> > attacker can derive a value of X+D where D is a value of increased
> > deanonymization capabilities for an attacker. Operational expenses
> > for an attacker are the same as before (without timelocked bonds),
> > because they need to operate a lot of makers either way.
> >
> > If M is profit-driven and non-ideological, it can rent out all of its
> > coins to A as a package, for the price X, and get the same value without
> > running a maker and dedicating any resources and time to it, not
> > incurring any operatinal expenses (thus having a bigger profit in the
> > end).
> >
> > Attacker A will run a maker with M's coins, get profit X, pay X to M,
> > get increased deanonymization capabilities.
> >
> > If renting out of utxo is done in a way that the owner always gets X
> > after the lock expires, the operation will be riskless for the owner.
> > The attacker will need to lock amount X along with owner's coins, but
> > hopefully makes X back by running a maker operation.
> >
> > The price for renting out the coins will be determined on the size of
> > the 'coin package', so it will not be feasible for the owners of the
> > coins to rent them out separately.
> >
> > An attacker can even rent coins from several entities and combine them
> > to create a more 'powerful' maker. If I understand correctly, such
> > 'powerful' maker can have bigger profit than two less 'powerful'
> > makers. It seems like a centralization risk to me.
> >
>
> There's a few different issues here.
>
> Yes TXO fidelity bonds can be rented out, but that doesn't make a sybil
> attack cheaper. The aim of the fidelity bond scheme is to require makers
> to sacrifice value, renting out their fidelity bond coins doesn't avoid
> that sacrifice because the sacrifice is the paid rent. Because of the
> maths and market forces the rent paid by the attacker should be about
> the same as the cost of just buying the bitcoins and locking them.
>
> Centralization and decentralization are not ends in themselves, the main
> aim in JoinMarket is to improve privacy while keeping the other
> properties of bitcoin (e.g. censorship resistance). A single maker can
> never deanonoymize coinjoins no matter how valuable their bond is,
> because takers always choose multiple makers, and all of them need to be
> controlled by the sybil attacker for the attack to succeed. If a sybil
> attacker splits up their fidelity bonds (rented or not) amongst multiple
> maker bots then they reduce the value of their bonds because of the V^2
> term.
>
> Rented TXOs does destroy the effect of "A long-term holder probably
> won't want to attack a system like JoinMarket which makes his own
> investment coins more private and more fungible". However this is not
> the main effect which would protect JoinMarket's privacy. The main
> effect is the cost which for real-life numbers would be about 45-120
> bitcoin sent to burner outputs.
>
> Perhaps then rented TXOs is an argument against using coin age as a way
> to create fidelity bonds. Hodlers would be far less likely to rent out
> their coins if they have to specifically move them to a special
> time-locked address. Another point is that for privacy reasons creators
> of fidelity bonds should mix their coins before and after using them,
> because those TXOs are revealed to the world. So it's likely that
> fidelity bonds creators will need to install and run JoinMarket anyway.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 2 Aug 2019 14:18:36 +0500
> From: Dmitry Petukhov <dp@simplexum.com>
> To: Andrew Chow <achow101-lists@achow101.com>
> Cc: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future
>         Extensibility
> Message-ID: <20190802141836.15771ad6@simplexum.com>
> Content-Type: text/plain; charset=UTF-8
>
> ? Thu, 01 Aug 2019 19:01:06 +0000
> Andrew Chow <achow101-lists@achow101.com> wrote:
>
> > I spoke to some people OOB and they said that they didn't really like
> > the idea of having a prefix string (partially because they've already
> > implemented some proprietary types by simply squatting on unused
> > types). Matching the prefix string adds additional complexity to the
> > parser code.
>
> I do not oppose the idea of "{0xFC}|{private_type}" strongly, but I
> would like to note that for those who do not want to deal with
> additional complexity of handling a prefixed string, they can simply
> not use it at all. Since this is a private construction, and their
> private format specifies 'no prefix', they can just ignore everything
> that does not start with "{0xFC}|{0x00}", thus any further complexity
> regarding the prefix is also ignored. The only added complexity is one
> condition check: second_byte_of_the_key != 0
>
> My other argument for conflict-avoidance prefix as a first thing after
> 0xFC is that the set of future users of PSBT and private types is
> most likely much larger than the current set of those who already
> implemented proprietary types on their own, and thus the overall benefit
> for the whole industry will likely be bigger when 'i do not want
> conflict avoidance' decision have to be explicit, by setting the prefix
> to 0x00, and the set of possible conflicting types are limited only to
> those entities that made this explicit decision.
>
> Regarding the 'squatted' types, it seems to me that this only matters
> in the discussed context if they squatted on 0xFC type in particular.
> In other cases, they will need to implement changes anyway, to be
> compatible with the BIP. Maybe they could consider that one additional
> condition check is a small burden, and maybe they can tolerate that,
> for the benefit of reducing possibility of interoperability problems
> between other future PSBT/private types implementors.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 2 Aug 2019 06:43:27 -0500
> From: Bryan Bishop <kanzure@gmail.com>
> To: Emil Engler <me@emilengler.com>,    Bitcoin Protocol Discussion
>         <bitcoin-dev@lists.linuxfoundation.org>,        Bryan Bishop
>         <kanzure@gmail.com>
> Subject: Re: [bitcoin-dev] [Meta] bitcoin-dev moderation
> Message-ID:
>         <CABaSBay1w6ncJX2wVKWotp-FkzkDH4Nkve=
> QBz90S1G_-SzpZA@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Thu, Aug 1, 2019 at 10:50 PM Emil Engler via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > The current situation is that the moderation is slow and takes around
> > >24h for a E-Mail to be on the mailing list
>
> It really shouldn't be 24 hours. Our strategy was to have a few
> moderators in different timezones to cover sleep shifts or other
> disruptions of service. Evidently this has not been adequate.
>
> > Jonas Schnelli proposed: "I propose that we add more moderators to
> > shorten the moderation lag which has been between >24h, thus makes
> > debates cumbersome"
>
> Makes sense. I'll go find a few people.
>
> > Beside this I had the idea of people who already contributed n e-mails
> > to the mailing list don't need an approval for any e-mail anymore (Where
> > n is the number of previous e-mails). Does this exists already?
>
> There is an active software vulnerability which requires moderation to
> be enabled. This version of mailman is unmaintained, and Linux
> Foundation is migrating away from or abandoning the email protocol so
> they are less willing to do backend infrastructure work. This
> manifests in other ways, like downtime, but also weird situations like
> missing emails that never hit the moderation queue. I get pings from
> different people about two times a year where they report an email
> that they think I missed, but in fact it never hit the moderation
> queue at all. Email clearly isn't the greatest protocol.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 2 Aug 2019 08:19:03 -0400
> From: Ethan Heilman <eth3rs@gmail.com>
> To: "Kenshiro []" <tensiam@hotmail.com>,        Bitcoin Dev
>         <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin
>         protocol
> Message-ID:
>         <CAEM=
> y+UCdW2__nmQhWuL2FYvL6WKdBsF31WDFZUSdXPvgM2bvg@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Attack 1:
> I partition (i.e. eclipse) a bunch of nodes from the network this partition
> contains no mining power . I then mine 145 blocks for this partition. I
> don't even need 51% of the mining power because I'm not competing with any
> other miners. Under this rule this partition will hardfork from the network
> permanently. Under current rules this partition will be able to rejoin the
> network as the least weight chain will be orphaned.
>
> Attack 2:
> I pre-mine 145 blocks. A node goes offline for 24 hours, when it rejoins I
> feed it 145 blocks which fork off from the consensus chain. I have 24+24
> hours to mine these 145 blocks so I should be able to do this with 25% of
> the current hash rate at the time the node went offline. Under your rule
> each of these offline-->online nodes I attack this way will hardfork
> themselves from the rest of the network.
>
> I believe a moving-checkpoint rule as describe above would make Bitcoin
> more vulnerable to 51% attacks.
>
> A safer rule would be if a node detects a fork with both sides of the split
> having  length > 144 blocks, it halts and requests user intervention to
> determine which chain to follow.  I don't think 144 blocks is a great
> number to use here as 24 hours is very short. I suspect you could improve
> the security of the rule by making the number of blocks a fork most reach
> to halt the network proportional to the difference in time between the
> timestamp in the block prior to the fork and the current time. I am **NOT**
> proposing Bitcoin adopt such a rule.
>
> NXT has a fundamentally different security model as it uses Proof-of-stake
> rather than Proof-of-Work.
>
> On Wed, Jul 31, 2019 at 2:37 PM Kenshiro [] via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > P.S.: To be clearer, in this example I set an N value of 144 blocks,
> which
> > is approximately 24 hours.
> >
> > ------------------------------
> > *From:* Kenshiro [] <tensiam@hotmail.com>
> > *Sent:* Wednesday, July 31, 2019 16:40
> > *To:* Alistair Mann <al@pectw.net>; Bitcoin Protocol Discussion <
> > bitcoin-dev@lists.linuxfoundation.org>
> > *Subject:* Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin
> > protocol
> >
> > >>> How would a (potentially, state-sponsored) netsplit lasting longer
> > than N be
> > handled?
> >
> > It would be detected by the community much before reaching the reorg
> limit
> > of N blocks (it's 24 hours) so nodes could stop until the netsplit is
> > fixed.
> >
> > In the extreme case no one notice the network split during more than N
> > blocks (24 hours) and there are 2 permanent forks longer than N, nodes
> > from one branch could delete their local history so they would join the
> > other branch.
> >
> > Regards,
> >
> >
> > ------------------------------
> > *From:* Alistair Mann <al@pectw.net>
> > *Sent:* Wednesday, July 31, 2019 15:59
> > *To:* Kenshiro [] <tensiam@hotmail.com>; Bitcoin Protocol Discussion <
> > bitcoin-dev@lists.linuxfoundation.org>
> > *Subject:* Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin
> > protocol
> >
> > On Wednesday 31 Jul 2019 12:28:58 Kenshiro [] via bitcoin-dev wrote:
> >
> > > I would like to propose that a "moving checkpoint" is added to the
> > Bitcoin
> > > protocol. It's a very simple rule already implemented in NXT coin:
> > >
> > > - A node will ignore any new block under nodeBlockHeight - N, so the
> > > blockchain becomes truly immutable after N blocks, even during a 51%
> > attack
> > > which thanks to the moving checkpoint can't rewrite history older than
> > the
> > > last N blocks.
> >
> > How would a (potentially, state-sponsored) netsplit lasting longer than N
> > be
> > handled?
> > --
> > Alistair Mann
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190802/9071fcc3/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> End of bitcoin-dev Digest, Vol 51, Issue 3
> ******************************************
>

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

<div dir=3D"ltr"><div>Emil,</div><div><br></div><div>Re: [Meta] bitcoin-dev=
 moderation (Emil Engler)</div><div><br></div><div>Since my coding skills a=
re in the infancy stage and I can&#39;t contribute much in that area, at le=
ast not yet, I&#39;m looking for other ways to get involved and moderating =
the mailing list sounds like an ideal situation.=C2=A0 If you need help in =
this area I&#39;m more than happy to volunteer and pick up the slack.=C2=A0=
=C2=A0</div><div><br></div><div>Steven</div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Fri, Aug 2, 2019 at 8:50 AM &lt;<a=
 href=3D"mailto:bitcoin-dev-request@lists.linuxfoundation.org">bitcoin-dev-=
request@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">Send bitcoin-dev mailing list submissions =
to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://lists.linuxfoundation.org/ma=
ilman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://li=
sts.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
or, via email, send a message with subject or body &#39;help&#39; to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-request@lists.lin=
uxfoundation.org" target=3D"_blank">bitcoin-dev-request@lists.linuxfoundati=
on.org</a><br>
<br>
You can reach the person managing the list at<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-owner@lists.linux=
foundation.org" target=3D"_blank">bitcoin-dev-owner@lists.linuxfoundation.o=
rg</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than &quot;Re: Contents of bitcoin-dev digest...&quot;<br>
<br>
<br>
Today&#39;s Topics:<br>
<br>
=C2=A0 =C2=A01. [Meta] bitcoin-dev moderation (Emil Engler)<br>
=C2=A0 =C2=A02. Re: Improving JoinMarket&#39;s resistance to sybil attacks =
using<br>
=C2=A0 =C2=A0 =C2=A0 fidelity bonds (Chris Belcher)<br>
=C2=A0 =C2=A03. Re: Proposed Extensions to BIP 174 for Future Extensibility=
<br>
=C2=A0 =C2=A0 =C2=A0 (Dmitry Petukhov)<br>
=C2=A0 =C2=A04. Re: [Meta] bitcoin-dev moderation (Bryan Bishop)<br>
=C2=A0 =C2=A05. Re: Add a moving checkpoint to the Bitcoin protocol<br>
=C2=A0 =C2=A0 =C2=A0 (Ethan Heilman)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Thu, 1 Aug 2019 21:47:40 +0200<br>
From: Emil Engler &lt;<a href=3D"mailto:me@emilengler.com" target=3D"_blank=
">me@emilengler.com</a>&gt;<br>
To: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a><br>
Subject: [bitcoin-dev] [Meta] bitcoin-dev moderation<br>
Message-ID: &lt;<a href=3D"mailto:53b75074-59ff-9890-419d-d5e6fcb44a7c@emil=
engler.com" target=3D"_blank">53b75074-59ff-9890-419d-d5e6fcb44a7c@emilengl=
er.com</a>&gt;<br>
Content-Type: text/plain; charset=3D&quot;utf-8&quot;<br>
<br>
In the last #bitcoin-core-dev IRC meeting, the mailing list moderation<br>
was slightly discussed. It was decided to do this discussion mainly on<br>
this mailing list (which makes sense).<br>
<br>
The current situation is that the moderation is slow and takes around<br>
&gt;24h for a E-Mail to be on the mailing list.<br>
<br>
Jonas Schnelli proposed: &quot;I propose that we add more moderators to<br>
shorten the moderation lag which has been between &gt;24h, thus makes<br>
debates cumbersome&quot;<br>
<br>
Beside this I had the idea of people who already contributed n e-mails<br>
to the mailing list don&#39;t need an approval for any e-mail anymore (Wher=
e<br>
n is the number of previous e-mails). Does this exists already?<br>
<br>
Greetings,<br>
Emil Engler<br>
-------------- next part --------------<br>
A non-text attachment was scrubbed...<br>
Name: pEpkey.asc<br>
Type: application/pgp-keys<br>
Size: 3147 bytes<br>
Desc: not available<br>
URL: &lt;<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
attachments/20190801/a78795b7/attachment-0001.bin" rel=3D"noreferrer" targe=
t=3D"_blank">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachm=
ents/20190801/a78795b7/attachment-0001.bin</a>&gt;<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 2 Aug 2019 10:21:57 +0100<br>
From: Chris Belcher &lt;<a href=3D"mailto:belcher@riseup.net" target=3D"_bl=
ank">belcher@riseup.net</a>&gt;<br>
To: Dmitry Petukhov &lt;<a href=3D"mailto:dp@simplexum.com" target=3D"_blan=
k">dp@simplexum.com</a>&gt;,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
Subject: Re: [bitcoin-dev] Improving JoinMarket&#39;s resistance to sybil<b=
r>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 attacks using fidelity bonds<br>
Message-ID: &lt;<a href=3D"mailto:ae32dcbb-c950-3b3f-22b9-d152d6b221cb@rise=
up.net" target=3D"_blank">ae32dcbb-c950-3b3f-22b9-d152d6b221cb@riseup.net</=
a>&gt;<br>
Content-Type: text/plain; charset=3Dutf-8<br>
<br>
On 31/07/2019 16:50, Dmitry Petukhov wrote:<br>
&gt; ? Tue, 30 Jul 2019 22:39:14 +0100<br>
&gt; Chris Belcher via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or=
g</a>&gt;<br>
&gt; wrote:<br>
&gt; <br>
&gt;&gt; This is where a sacrifice of V bitcoins creates a<br>
&gt;&gt; bond of value V^2. The formula provides a strong incentive for<br>
&gt;&gt; profit-motivated makers to use all their fidelity bond coins with =
just<br>
&gt;&gt; one maker, not spread them out over many makers.<br>
&gt; <br>
&gt; The attacker derives additional value from the use of<br>
&gt; locked utxo - the deanonimyzation capabilities.<br>
&gt; <br>
&gt; An entity M can use all of its locked coins to run a maker, and then<b=
r>
&gt; earn value X. It will also incur some operational expenses in the cour=
se<br>
&gt; of running the maker, so the profit will be less than X.<br>
&gt; <br>
&gt; If these locked coins are given to the attacker A as a package, an<br>
&gt; attacker can derive a value of X+D where D is a value of increased<br>
&gt; deanonymization capabilities for an attacker. Operational expenses<br>
&gt; for an attacker are the same as before (without timelocked bonds),<br>
&gt; because they need to operate a lot of makers either way.<br>
&gt; <br>
&gt; If M is profit-driven and non-ideological, it can rent out all of its<=
br>
&gt; coins to A as a package, for the price X, and get the same value witho=
ut<br>
&gt; running a maker and dedicating any resources and time to it, not<br>
&gt; incurring any operatinal expenses (thus having a bigger profit in the<=
br>
&gt; end).<br>
&gt; <br>
&gt; Attacker A will run a maker with M&#39;s coins, get profit X, pay X to=
 M,<br>
&gt; get increased deanonymization capabilities. <br>
&gt; <br>
&gt; If renting out of utxo is done in a way that the owner always gets X<b=
r>
&gt; after the lock expires, the operation will be riskless for the owner.<=
br>
&gt; The attacker will need to lock amount X along with owner&#39;s coins, =
but<br>
&gt; hopefully makes X back by running a maker operation. <br>
&gt; <br>
&gt; The price for renting out the coins will be determined on the size of<=
br>
&gt; the &#39;coin package&#39;, so it will not be feasible for the owners =
of the<br>
&gt; coins to rent them out separately.<br>
&gt; <br>
&gt; An attacker can even rent coins from several entities and combine them=
<br>
&gt; to create a more &#39;powerful&#39; maker. If I understand correctly, =
such<br>
&gt; &#39;powerful&#39; maker can have bigger profit than two less &#39;pow=
erful&#39;<br>
&gt; makers. It seems like a centralization risk to me.<br>
&gt; <br>
<br>
There&#39;s a few different issues here.<br>
<br>
Yes TXO fidelity bonds can be rented out, but that doesn&#39;t make a sybil=
<br>
attack cheaper. The aim of the fidelity bond scheme is to require makers<br=
>
to sacrifice value, renting out their fidelity bond coins doesn&#39;t avoid=
<br>
that sacrifice because the sacrifice is the paid rent. Because of the<br>
maths and market forces the rent paid by the attacker should be about<br>
the same as the cost of just buying the bitcoins and locking them.<br>
<br>
Centralization and decentralization are not ends in themselves, the main<br=
>
aim in JoinMarket is to improve privacy while keeping the other<br>
properties of bitcoin (e.g. censorship resistance). A single maker can<br>
never deanonoymize coinjoins no matter how valuable their bond is,<br>
because takers always choose multiple makers, and all of them need to be<br=
>
controlled by the sybil attacker for the attack to succeed. If a sybil<br>
attacker splits up their fidelity bonds (rented or not) amongst multiple<br=
>
maker bots then they reduce the value of their bonds because of the V^2<br>
term.<br>
<br>
Rented TXOs does destroy the effect of &quot;A long-term holder probably<br=
>
won&#39;t want to attack a system like JoinMarket which makes his own<br>
investment coins more private and more fungible&quot;. However this is not<=
br>
the main effect which would protect JoinMarket&#39;s privacy. The main<br>
effect is the cost which for real-life numbers would be about 45-120<br>
bitcoin sent to burner outputs.<br>
<br>
Perhaps then rented TXOs is an argument against using coin age as a way<br>
to create fidelity bonds. Hodlers would be far less likely to rent out<br>
their coins if they have to specifically move them to a special<br>
time-locked address. Another point is that for privacy reasons creators<br>
of fidelity bonds should mix their coins before and after using them,<br>
because those TXOs are revealed to the world. So it&#39;s likely that<br>
fidelity bonds creators will need to install and run JoinMarket anyway.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 2 Aug 2019 14:18:36 +0500<br>
From: Dmitry Petukhov &lt;<a href=3D"mailto:dp@simplexum.com" target=3D"_bl=
ank">dp@simplexum.com</a>&gt;<br>
To: Andrew Chow &lt;<a href=3D"mailto:achow101-lists@achow101.com" target=
=3D"_blank">achow101-lists@achow101.com</a>&gt;<br>
Cc: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a><br>
Subject: Re: [bitcoin-dev] Proposed Extensions to BIP 174 for Future<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Extensibility<br>
Message-ID: &lt;<a href=3D"mailto:20190802141836.15771ad6@simplexum.com" ta=
rget=3D"_blank">20190802141836.15771ad6@simplexum.com</a>&gt;<br>
Content-Type: text/plain; charset=3DUTF-8<br>
<br>
? Thu, 01 Aug 2019 19:01:06 +0000<br>
Andrew Chow &lt;<a href=3D"mailto:achow101-lists@achow101.com" target=3D"_b=
lank">achow101-lists@achow101.com</a>&gt; wrote:<br>
<br>
&gt; I spoke to some people OOB and they said that they didn&#39;t really l=
ike<br>
&gt; the idea of having a prefix string (partially because they&#39;ve alre=
ady<br>
&gt; implemented some proprietary types by simply squatting on unused<br>
&gt; types). Matching the prefix string adds additional complexity to the<b=
r>
&gt; parser code.<br>
<br>
I do not oppose the idea of &quot;{0xFC}|{private_type}&quot; strongly, but=
 I<br>
would like to note that for those who do not want to deal with<br>
additional complexity of handling a prefixed string, they can simply<br>
not use it at all. Since this is a private construction, and their<br>
private format specifies &#39;no prefix&#39;, they can just ignore everythi=
ng<br>
that does not start with &quot;{0xFC}|{0x00}&quot;, thus any further comple=
xity<br>
regarding the prefix is also ignored. The only added complexity is one<br>
condition check: second_byte_of_the_key !=3D 0 <br>
<br>
My other argument for conflict-avoidance prefix as a first thing after<br>
0xFC is that the set of future users of PSBT and private types is<br>
most likely much larger than the current set of those who already<br>
implemented proprietary types on their own, and thus the overall benefit<br=
>
for the whole industry will likely be bigger when &#39;i do not want<br>
conflict avoidance&#39; decision have to be explicit, by setting the prefix=
<br>
to 0x00, and the set of possible conflicting types are limited only to<br>
those entities that made this explicit decision.<br>
<br>
Regarding the &#39;squatted&#39; types, it seems to me that this only matte=
rs<br>
in the discussed context if they squatted on 0xFC type in particular.<br>
In other cases, they will need to implement changes anyway, to be<br>
compatible with the BIP. Maybe they could consider that one additional<br>
condition check is a small burden, and maybe they can tolerate that,<br>
for the benefit of reducing possibility of interoperability problems<br>
between other future PSBT/private types implementors.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Fri, 2 Aug 2019 06:43:27 -0500<br>
From: Bryan Bishop &lt;<a href=3D"mailto:kanzure@gmail.com" target=3D"_blan=
k">kanzure@gmail.com</a>&gt;<br>
To: Emil Engler &lt;<a href=3D"mailto:me@emilengler.com" target=3D"_blank">=
me@emilengler.com</a>&gt;,=C2=A0 =C2=A0 Bitcoin Protocol Discussion<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t;,=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bryan Bishop<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:kanzure@gmail.com" target=
=3D"_blank">kanzure@gmail.com</a>&gt;<br>
Subject: Re: [bitcoin-dev] [Meta] bitcoin-dev moderation<br>
Message-ID:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;CABaSBay1w6ncJX2wVKWotp-FkzkDH4Nkve=3D<a hr=
ef=3D"mailto:QBz90S1G_-SzpZA@mail.gmail.com" target=3D"_blank">QBz90S1G_-Sz=
pZA@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=3D&quot;UTF-8&quot;<br>
<br>
On Thu, Aug 1, 2019 at 10:50 PM Emil Engler via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; The current situation is that the moderation is slow and takes around<=
br>
&gt; &gt;24h for a E-Mail to be on the mailing list<br>
<br>
It really shouldn&#39;t be 24 hours. Our strategy was to have a few<br>
moderators in different timezones to cover sleep shifts or other<br>
disruptions of service. Evidently this has not been adequate.<br>
<br>
&gt; Jonas Schnelli proposed: &quot;I propose that we add more moderators t=
o<br>
&gt; shorten the moderation lag which has been between &gt;24h, thus makes<=
br>
&gt; debates cumbersome&quot;<br>
<br>
Makes sense. I&#39;ll go find a few people.<br>
<br>
&gt; Beside this I had the idea of people who already contributed n e-mails=
<br>
&gt; to the mailing list don&#39;t need an approval for any e-mail anymore =
(Where<br>
&gt; n is the number of previous e-mails). Does this exists already?<br>
<br>
There is an active software vulnerability which requires moderation to<br>
be enabled. This version of mailman is unmaintained, and Linux<br>
Foundation is migrating away from or abandoning the email protocol so<br>
they are less willing to do backend infrastructure work. This<br>
manifests in other ways, like downtime, but also weird situations like<br>
missing emails that never hit the moderation queue. I get pings from<br>
different people about two times a year where they report an email<br>
that they think I missed, but in fact it never hit the moderation<br>
queue at all. Email clearly isn&#39;t the greatest protocol.<br>
<br>
- Bryan<br>
<a href=3D"http://heybryan.org/" rel=3D"noreferrer" target=3D"_blank">http:=
//heybryan.org/</a><br>
1 512 203 0507<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Fri, 2 Aug 2019 08:19:03 -0400<br>
From: Ethan Heilman &lt;<a href=3D"mailto:eth3rs@gmail.com" target=3D"_blan=
k">eth3rs@gmail.com</a>&gt;<br>
To: &quot;Kenshiro []&quot; &lt;<a href=3D"mailto:tensiam@hotmail.com" targ=
et=3D"_blank">tensiam@hotmail.com</a>&gt;,=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bitco=
in Dev<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t;<br>
Subject: Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 protocol<br>
Message-ID:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &lt;CAEM=3D<a href=3D"mailto:y%2BUCdW2__nmQhWuL=
2FYvL6WKdBsF31WDFZUSdXPvgM2bvg@mail.gmail.com" target=3D"_blank">y+UCdW2__n=
mQhWuL2FYvL6WKdBsF31WDFZUSdXPvgM2bvg@mail.gmail.com</a>&gt;<br>
Content-Type: text/plain; charset=3D&quot;utf-8&quot;<br>
<br>
Attack 1:<br>
I partition (i.e. eclipse) a bunch of nodes from the network this partition=
<br>
contains no mining power . I then mine 145 blocks for this partition. I<br>
don&#39;t even need 51% of the mining power because I&#39;m not competing w=
ith any<br>
other miners. Under this rule this partition will hardfork from the network=
<br>
permanently. Under current rules this partition will be able to rejoin the<=
br>
network as the least weight chain will be orphaned.<br>
<br>
Attack 2:<br>
I pre-mine 145 blocks. A node goes offline for 24 hours, when it rejoins I<=
br>
feed it 145 blocks which fork off from the consensus chain. I have 24+24<br=
>
hours to mine these 145 blocks so I should be able to do this with 25% of<b=
r>
the current hash rate at the time the node went offline. Under your rule<br=
>
each of these offline--&gt;online nodes I attack this way will hardfork<br>
themselves from the rest of the network.<br>
<br>
I believe a moving-checkpoint rule as describe above would make Bitcoin<br>
more vulnerable to 51% attacks.<br>
<br>
A safer rule would be if a node detects a fork with both sides of the split=
<br>
having=C2=A0 length &gt; 144 blocks, it halts and requests user interventio=
n to<br>
determine which chain to follow.=C2=A0 I don&#39;t think 144 blocks is a gr=
eat<br>
number to use here as 24 hours is very short. I suspect you could improve<b=
r>
the security of the rule by making the number of blocks a fork most reach<b=
r>
to halt the network proportional to the difference in time between the<br>
timestamp in the block prior to the fork and the current time. I am **NOT**=
<br>
proposing Bitcoin adopt such a rule.<br>
<br>
NXT has a fundamentally different security model as it uses Proof-of-stake<=
br>
rather than Proof-of-Work.<br>
<br>
On Wed, Jul 31, 2019 at 2:37 PM Kenshiro [] via bitcoin-dev &lt;<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
<br>
&gt; P.S.: To be clearer, in this example I set an N value of 144 blocks, w=
hich<br>
&gt; is approximately 24 hours.<br>
&gt;<br>
&gt; ------------------------------<br>
&gt; *From:* Kenshiro [] &lt;<a href=3D"mailto:tensiam@hotmail.com" target=
=3D"_blank">tensiam@hotmail.com</a>&gt;<br>
&gt; *Sent:* Wednesday, July 31, 2019 16:40<br>
&gt; *To:* Alistair Mann &lt;<a href=3D"mailto:al@pectw.net" target=3D"_bla=
nk">al@pectw.net</a>&gt;; Bitcoin Protocol Discussion &lt;<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<br>
&gt; *Subject:* Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin<br=
>
&gt; protocol<br>
&gt;<br>
&gt; &gt;&gt;&gt; How would a (potentially, state-sponsored) netsplit lasti=
ng longer<br>
&gt; than N be<br>
&gt; handled?<br>
&gt;<br>
&gt; It would be detected by the community much before reaching the reorg l=
imit<br>
&gt; of N blocks (it&#39;s 24 hours) so nodes could stop until the netsplit=
 is<br>
&gt; fixed.<br>
&gt;<br>
&gt; In the extreme case no one notice the network split during more than N=
<br>
&gt; blocks (24 hours) and there are 2 permanent forks longer than N, nodes=
<br>
&gt; from one branch could delete their local history so they would join th=
e<br>
&gt; other branch.<br>
&gt;<br>
&gt; Regards,<br>
&gt;<br>
&gt;<br>
&gt; ------------------------------<br>
&gt; *From:* Alistair Mann &lt;<a href=3D"mailto:al@pectw.net" target=3D"_b=
lank">al@pectw.net</a>&gt;<br>
&gt; *Sent:* Wednesday, July 31, 2019 15:59<br>
&gt; *To:* Kenshiro [] &lt;<a href=3D"mailto:tensiam@hotmail.com" target=3D=
"_blank">tensiam@hotmail.com</a>&gt;; Bitcoin Protocol Discussion &lt;<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<br>
&gt; *Subject:* Re: [bitcoin-dev] Add a moving checkpoint to the Bitcoin<br=
>
&gt; protocol<br>
&gt;<br>
&gt; On Wednesday 31 Jul 2019 12:28:58 Kenshiro [] via bitcoin-dev wrote:<b=
r>
&gt;<br>
&gt; &gt; I would like to propose that a &quot;moving checkpoint&quot; is a=
dded to the<br>
&gt; Bitcoin<br>
&gt; &gt; protocol. It&#39;s a very simple rule already implemented in NXT =
coin:<br>
&gt; &gt;<br>
&gt; &gt; - A node will ignore any new block under nodeBlockHeight - N, so =
the<br>
&gt; &gt; blockchain becomes truly immutable after N blocks, even during a =
51%<br>
&gt; attack<br>
&gt; &gt; which thanks to the moving checkpoint can&#39;t rewrite history o=
lder than<br>
&gt; the<br>
&gt; &gt; last N blocks.<br>
&gt;<br>
&gt; How would a (potentially, state-sponsored) netsplit lasting longer tha=
n N<br>
&gt; be<br>
&gt; handled?<br>
&gt; --<br>
&gt; Alistair Mann<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.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.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: &lt;<a href=3D"http://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
attachments/20190802/9071fcc3/attachment.html" rel=3D"noreferrer" target=3D=
"_blank">http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments=
/20190802/9071fcc3/attachment.html</a>&gt;<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br>
<br>
End of bitcoin-dev Digest, Vol 51, Issue 3<br>
******************************************<br>
</blockquote></div></div>

--00000000000093533f058f2511b1--