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: <truthcoin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 06CCEB56
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Jun 2017 11:54:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f170.google.com (mail-qt0-f170.google.com
[209.85.216.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3AEC6EB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Jun 2017 11:54:51 +0000 (UTC)
Received: by mail-qt0-f170.google.com with SMTP id u12so131469675qth.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 20 Jun 2017 04:54:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=subject:to:references:from:cc:message-id:date:user-agent
:mime-version:in-reply-to:content-language;
bh=tXg/XhkCSg4zNoZmCI1zrw4TqTOfwac8Mol+iLi+L4U=;
b=CYuxg9t833TtyeExVdMfsg+P2pE+876jz7I3gUhZmvrz6QiOgdpnwxvSpLvO/zI1Z9
2O81QUN2RRGLVgLMti5sVyFkC64Je+EgP4hxtfRvCSrzwrs4Hh05LAC5MoNtkwd0vXXS
wZ8OncP8/g38KhNJWaxThHaMmPJWxqebkc7ZP5KFxTRBNRfos9oj5SHKUX6FCb8cI2AW
JLgxRLEpqfm0w4Cjdo912ChjBlrQnGCudZpXWdIfLDT/mIYA2zD1i3yMBvGUlyN1OF72
zurDdVLk71g4lf3w2Cd8El8s3ngwxc87zs1ttey2F3tjAvdxiOuehZzhVZB33K8vI+Lm
Y8hQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:subject:to:references:from:cc:message-id:date
:user-agent:mime-version:in-reply-to:content-language;
bh=tXg/XhkCSg4zNoZmCI1zrw4TqTOfwac8Mol+iLi+L4U=;
b=itMLZdRfRybjhN2GABuATx/XscR9vVokktYLWVLWrO4Fi+TrnzXwqP4QffcPezdtZx
AkwRmFJP/4gs4+bAeUC8Y8CAy2txIMO12vfdvh+HPtXrx9AK3pnuItb1u2of4+RTn/o2
q2YBxYyIF0/v6v2KL8P1ejPt6xJBuKcGf6x5G1mS5FMDlk+stvDWVEaTv3zHbrQzLbtt
IWTaLZ/cPFaMtZwcTZQdt2OEZ6dVvo5fXagF31bGr2I55EXIjm6bMlEt95Wcy3KolrLc
sP6htP2bIh5LTbnAXAkLheuIfluqKnHHdNdJYT+DbjtGWHQQBq/fpL11KKrT5mPw1Ahc
9+7g==
X-Gm-Message-State: AKS2vOyZ9z473mcHZJ6BQ7KIBDjEd4MXWfx3Nck5bjFsEruj6+126raj
Q5Zfj1Fcddgl8R0k
X-Received: by 10.200.47.60 with SMTP id j57mr4081211qta.175.1497959689910;
Tue, 20 Jun 2017 04:54:49 -0700 (PDT)
Received: from [192.168.1.102] (ool-45726efb.dyn.optonline.net.
[69.114.110.251]) by smtp.googlemail.com with ESMTPSA id
f8sm7967846qke.52.2017.06.20.04.54.48
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 20 Jun 2017 04:54:48 -0700 (PDT)
To: Erik Aronesty <erik@q32.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>
<CAJowKgLJW=kJhcN4B7TbWXLb7U51tzYU3PFOy1m8JqKXqFsU4A@mail.gmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
Message-ID: <33d98418-10f0-3854-a954-14985d53e04b@gmail.com>
Date: Tue, 20 Jun 2017 07:54:52 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101
Thunderbird/52.2.0
MIME-Version: 1.0
In-Reply-To: <CAJowKgLJW=kJhcN4B7TbWXLb7U51tzYU3PFOy1m8JqKXqFsU4A@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------88D16E39E224D559E3C1BCD0"
Content-Language: en-US
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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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: Tue, 20 Jun 2017 11:54:53 -0000
This is a multi-part message in MIME format.
--------------88D16E39E224D559E3C1BCD0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Hi Erik,
As you know:
1. If a sidechain is merged mined it basically grows out of the existing
Bitcoin mining network. If it has a different PoW algorithm it is a new
mining network.
2. The security (ie, hashrate) of any mining network would be determined
by the total economic value of the block. In Bitcoin this is
(subsidy+tx_fees)*price, but since a sidechain cannot issue new tokens
it would only be (tx_fees)*price.
Unfortunately the two have a nasty correlation which can lead to a
disastrous self-fulfilling prophecy: users will avoid a network that is
too insecure; and if users avoid using a network, they will stop paying
txn fees and so the quantity (tx_fees)*price falls toward zero, erasing
the network's security. So it is quite problematic and I recommend just
biting the bullet and going with merged mining instead.
And, the point may be moot. Bitcoin miners may decide that, given their
expertise in seeking out cheap sources of power/cooling, they might as
well mine both/all chains. So your suggestion may not achieve your
desired result (and would, meanwhile, consume more of the economy's
resources -- some of these would not contribute even to a higher hashrate=
).
Paul
On 6/19/2017 1:11 PM, Erik Aronesty wrote:
> It would be nice to be able to enforce that a drivechain *not* have
> the same POW as bitcoin.
>
> I suspect this is the only way to be sure that a drivechain doesn't
> destabilize the main chain and push more power to miners that already
> have too much power.
>
>
> On Mon, Jun 19, 2017 at 12:04 PM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
> Hi Greg,
>
> Responses below:
>
> On 6/18/2017 5:30 PM, Tao Effect wrote:
> > In Drivechain, 51% of miners have total control and ownership
> over all
> > of the sidechain coins.
>
> It would not be accurate to say that miners have "total" control.
> Miners
> do control the destination of withdrawals, but they do not control =
the
> withdrawal-duration nor the withdrawal-frequency.
>
> So, if miners wish to 'steal' from a sidechain, they _can_ initiate=
a
> theft, but they can not change the fact that their malfeasance will=
be
> [a] obvious, and [b] on display for a long period of time.
>
> We might draw a comparison between:
>
> 1. Classic Theft -- A majority hashrate reorganizes the main Bitc=
oin
> chain to double-spend funds (or coordinate with someone who is
> double-spending). This is prevented/discouraged by waiting for many=
> confirmations.
> 2. Channel Theft -- A majority hashrate assists a Lightning-Network=
> thief, by censoring the punitive audit txn (possibly by exploiting
> some
> excuse regarding fullness of blocks, or possibly induced to do so
> by the
> thief provably splitting the proceeds with miners). This is
> prevented/discouraged by using lengthy custodial periods, paying hi=
gh
> fees with your attacker's money, and using
> fungibility/non-communication
> to interact with miners as little as possible (so as to frame LN-th=
eft
> as undermining the entire LN system, and not merely a single traged=
y).
> 3. Drivechain Theft -- A majority hashrate initiates an
> unrepresentative
> withdrawal from some sidechain. This is prevented/discouraged by on=
ly
> using 'popular' sidechains (those that [a] increase the usefulness
> ("market price") of bitcoin, and [b] generate tx fees for miners).
> It is
> also discouraged by the fact that egregious theft would probably
> end the
> sidechain experiment, meaning that all present and future sidechain=
s
> would be forever unavailable (and unable to buoy the price or the t=
x
> revenues).
>
> I do not think that any of the three stands out as being categorica=
lly
> worse than the others, especially when we consider the
> heterogeneity of
> use-cases and preferences. As Luke-Jr has been pointing out on soci=
al
> media recently, the very group which is more associated with
> miners (and
> explicitly more willing to trust them, ie Bitcoin Unlimited et al),=
> happens to be the same group that would be expected to make use of =
a
> LargeBlock drivechain. Some can argue that one type of security is
> more
> "cryptographic" than others, but I think this is misguided (how man=
y
> 'bits' of security does each have?) -- imho, all three security mod=
els
> are 'game theoretic' (neither computer scientific, nor cryptographi=
c).
>
> More importantly, before a miner has any "control" over the sidecha=
in
> coins, users must voluntarily agree to subject themselves to these =
new
> rules. This is similar to how an arbitrary piece of (open source)
> software can have "total" control over your computer...if you
> choose to
> install it.
>
> > Thus the effect of Drivechain appears to be the creation of a
> new kind
> > of digital border imposed onto the network ...
>
> I'm not sure it would "create a border", given that sidechains are
> currently not accessible at all. If anything drivechain cuts a
> door into
> an existing impassible border.
>
> > ... where everyone hands over ownership of their Bitcoins to a
> > /single/ mining cartel when they wish to interact with /any/ side=
chain.
>
> The qualifier "/any/ sidechain" would seem to imply that there is
> a way
> to do sidechains that does not involve handing over some control
> to 51%
> hashrate...I think this is false (even in the fabled case of
> ZK-SNARKS).
> The first thing I do in the drivechain spec (
> truthcoin.info/blog/drivechain
> <http://truthcoin.info/blog/drivechain> ) is explain why.
>
> > Drivechain would be a reasonable idea if that weren't the case, b=
ut
> > since it is, Drivechain now introduces a very real possible futur=
e
> > where Bitcoins can be confiscated by the Chinese government in
> exactly
> > the same manner that the Chinese government today confiscates
> > financial assets in other financial networks within China.
>
> Yes, but money could also be confiscated from _any_ Bitcoin users
> (Chinese or otherwise) using any of the three methods I mentioned
> above.
> And confiscation could strike Chinese Bitcoin users if they decided=
to
> sell their Bitcoin for Chinese Yuan, which they then deposited in a=
> Chinese bank. Or if they sold their Bitcoin for an Altcoin
> controlled by
> the Chinese govt in some other way.
>
> It is not up to the members of this list to decide, USSR style, wha=
t
> other people are allowed to do with their own money.
>
> The exceptions to this rule would be (ie, "bitcoin-dev should care
> about
> what users are doing when..."):
>
> 1. [Unreasonable use of Reviewer Time] The user's use-case is eith=
er
> nonexistent (ie "no one wants that"), or totally unachievable ("we
> can't
> do that") thus rendering the conversation a complete waste of time =
/
> reviewer attention.
> 2. [Harmful Interference] The user's use-case would impose harm on
> some
> existing use-case(s).
>
> No reasonable person will claim the first, given today's scaling
> debate
> (not to mention today's 'bitcoin dominance index'). Therefore, crit=
ics
> must claim the second (as, for example, Peter Todd has been doing o=
n
> this list).
>
> Which is why I narrowly focus on inter-chain harms [1], leading
> ultimately to a focus on the mining ecosystem [2,3] and the
> development
> of Blind Merged Mining [4].
>
> [1]
> https://www.youtube.com/watch?v=3D0goYH2sDw0w&list=3DPLw8-6ARlyVciN=
jgS_NFhAu-qt7HPf_dtg&index=3D1
> <https://www.youtube.com/watch?v=3D0goYH2sDw0w&list=3DPLw8-6ARlyVci=
NjgS_NFhAu-qt7HPf_dtg&index=3D1>
> [2] http://www.truthcoin.info/blog/mirage-miner-centralization/
> <http://www.truthcoin.info/blog/mirage-miner-centralization/>
> [3] http://www.truthcoin.info/blog/mining-threat-equilibrium/
> <http://www.truthcoin.info/blog/mining-threat-equilibrium/>
> [4] http://www.truthcoin.info/blog/blind-merged-mining/
> <http://www.truthcoin.info/blog/blind-merged-mining/>
> [5] http://www.truthcoin.info/blog/measuring-decentralization/
> <http://www.truthcoin.info/blog/measuring-decentralization/>
>
> > 1. The Bitcoin network centralizes more, because more power (both=
> > financial power and power in terms of capability/control) is gran=
ted
> > to miners.
>
> I think that one has some duty to very clearly define something (li=
ke
> "mining centralization" [2] or "centralization" [5]) before
> complaining
> about it. I feel that people will occasionally use selfless complai=
nts
> to accomplish a selfish goal...especially when the artificial selfl=
ess
> part is hard to discuss by virtue of its being poorly defined
> (especially vague or abstract items like "the company", "our countr=
y",
> etc). For example, those who take it upon themselves to "defend" "t=
he
> Bitcoin community" may have exactly that in mind as their primary
> goal...but they may also end up with more visibility (and with it:
> more
> influence, more job offers, more conference invites, more friends,
> etc)
> and they may also end up with a megaphone for which to broadcast th=
eir
> other views, or just a defend-able excuse for bragging loudly
> about how
> great cypherpunks are and/or how devoted they-in-particular are to =
the
> cypherpunk tribe, et cetera. To avoid this problem in my own techni=
cal
> discourse, I try to avoid abstractions like "centralization" until =
I
> have defined them [2,5].
>
> You have defined centralization above, but the definition is itself=
> vague to the point where I do not think even you actually endorse i=
t.
> For example, you would need to say that Bitcoin centralizes
> whenever the
> exchange rate increases (as this grants additional financial power =
to
> miners) or when any new user joins Bitcoin, or when tx fee revenues=
> increase for any reason. You might also be forced to say that LN
> centralizes Bitcoin (as LN grants new capability/control to
> miners), and
> probably even that Bitcoin becomes more centralized when developers=
> release new software (as this grants new capability to miners,
> specifically the ability to deny upgrades). This probably isn't
> what you
> meant, but since you did not clearly explain what you meant we have=
no
> way of knowing for sure.
>
> It seems to me that you reject the premise that BMM [4] addresses
> these
> issues. This is probably because BMM only addresses miner's
> interactions
> with each other, and it does not address miner abilities as a group=
in
> relation to other groups (for example, vs. users, developers,
> investors). But, as I consistently emphasize, these groups of
> people are
> free to ignore any sidechains that they do not like. In law there i=
s a
> saying 'volenti non fit injuria' which I would translate as "he who=
> volunteers cannot claim later to have been injured". This is a lega=
l
> theory, because otherwise everyone would be arbitrarily liable for
> choices beyond their control (ie, responsible for decisions of othe=
r
> unrelated people), which would be nonsense.
>
> > 3. Drivechain limits user's existing choice when it comes to who =
is
> > acting as custodian of their Bitcoins, from any trustworthy
> exchange,
> > down to a single mining cartel under the control of a single set
> of laws.
>
> Currently no (P2P) sidechains exist, and therefore the set of choic=
es
> today would seem to be more "limited" than in a post-sidechain futu=
re.
> (The set of options may decrease later, for ecological reasons, if =
and
> only if 'exchanges' are a strictly inferior option to 'sidechains' =
for
> some reason...I don't see why this would be the case. I also don't
> understand the emphasis on "exchanges" [SCs are much more like
> Altcoins,
> than exchanges] in the first place, nor the dubious qualifier
> "trustworthy".)
>
> --Paul
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
>
--------------88D16E39E224D559E3C1BCD0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi Erik,<br>
<br>
As you know:<br>
<br>
1. If a sidechain is merged mined it basically grows out of the
existing Bitcoin mining network. If it has a different PoW
algorithm it is a new mining network.<br>
2. The security (ie, hashrate) of any mining network would be
determined by the total economic value of the block. In Bitcoin
this is (subsidy+tx_fees)*price, but since a sidechain cannot
issue new tokens it would only be (tx_fees)*price.<br>
<br>
Unfortunately the two have a nasty correlation which can lead to a
disastrous self-fulfilling prophecy: users will avoid a network
that is too insecure; and if users avoid using a network, they
will stop paying txn fees and so the quantity (tx_fees)*price
falls toward zero, erasing the network's security. So it is quite
problematic and I recommend just biting the bullet and going with
merged mining instead.<br>
<br>
And, the point may be moot. Bitcoin miners may decide that, given
their expertise in seeking out cheap sources of power/cooling,
they might as well mine both/all chains. So your suggestion may
not achieve your desired result (and would, meanwhile, consume
more of the economy's resources -- some of these would not
contribute even to a higher hashrate).<br>
<br>
Paul<br>
<br>
<br>
<br>
On 6/19/2017 1:11 PM, Erik Aronesty wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAJowKgLJW=kJhcN4B7TbWXLb7U51tzYU3PFOy1m8JqKXqFsU4A@mail.gmail.com">
<div dir="ltr">
<div>It would be nice to be able to enforce that a drivechain
*not* have the same POW as bitcoin. <br>
<br>
</div>
<div>I suspect this is the only way to be sure that a drivechain
doesn't destabilize the main chain and push more power to
miners that already have too much power.<br>
</div>
<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Jun 19, 2017 at 12:04 PM, Paul
Sztorc via bitcoin-dev <span dir="ltr"><<a
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
target="_blank" moz-do-not-send="true">bitcoin-dev@lists.linuxfoundation.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Greg,<br>
<br>
Responses below:<br>
<span class=""><br>
On 6/18/2017 5:30 PM, Tao Effect wrote:<br>
> In Drivechain, 51% of miners have total control and
ownership over all<br>
> of the sidechain coins.<br>
<br>
</span>It would not be accurate to say that miners have
"total" control. Miners<br>
do control the destination of withdrawals, but they do not
control the<br>
withdrawal-duration nor the withdrawal-frequency.<br>
<br>
So, if miners wish to 'steal' from a sidechain, they _can_
initiate a<br>
theft, but they can not change the fact that their
malfeasance will be<br>
[a] obvious, and [b] on display for a long period of time.<br>
<br>
We might draw a comparison between:<br>
<br>
1. Classic Theft -- A majority hashrate reorganizes the
main Bitcoin<br>
chain to double-spend funds (or coordinate with someone who
is<br>
double-spending). This is prevented/discouraged by waiting
for many<br>
confirmations.<br>
2. Channel Theft -- A majority hashrate assists a
Lightning-Network<br>
thief, by censoring the punitive audit txn (possibly by
exploiting some<br>
excuse regarding fullness of blocks, or possibly induced to
do so by the<br>
thief provably splitting the proceeds with miners). This is<br>
prevented/discouraged by using lengthy custodial periods,
paying high<br>
fees with your attacker's money, and using
fungibility/non-communication<br>
to interact with miners as little as possible (so as to
frame LN-theft<br>
as undermining the entire LN system, and not merely a single
tragedy).<br>
3. Drivechain Theft -- A majority hashrate initiates an
unrepresentative<br>
withdrawal from some sidechain. This is
prevented/discouraged by only<br>
using 'popular' sidechains (those that [a] increase the
usefulness<br>
("market price") of bitcoin, and [b] generate tx fees for
miners). It is<br>
also discouraged by the fact that egregious theft would
probably end the<br>
sidechain experiment, meaning that all present and future
sidechains<br>
would be forever unavailable (and unable to buoy the price
or the tx<br>
revenues).<br>
<br>
I do not think that any of the three stands out as being
categorically<br>
worse than the others, especially when we consider the
heterogeneity of<br>
use-cases and preferences. As Luke-Jr has been pointing out
on social<br>
media recently, the very group which is more associated with
miners (and<br>
explicitly more willing to trust them, ie Bitcoin Unlimited
et al),<br>
happens to be the same group that would be expected to make
use of a<br>
LargeBlock drivechain. Some can argue that one type of
security is more<br>
"cryptographic" than others, but I think this is misguided
(how many<br>
'bits' of security does each have?) -- imho, all three
security models<br>
are 'game theoretic' (neither computer scientific, nor
cryptographic).<br>
<br>
More importantly, before a miner has any "control" over the
sidechain<br>
coins, users must voluntarily agree to subject themselves to
these new<br>
rules. This is similar to how an arbitrary piece of (open
source)<br>
software can have "total" control over your computer...if
you choose to<br>
install it.<br>
<span class=""><br>
> Thus the effect of Drivechain appears to be the
creation of a new kind<br>
</span>> of digital border imposed onto the network ...<br>
<br>
I'm not sure it would "create a border", given that
sidechains are<br>
currently not accessible at all. If anything drivechain cuts
a door into<br>
an existing impassible border.<br>
<br>
> ... where everyone hands over ownership of their
Bitcoins to a<br>
<span class="">> /single/ mining cartel when they wish to
interact with /any/ sidechain.<br>
<br>
</span>The qualifier "/any/ sidechain" would seem to imply
that there is a way<br>
to do sidechains that does not involve handing over some
control to 51%<br>
hashrate...I think this is false (even in the fabled case of
ZK-SNARKS).<br>
The first thing I do in the drivechain spec (<br>
<a href="http://truthcoin.info/blog/drivechain"
rel="noreferrer" target="_blank" moz-do-not-send="true">truthcoin.info/blog/drivechain</a>
) is explain why.<br>
<span class=""><br>
> Drivechain would be a reasonable idea if that weren't
the case, but<br>
> since it is, Drivechain now introduces a very real
possible future<br>
> where Bitcoins can be confiscated by the Chinese
government in exactly<br>
> the same manner that the Chinese government today
confiscates<br>
> financial assets in other financial networks within
China.<br>
<br>
</span>Yes, but money could also be confiscated from _any_
Bitcoin users<br>
(Chinese or otherwise) using any of the three methods I
mentioned above.<br>
And confiscation could strike Chinese Bitcoin users if they
decided to<br>
sell their Bitcoin for Chinese Yuan, which they then
deposited in a<br>
Chinese bank. Or if they sold their Bitcoin for an Altcoin
controlled by<br>
the Chinese govt in some other way.<br>
<br>
It is not up to the members of this list to decide, USSR
style, what<br>
other people are allowed to do with their own money.<br>
<br>
The exceptions to this rule would be (ie, "bitcoin-dev
should care about<br>
what users are doing when..."):<br>
<br>
1. [Unreasonable use of Reviewer Time] The user's use-case
is either<br>
nonexistent (ie "no one wants that"), or totally
unachievable ("we can't<br>
do that") thus rendering the conversation a complete waste
of time /<br>
reviewer attention.<br>
2. [Harmful Interference] The user's use-case would impose
harm on some<br>
existing use-case(s).<br>
<br>
No reasonable person will claim the first, given today's
scaling debate<br>
(not to mention today's 'bitcoin dominance index').
Therefore, critics<br>
must claim the second (as, for example, Peter Todd has been
doing on<br>
this list).<br>
<br>
Which is why I narrowly focus on inter-chain harms [1],
leading<br>
ultimately to a focus on the mining ecosystem [2,3] and the
development<br>
of Blind Merged Mining [4].<br>
<br>
[1]<br>
<a
href="https://www.youtube.com/watch?v=0goYH2sDw0w&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=1"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.youtube.com/watch?<wbr>v=0goYH2sDw0w&list=PLw8-<wbr>6ARlyVciNjgS_NFhAu-qt7HPf_dtg&<wbr>index=1</a><br>
[2] <a
href="http://www.truthcoin.info/blog/mirage-miner-centralization/"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://www.truthcoin.info/<wbr>blog/mirage-miner-<wbr>centralization/</a><br>
[3] <a
href="http://www.truthcoin.info/blog/mining-threat-equilibrium/"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://www.truthcoin.info/<wbr>blog/mining-threat-<wbr>equilibrium/</a><br>
[4] <a
href="http://www.truthcoin.info/blog/blind-merged-mining/"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://www.truthcoin.info/<wbr>blog/blind-merged-mining/</a><br>
[5] <a
href="http://www.truthcoin.info/blog/measuring-decentralization/"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://www.truthcoin.info/<wbr>blog/measuring-<wbr>decentralization/</a><br>
<span class=""><br>
> 1. The Bitcoin network centralizes more, because more
power (both<br>
> financial power and power in terms of
capability/control) is granted<br>
> to miners.<br>
<br>
</span>I think that one has some duty to very clearly define
something (like<br>
"mining centralization" [2] or "centralization" [5]) before
complaining<br>
about it. I feel that people will occasionally use selfless
complaints<br>
to accomplish a selfish goal...especially when the
artificial selfless<br>
part is hard to discuss by virtue of its being poorly
defined<br>
(especially vague or abstract items like "the company", "our
country",<br>
etc). For example, those who take it upon themselves to
"defend" "the<br>
Bitcoin community" may have exactly that in mind as their
primary<br>
goal...but they may also end up with more visibility (and
with it: more<br>
influence, more job offers, more conference invites, more
friends, etc)<br>
and they may also end up with a megaphone for which to
broadcast their<br>
other views, or just a defend-able excuse for bragging
loudly about how<br>
great cypherpunks are and/or how devoted they-in-particular
are to the<br>
cypherpunk tribe, et cetera. To avoid this problem in my own
technical<br>
discourse, I try to avoid abstractions like "centralization"
until I<br>
have defined them [2,5].<br>
<br>
You have defined centralization above, but the definition is
itself<br>
vague to the point where I do not think even you actually
endorse it.<br>
For example, you would need to say that Bitcoin centralizes
whenever the<br>
exchange rate increases (as this grants additional financial
power to<br>
miners) or when any new user joins Bitcoin, or when tx fee
revenues<br>
increase for any reason. You might also be forced to say
that LN<br>
centralizes Bitcoin (as LN grants new capability/control to
miners), and<br>
probably even that Bitcoin becomes more centralized when
developers<br>
release new software (as this grants new capability to
miners,<br>
specifically the ability to deny upgrades). This probably
isn't what you<br>
meant, but since you did not clearly explain what you meant
we have no<br>
way of knowing for sure.<br>
<br>
It seems to me that you reject the premise that BMM [4]
addresses these<br>
issues. This is probably because BMM only addresses miner's
interactions<br>
with each other, and it does not address miner abilities as
a group in<br>
relation to other groups (for example, vs. users,
developers,<br>
investors). But, as I consistently emphasize, these groups
of people are<br>
free to ignore any sidechains that they do not like. In law
there is a<br>
saying 'volenti non fit injuria' which I would translate as
"he who<br>
volunteers cannot claim later to have been injured". This is
a legal<br>
theory, because otherwise everyone would be arbitrarily
liable for<br>
choices beyond their control (ie, responsible for decisions
of other<br>
unrelated people), which would be nonsense.<br>
<span class=""><br>
> 3. Drivechain limits user's existing choice when it
comes to who is<br>
> acting as custodian of their Bitcoins, from any
trustworthy exchange,<br>
> down to a single mining cartel under the control of a
single set of laws.<br>
<br>
</span>Currently no (P2P) sidechains exist, and therefore
the set of choices<br>
today would seem to be more "limited" than in a
post-sidechain future.<br>
(The set of options may decrease later, for ecological
reasons, if and<br>
only if 'exchanges' are a strictly inferior option to
'sidechains' for<br>
some reason...I don't see why this would be the case. I also
don't<br>
understand the emphasis on "exchanges" [SCs are much more
like Altcoins,<br>
than exchanges] in the first place, nor the dubious
qualifier<br>
"trustworthy".)<br>
<span class="HOEnZb"><font color="#888888"><br>
--Paul<br>
</font></span>
<div class="HOEnZb">
<div class="h5"><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org"
moz-do-not-send="true">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a
href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<p><br>
</p>
</body>
</html>
--------------88D16E39E224D559E3C1BCD0--
|