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
|
Return-Path: <hampus.sjoberg@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B2C21A82
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Jul 2017 13:17:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f173.google.com (mail-qt0-f173.google.com
[209.85.216.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1F0AD1E8
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Jul 2017 13:17:15 +0000 (UTC)
Received: by mail-qt0-f173.google.com with SMTP id r30so37372009qtc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Jul 2017 06:17:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=pXGOSwMxstOQ1zjKjyEzLl0i3nrDB01TschYj373f9M=;
b=LbgZoMM2Myqygw4053gHgSfgUBRWHZitj4zuIsdASzA5LxSXacHzOR+OYcIB0LWR05
qnD5Fj/3R3G20jj31HDZlPvBY95AbMxrDIZPW1yF92mH9y34nJ2DTEFMzVDigP2o6Z4L
/pW1ASAk0JO+AFQjxsixfj/hdZi1rhYlBuao2MfBCiaWVrrN1x4/3MP6Ntf+ifD2SL2y
5tdpCgi3Dbso8tsZpunkn0FScVJvwbVZ3ELvAv6LnBsFQxEr0BG/5IZFRQ4lOLrMSM3q
5gD0FyUHPty2Z2GJDMOo20MdYdBTXHmXFsBjuvpoaRO9a5ucSPxMg3wfckoZdc+C3k4n
rRbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=pXGOSwMxstOQ1zjKjyEzLl0i3nrDB01TschYj373f9M=;
b=DMdZwqgOWxqS07VMUwWuFJ6O3NCUuJB54ihpetUrsfMX1yh2tOc7TmdgAk68WWIldw
KFHCtUrGiUP9UhEyBFbPWEUw9Y7vtNvVy1xFYYmJG2TR7eWNm2MLnaJDzzM1Ya0m2gqu
qGb6REQSxs+aY8NpDpOtuEpsK1tarNP+0Ekcaw3r52tpP1Ap1unpdU67JuDnApFJbzd5
OXRyUg2CWuQVfh/Mrgjr+/2IAbKRQnNQPKW+6XDHhOYkvcKRGhmHR41fzIcSlajAZUvQ
97lPR9QRvN/QHmSXSb0mN5c/OlQKTcpDrsrjbi8MgId2ZWByRstigSV+95crM/RnaSQI
blZw==
X-Gm-Message-State: AIVw111TaLt4WJFWyvVu7q+yhZo2gEaK4miNbmr+48s5bT53cAwSWPoA
EBjnfh7BkcPbXXJ2+R53L5owG8Zmfw==
X-Received: by 10.200.45.241 with SMTP id q46mr5155534qta.177.1499951834166;
Thu, 13 Jul 2017 06:17:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.186.175 with HTTP; Thu, 13 Jul 2017 06:17:13 -0700 (PDT)
In-Reply-To: <3277f4ef-a250-d383-8b00-cb912eb19f8b@gmail.com>
References: <24f2b447-a237-45eb-ef9f-1a62533fad5c@gmail.com>
<83671224-f6ff-16a9-81c0-20ab578aec9d@gmail.com>
<AAC86547-7904-4475-9966-138130019567@taoeffect.com>
<6764b8af-bb4c-615d-5af5-462127bbbe36@gmail.com>
<F2C3A9F4-07AB-41B9-B915-9E33EE313F9E@taoeffect.com>
<117f6a96-6d90-778a-d87a-be72592e31c5@gmail.com>
<42C03DFC-C358-4F8C-A088-735910CCC60E@taoeffect.com>
<3277f4ef-a250-d383-8b00-cb912eb19f8b@gmail.com>
From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= <hampus.sjoberg@gmail.com>
Date: Thu, 13 Jul 2017 15:17:13 +0200
Message-ID: <CAFMkqK_2V+p0JmrAj5WSkEDWXWG4h4c1SzZ4mxEiZBwDpAHd4A@mail.gmail.com>
To: Paul Sztorc <truthcoin@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a1137558c4186b3055432c00e"
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 13 Jul 2017 13:22:39 +0000
Subject: Re: [bitcoin-dev] Drivechain RfD -- Follow Up
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: Thu, 13 Jul 2017 13:17:16 -0000
--001a1137558c4186b3055432c00e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
In softforks, I would argue that 100% of all nodes and miners need to
upgrade to the new rules.
This makes sure that trying to incorrectly spend an "AnyOneCanSpend" will
result in a hardfork, instead of a temporary (or permanent) chainsplit.
With drivechains, it seems like the current plan is to only let the nodes
that are interested in the drivechain validate the other chain, and not
necessarily 100% of the network.
I guess this could be any percentage of the network, which could lead to a
temporary/permanent chainsplit depending on how many percentage of the
miners are also validating the other chain (am I missing something here?).
I have no way to evaluate if this is an okay trade-off.
It seems like major disruption could very likely happen if say only 5% of
all fullnodes validate the drivechain.
To be fully secure, it seems like 100% of all nodes should also have a
fullnode for the drivechain as well...
This is one of the reasons I don't advocate sidechains/drivechains as a
scaling solution, it looks like it would have to the same outcome as a
blocksize increase on the mainchain, but with more complexity.
I think sidechains/drivechains could be useful for other things though.
Thanks for all your work so far Paul.
Hampus
2017-07-13 4:58 GMT+02:00 Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:
> I will repeat that Drivechain can sometimes be confusing because it is
> different things to different people.
>
> Here is my attempt to break it down into different modes:
>
> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is
> running, say, 0.13). However, they experience the effects of the new rule=
s
> which miners add (as per the soft fork[s] to add drivechain functionality
> and individual drivechains).
> [DC#1] -- Someone who always upgrades to the latest version of the Bitcoi=
n
> software, but otherwise has no interest in running/using sidechains.
> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and decides
> to also become a full node of one or more sidechains, but who ever actual=
ly
> uses the sidechains.
> [DC#3] -- Someone who upgrades their software, runs sidechain full nodes,
> and actively moves money to and from these.
>
> Greg is still conflating modes [DC#1] and [DC#3]. Specifically, he
> equivocates on the team "steal", using it to mean two different things: [=
a]
> spending an invalid transaction, and [b] a withdrawal that would not matc=
h
> the report given by a sidechain node.
>
> The two are quite different, see my comments below:
>
>
> On 7/12/2017 9:15 PM, Tao Effect wrote:
>
> FYI that document is nearly two years old, and although it is still
> overwhelmingly accurate, new optimizations allow us (I think) to push the
> waiting period to several weeks and the total ACK counting period up to
> several months.
>
> What does that have to do with my question? The counting period, if I
> understood correctly, is something miners do, not full nodes.
>
>
> Greg quoted a passage that contained an older parameter estimate of "a fe=
w
> days", and I thought it would be helpful and informative if I clarified
> that the parameter estimate had been updated to a new (more secure) value=
.
>
> In point of fact, he is wrong, because nodes do the counting. When miners
> find a block, they can choose to move the counter up, down, or not at all=
.
> But nodes do the counting.
>
>
> Also, if the document is old and/or outdated, do you happen to have a lin=
k
> to a more update-to-date version of the spec? It would be helpful for
> review.
>
>
> As I stated above, the document is mostly accurate. There is no other mor=
e
> up to date version.
>
>
> Because if a node doesn't have the sidechain's information, it will just
> assume every withdrawal is valid. This is comparable to someone who still
> hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>
>
> Right, for [DC#0] and [DC#1], but for [DC#2] an [DC#3] you marked it as
> "Yes" without substantiating why you did so.
>
>
>
> Above, Greg omitted his original question. For reference, it was:
>
> The Drivechain spec seems to claim that its use of anyone-can-pay is the=
same as P2SH
>
>
> The answer is that both DC and P2SH use transactions which are 'always
> valid' to some group of people (un-upgraded users) but which are sometime=
s
> invalid to new users. So the only difference would be for [DC#0] vs other
> versions, but this difference is trivial as miners will censor invalid tx=
ns.
>
> It is your classic soft fork situation.
>
>
> Again, from the perspective of a mainchain user, every withdrawal is vali=
d.
>
> And that is not how P2SH works.
>
>
> Again, keep in mind that Greg continually conflates two different things:
> 1. Whether the soft fork rules have been followed, and
> 2. Whether the WT^ submitted by a majority hashrate matches the one
> calculated by sidechain nodes.
>
> The first case is exactly equal to P2SH. Just as old nodes accept every
> P2SH transaction, so too will [DC#0] users accept every WT^ transaction.
>
> In the second case, it so happens that [DC#1], [DC#2], and [DC#3] would
> also accept any WT^ *that followed the Drivechain rules*, even if they di=
d
> not like the outcome (because the outcome in question was arbitrarily
> designated as a "theft" of funds -- again, see the second case in the lis=
t
> above). In this way, it is exactly similar to P2SH because nodes will
> accept *any* p2sh txn **that follows the p2sh rules**, even if they don't
> "like" the specific script contained within (for example, because it is a
> theft of "their" BitFinex funds, or a donation to a political candidate
> they dislike, etc).
>
>
> [DC#2] and [DC#3] would certainly have an interest in understanding what
> is going on, but that has absolutely nothing whatsoever to do with Bitcoi=
n
> Core and so is off-topic for this mailing list.
>
> How is that an answer to my question?
>
>
> Greg is, of course, not entitled to an answer to irrelevant questions --
> just as he would not be entitled to an answer if he asked for my favorite
> color or my home address. And such answers would needlessly consume the
> mailing list's scarce time.
>
>
> What does "[DC#2] and [DC#3] would certainly have an interest in
> understanding what is going on" mean?
>
>
> It is clear to me that, if we are not clear on the basics first, we canno=
t
> hope to tackle anything intermediate. We will come back to this after
> clearing up soft fork part.
>
>
> In P2SH, all upgraded nodes will reject invalid P2SH transactions, period=
.
>
>
> In DC, all upgraded nodes will reject invalid DC transactions, period.
>
>
> What exactly would [DC#2] and [DC#3] nodes do when faced with an invalid
> WT^ transaction =E2=80=94 invalid in the sense that it contains funds whi=
ch miners
> are stealing?
>
>
> The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and [DC#1]
> nodes do. This is what I mean by "every withdrawal is valid".
>
>
> Again, in P2SH miners cannot steal funds, because all full nodes have a
> fully automatic enforcement policy.
>
>
> In DC, miners cannot steal funds, because all full nodes have a fully
> automatic enforcement policy.
>
> However, DC *allows* users to choose to place some of their BTC at the
> relative mercy of the miners in creative ways, if they wish (as does P2SH
> -- someone could write a script which donates funds to miners, and then
> fund it... "paying" to that script). This is another example of conflatin=
g
> [DC#1] and [DC#3].
>
> Paul
>
>
>
>
> On Jul 12, 2017, at 5:26 PM, Paul Sztorc <truthcoin@gmail.com> wrote:
>
> The confusion below stems from his conflation of several different ideas.
>
> I will try to explicitly clarify a distinction between several types of
> user (or, "modes" of use if you prefer):
>
> [DC#0] -- Someone who does not upgrade their Bitcoin software (and is
> running, say, 0.13). However, they experience the effects of the new rule=
s
> which miners add (as per the soft fork[s] to add drivechain functionality
> and individual drivechains).
> [DC#1] -- Someone who always upgrades to the latest version of the Bitcoi=
n
> software, but otherwise has no interest in running/using sidechains.
> [DC#2] -- Someone who upgrades to the latest Bitcoin version, and decides
> to also become a full node of one or more sidechains, but who ever actual=
ly
> uses the sidechains.
> [DC#3] -- Someone who upgrades their software, runs sidechain full nodes,
> and actively moves money to and from these.
>
>
> On 7/12/2017 6:43 PM, Tao Effect wrote:
>
>
> I am now looking closer again at step number 4 in the Drivechain
> specification [2]:
>
> 4. Everyone waits for a period of, say, 3 days. This gives everyone an
> opportunity to make sure the same WT^ is in both the Bitcoin coinbase and
> the Sidechain header. If they=E2=80=99re different, everyone has plenty o=
f time to
> contact each other, figure out what is going on, and restart the process
> until its right.
>
> It seems to me that where our disagreement lies is in this point.
> The Drivechain spec seems to claim that its use of anyone-can-pay is the
> same as P2SH (and in later emails you reference SegWit as well). Is this
> really true?
>
> FYI that document is nearly two years old, and although it is still
> overwhelmingly accurate, new optimizations allow us (I think) to push the
> waiting period to several weeks and the total ACK counting period up to
> several months.
>
> [DC#0] Yes
> [DC#1] Yes
> [DC#2] Yes
> [DC#3] Yes
>
> Because if a node doesn't have the sidechain's information, it will just
> assume every withdrawal is valid. This is comparable to someone who still
> hasn't upgraded to support P2SH, in cases [DC#0] and [#1].
>
> (And this is the main advantage of DC over extension blocks).
>
>
> 2. Per the question in [1], it's my understanding that P2SH transactions
> contain all of the information within themselves for full nodes to act as=
a
> check on miners mishandling the anyone-can-spend nature of P2SH
> transactions. However, that does not seem to be the case with WT^
> transactions.
>
> [DC#0] They do.
> [DC#1] They do.
> [DC#2] They do.
> [DC#3] They do.
>
> Again, from the perspective of a mainchain user, every withdrawal is vali=
d.
>
>
> In P2SH txns, there is no need for anyone to, as the Drivechain spec says=
,
> "to contact each other, figure out what is going on". Everything just
> automatically works.
>
> There is no *need* to this in Drivechain, either, for [DC#0] or [DC#1].
>
> [DC#2] and [DC#3] would certainly have an interest in understanding what
> is going on, but that has absolutely nothing whatsoever to do with Bitcoi=
n
> Core and so is off-topic for this mailing list.
>
>
> If the security of WT^ transactions could be brought up to actually be in
> line with the security of P2SH and SegWit transactions, then I would have
> far less to object to.
>
> Somehow I doubt it.
>
>
> Paul
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--001a1137558c4186b3055432c00e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>In softforks, I would argue that 100% of all no=
des and miners need to upgrade to the new rules.<br>This makes sure that tr=
ying to incorrectly spend an "AnyOneCanSpend" will result in a ha=
rdfork, instead of a temporary (or permanent) chainsplit.<br><br></div>With=
drivechains, it seems like the current plan is to only let the nodes that =
are interested in the drivechain validate the other chain, and not necessar=
ily 100% of the network.<br></div><div>I guess this could be any percentage=
of the network, which could lead to a temporary/permanent chainsplit depen=
ding on how many percentage of the miners are also validating the other cha=
in (am I missing something here?).<br><br>I have no way to evaluate if this=
is an okay trade-off.<br>It seems like major disruption could very likely =
happen if say only 5% of all fullnodes validate the drivechain.<br><br></di=
v><div>To be fully secure, it seems like 100% of all nodes should also have=
a fullnode for the drivechain as well...<br></div><div>This is one of the =
reasons I don't advocate sidechains/drivechains as a scaling solution, =
it looks like it would have to the same outcome as a blocksize increase on =
the mainchain, but with more complexity.<br></div><div>I think sidechains/d=
rivechains could be useful for other things though.<br><br><br></div><div>T=
hanks for all your work so far Paul.<br></div><div>Hampus<br></div></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">2017-07-13 4:58 GMT=
+02:00 Paul Sztorc via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:=
bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.=
linuxfoundation.org</a>></span>:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"m_-8968958481456770284moz-cite-prefix">I will repeat that=
Drivechain can
sometimes be confusing because it is different things to different
people.<br>
<br>
Here is my attempt to break it down into different modes:<span class=
=3D""><br>
<br>
[DC#0] -- Someone who does not upgrade their Bitcoin software (and
is running, say, 0.13). However, they experience the effects of
the new rules which miners add (as per the soft fork[s] to add
drivechain functionality and individual drivechains).<br>
[DC#1] -- Someone who always upgrades to the latest version of the
Bitcoin software, but otherwise has no interest in running/using
sidechains.<br>
[DC#2] -- Someone who upgrades to the latest Bitcoin version, and
decides to also become a full node of one or more sidechains, but
who ever actually uses the sidechains.<br>
[DC#3] -- Someone who upgrades their software, runs sidechain full
nodes, and actively moves money to and from these.<br>
<br></span>
Greg is still conflating modes [DC#1] and [DC#3]. Specifically, he
equivocates on the team "steal", using it to mean two diffe=
rent
things: [a] spending an invalid transaction, and [b] a withdrawal
that would not match the report given by a sidechain node.<br>
<br>
The two are quite different, see my comments below:<span class=3D""><=
br>
<br>
<br>
On 7/12/2017 9:15 PM, Tao Effect wrote:<br>
</span></div><span class=3D"">
<blockquote type=3D"cite">
<div>
<blockquote type=3D"cite">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">FYI that
document is nearly two years old, and although it is still
overwhelmingly accurate, new optimizations allow us (I
think) to push the waiting period to several weeks and the
total ACK counting period up to several months.</div>
</blockquote>
</div>
<div>What does that have to do with my question? The
counting period, if I understood correctly, is something miners
do, not full nodes.</div>
</blockquote>
<br></span>
Greg quoted a passage that contained an older parameter estimate of
"a few days", and I thought it would be helpful and informati=
ve if I
clarified that the parameter estimate had been updated to a new
(more secure) value.<br>
<br>
In point of fact, he is wrong, because nodes do the counting. When
miners find a block, they can choose to move the counter up, down,
or not at all. But nodes do the counting.<span class=3D""><br>
<br>
<br>
<blockquote type=3D"cite">
<div>Also, if the document is old and/or outdated, do you
happen to have a link to a more update-to-date version of the
spec? It would be helpful for review.</div>
</blockquote>
<br></span>
As I stated above, the document is mostly accurate. There is no
other more up to date version.<span class=3D""><br>
<br>
<br>
<blockquote type=3D"cite">
<div>
<blockquote type=3D"cite">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">Because if a
node doesn't have the sidechain's information, it will =
just
assume every withdrawal is valid. This is comparable to
someone who still hasn't upgraded to support P2SH, in cases
[DC#0] and [#1].<br>
</div>
</blockquote>
<br>
</div>
<div>Right, for [DC#0] and [DC#1], but for [DC#2] an
[DC#3] you marked it as "Yes" without substantiating why =
you did
so.</div>
</blockquote>
<br>
<br></span>
Above, Greg omitted his original question. For reference, it was:<span =
class=3D""><br>
<br>
<blockquote type=3D"cite">
<pre style=3D"white-space:pre-wrap;color:rgb(0,0,0);font-style:normal=
;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:normal;=
letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;=
word-spacing:0px;text-decoration-style:initial;text-decoration-color:initia=
l"> The Drivechain spec seems to claim that its use of anyone-can-pay is th=
e same as P2SH</pre>
</blockquote>
<br></span>
The answer is that both DC and P2SH use transactions which are
'always valid' to some group of people (un-upgraded users) but =
which
are sometimes invalid to new users. So the only difference would be
for [DC#0] vs other versions, but this difference is trivial as
miners will censor invalid txns.<br>
<br>
It is your classic soft fork situation.<span class=3D""><br>
<br>
<br>
<blockquote type=3D"cite">
<div>
<blockquote type=3D"cite">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">Again, from the
perspective of a mainchain user, every withdrawal is valid.</di=
v>
</blockquote>
</div>
<div>And that is not how P2SH works.</div>
</blockquote>
<br></span>
Again, keep in mind that Greg continually conflates two different
things:<br>
1. Whether the soft fork rules have been followed, and<br>
2. Whether the WT^ submitted by a majority hashrate matches the one
calculated by sidechain nodes.<br>
<br>
The first case is exactly equal to P2SH. Just as old nodes accept
every P2SH transaction, so too will [DC#0] users accept every WT^
transaction.<br>
<br>
In the second case, it so happens that [DC#1], [DC#2], and [DC#3]
would also accept any WT^ *that followed the Drivechain rules*, even
if they did not like the outcome (because the outcome in question
was arbitrarily designated as a "theft" of funds -- again, se=
e the
second case in the list above). In this way, it is exactly similar
to P2SH because nodes will accept *any* p2sh txn **that follows the
p2sh rules**, even if they don't "like" the specific scri=
pt
contained within (for example, because it is a theft of "their&quo=
t;
BitFinex funds, or a donation to a political candidate they dislike,
etc).<span class=3D""><br>
<br>
<br>
<blockquote type=3D"cite">
<div>
<blockquote type=3D"cite">
<div text=3D"#000000" bgcolor=3D"#FFFFFF">[DC#2] and
[DC#3] would certainly have an interest in understanding
what is going on, but that has absolutely nothing whatsoever
to do with Bitcoin Core and so is off-topic for this mailing
list.<br>
</div>
</blockquote>
</div>
<div>How is that an answer to my question?</div>
</blockquote>
<br></span>
Greg is, of course, not entitled to an answer to irrelevant
questions -- just as he would not be entitled to an answer if he
asked for my favorite color or my home address. And such answers
would needlessly consume the mailing list's scarce time.<span class=
=3D""><br>
<br>
<br>
<blockquote type=3D"cite">
<div>What does "[DC#2] and [DC#3] would certainly have an
interest in understanding what is going on" mean?</div>
</blockquote>
<br></span>
It is clear to me that, if we are not clear on the basics first, we
cannot hope to tackle anything intermediate. We will come back to
this after clearing up soft fork part.<span class=3D""><br>
<br>
<br>
<blockquote type=3D"cite">
<div>In P2SH, all upgraded nodes will reject invalid P2SH
transactions, period.</div>
</blockquote>
<br></span>
In DC, all upgraded nodes will reject invalid DC transactions,
period.<span class=3D""><br>
<br>
<br>
<blockquote type=3D"cite">
<div>What exactly would [DC#2] and [DC#3] nodes do when
faced with an invalid WT^ transaction =E2=80=94 invalid in the sens=
e
that it contains funds which miners are stealing?</div>
</blockquote>
<br></span>
The [DC#2] and [DC#3] nodes would do exactly what the [DC#0] and
[DC#1] nodes do. This is what I mean by "every withdrawal is valid=
".<span class=3D""><br>
<br>
<br>
<blockquote type=3D"cite">
<div>Again, in P2SH miners cannot steal funds, because
all full nodes have a fully automatic enforcement policy.</div>
</blockquote>
<br></span>
In DC, miners cannot steal funds, because all full nodes have a
fully automatic enforcement policy.<br>
<br>
However, DC *allows* users to choose to place some of their BTC at
the relative mercy of the miners in creative ways, if they wish (as
does P2SH -- someone could write a script which donates funds to
miners, and then fund it... "paying" to that script). This is
another example of conflating [DC#1] and [DC#3].<span class=3D"HOEnZb">=
<font color=3D"#888888"><br>
<br>
Paul</font></span><div><div class=3D"h5"><br>
<span style=3D"color:rgb(0,0,0);font-family:Helvetica;font-size:14px;fo=
nt-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:=
normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px;font-variant-ligatures:normal;font-variant-numeric:nor=
mal;font-variant-alternates:normal;font-variant-east-asian:normal;line-heig=
ht:normal"></span><br>
<br>
<br>
<blockquote type=3D"cite">
<div>
<div>
<blockquote type=3D"cite">
<div>On Jul 12, 2017, at 5:26 PM, Paul Sztorc <<a href=3D"ma=
ilto:truthcoin@gmail.com" target=3D"_blank">truthcoin@gmail.com</a>>
wrote:</div>
<br class=3D"m_-8968958481456770284Apple-interchange-newline">
<div>
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"m_-8968958481456770284moz-cite-prefix">The co=
nfusion below stems
from his conflation of several different ideas.<br>
<br>
I will try to explicitly clarify a distinction between
several types of user (or, "modes" of use if yo=
u
prefer):<br>
<br>
[DC#0] -- Someone who does not upgrade their Bitcoin
software (and is running, say, 0.13). However, they
experience the effects of the new rules which miners
add (as per the soft fork[s] to add drivechain
functionality and individual drivechains).<br>
[DC#1] -- Someone who always upgrades to the latest
version of the Bitcoin software, but otherwise has no
interest in running/using sidechains.<br>
[DC#2] -- Someone who upgrades to the latest Bitcoin
version, and decides to also become a full node of one
or more sidechains, but who ever actually uses the
sidechains.<br>
[DC#3] -- Someone who upgrades their software, runs
sidechain full nodes, and actively moves money to and
from these.<br>
<br>
<br>
On 7/12/2017 6:43 PM, Tao Effect wrote:<br>
</div>
<blockquote type=3D"cite">
=20
=20
<div><br>
</div>
<div>I am now looking closer again at step
number 4 in the Drivechain specification [2]:</div>
<div><br>
</div>
<blockquote style=3D"margin:0 0 0 40px;border:none;paddin=
g:0px">
<div>
<div>4. Everyone waits for a period of,
say, 3 days. This gives everyone an opportunity
to make sure the same WT^ is in both the Bitcoin
coinbase and the Sidechain header. If they=E2=80=99=
re
different, everyone has plenty of time to
contact each other, figure out what is going on,
and restart the process until its right.</div>
</div>
</blockquote>
<div>It seems to me that where our
disagreement lies is in this point.</div>
<div>The Drivechain spec seems to claim that
its use of anyone-can-pay is the same as P2SH (and
in later emails you reference SegWit as well). Is
this really true?</div>
</blockquote>
FYI that document is nearly two years old, and although
it is still overwhelmingly accurate, new optimizations
allow us (I think) to push the waiting period to several
weeks and the total ACK counting period up to several
months.<br>
<br>
[DC#0] Yes<br>
[DC#1] Yes<br>
[DC#2] Yes<br>
[DC#3] Yes<br>
<br>
Because if a node doesn't have the sidechain's
information, it will just assume every withdrawal is
valid. This is comparable to someone who still hasn't
upgraded to support P2SH, in cases [DC#0] and [#1].<br>
<br>
(And this is the main advantage of DC over extension
blocks).<br>
<br>
<br>
<blockquote type=3D"cite">
<div>2. Per the question in [1], it's my
understanding that P2SH transactions contain all of
the information within themselves for full nodes to
act as a check on miners mishandling the
anyone-can-spend nature of P2SH transactions.
However, that does not seem to be the case with WT^
transactions.</div>
</blockquote>
[DC#0] They do.<br>
[DC#1] They do.<br>
[DC#2] They do.<br>
[DC#3] They do.<br>
<br>
Again, from the perspective of a mainchain user, every
withdrawal is valid.<br>
<br>
<br>
<blockquote type=3D"cite">
<div>In P2SH txns, there is no need for
anyone to, as the Drivechain spec says, "to contac=
t
each other, figure out what is going on". Everythi=
ng
just automatically works.</div>
</blockquote>
There is no *need* to this in Drivechain, either, for
[DC#0] or [DC#1].<br>
<br>
[DC#2] and [DC#3] would certainly have an interest in
understanding what is going on, but that has absolutely
nothing whatsoever to do with Bitcoin Core and so is
off-topic for this mailing list.<br>
<br>
<br>
<blockquote type=3D"cite">
<div>If the security of WT^ transactions
could be brought up to actually be in line with the
security of P2SH and SegWit transactions, then I
would have far less to object to.</div>
</blockquote>
Somehow I doubt it.<br>
<br>
<br>
Paul<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<p><br>
</p>
</div></div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>
--001a1137558c4186b3055432c00e--
|