summaryrefslogtreecommitdiff
path: root/71/7f2bf45afe5eb36a1cf49770792c9f352674d4
blob: efbd6e8634e41cf206c42fb4bd388c65cbde60ff (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
Return-Path: <bounce+33760e.2c141-bitcoin-dev=lists.linuxfoundation.org@suredbits.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id A2B43AB8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Sep 2017 20:14:36 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from so254-16.mailgun.net (so254-16.mailgun.net [198.61.254.16])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 290D912A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Sep 2017 20:14:34 +0000 (UTC)
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=suredbits.com;
	q=dns/txt; 
	s=mailo; t=1504901673; h=Content-Type: Cc: To: Subject: Message-ID:
	Date: From: References: In-Reply-To: MIME-Version: Sender;
	bh=TdjBzIcSuzhaLrxbiphggqpM0zAmTyM3CgbSG97Y5zs=;
	b=gv5HCUzmBl2YpFChMkRQ15NIdPdOF4t+XcWQWg6frr1q3nN/3+euopfHsq+lcxKWlg+qqjur
	xWcok2ARYLLjnsrKkQcG3/kPcnEgXRi5u6cfFmjP15/agtzQCZS9ry1El13J9utY7PyhGesH
	BTQhIg1xLMz3IgMw9nq/G2HqZck=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=suredbits.com; s=mailo;
	q=dns; h=Sender: MIME-Version: In-Reply-To: References: From: Date:
	Message-ID: Subject: To: Cc: Content-Type;
	b=koC6S6yN9R+xHh6Runs36ODn6XOAI5/ZlO9h0Adj5OSk+Bwa1zsy3Li+iVe1aWIdW0a1YD
	Zm55KGx0LFzMhBX35TijIhTszY9b20YOHpU6zemrG4XE1YJvwXCk72WtoRUqXVLv61bL+uSy
	tly12gShP9YmQTCJr1JFnaTI4cKWQ=
Sender: chris@suredbits.com
X-Mailgun-Sending-Ip: 198.61.254.16
X-Mailgun-Sid: WyI5MGYzNyIsICJiaXRjb2luLWRldkBsaXN0cy5saW51eGZvdW5kYXRpb24ub3JnIiwgIjJjMTQxIl0=
Received: from mail-it0-f47.google.com (mail-it0-f47.google.com
	[209.85.214.47])
	by mxa.mailgun.org with ESMTP id 59b2fa27.7ff6c84810f0-smtp-out-n01;
	Fri, 08 Sep 2017 20:14:31 -0000 (UTC)
Received: by mail-it0-f47.google.com with SMTP id c195so5222116itb.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 08 Sep 2017 13:14:31 -0700 (PDT)
X-Gm-Message-State: AHPjjUjzCwztPEpsYO9AJhHNr24SYZWWHGpbZBkUE8tkQZDEbTeLB8LG
	QwWMDiVI2CBOf1cuJEQx9GktObX0/F+oAe9HfHA=
X-Google-Smtp-Source: ADKCNb4gjZdArS1nlnT1ACN5A5KZwsIzVWDhHdgldhsO+TUCdTHt8VpcfxmuL0z5leKmeU7KSUzesOm15QgudSWTnYs=
X-Received: by 10.36.213.212 with SMTP id a203mr2627908itg.59.1504901670883;
	Fri, 08 Sep 2017 13:14:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.10.20 with HTTP; Fri, 8 Sep 2017 13:14:30 -0700 (PDT)
In-Reply-To: <Imrd8VOoGb1nVRp10RedyHoeJYajcvlhrwZQg9OtTk3vDMpc7DEFgw7CSQR_AiqNDwmMECV_fn53WY2i9NZcJKx2jtyd_psyQf6VNg3S7Gc=@protonmail.com>
References: <H7RPmZGfkVC8opGMMCW7Orav6yD05-AVB9bNtNU8C0hKYokiXL32VSmn0wkjn77qh4MvacPOePdVQ5gQZuAMF6q2oEuvKDSu6crNcEoXx_0=@protonmail.com>
	<CAGL6+mFHe_SfMea1oMZ3n-G3ey9yToAvTMTcfdxJ5qDD1dTXyQ@mail.gmail.com>
	<Cc5DW6tb6_Xhe3DaXisRJzqYtnWHCGcHkOsXDJLIRvv9WP2lCVocsM1atkdQOSE8-reUbCp_ZKfEDIaA0Qh5CRwFeIrHFJcNkFsqmZx70XQ=@protonmail.com>
	<Imrd8VOoGb1nVRp10RedyHoeJYajcvlhrwZQg9OtTk3vDMpc7DEFgw7CSQR_AiqNDwmMECV_fn53WY2i9NZcJKx2jtyd_psyQf6VNg3S7Gc=@protonmail.com>
From: Chris Stewart <chris@suredbits.com>
Date: Fri, 8 Sep 2017 15:14:30 -0500
X-Gmail-Original-Message-ID: <CAGL6+mFqrnTXOwse3Zuu-GuRYxgQQV9Bs9OUU+RmyUqOsm0UTQ@mail.gmail.com>
Message-ID: <CAGL6+mFqrnTXOwse3Zuu-GuRYxgQQV9Bs9OUU+RmyUqOsm0UTQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Content-Type: multipart/alternative; boundary="94eb2c05d7c483e5bc0558b33941"
X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM
	autolearn=disabled 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, 09 Sep 2017 03:28:16 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Sidechain headers on mainchain (unification of
 drivechains and spv proofs)
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, 08 Sep 2017 20:14:36 -0000

--94eb2c05d7c483e5bc0558b33941
Content-Type: text/plain; charset="UTF-8"

Hi ZmnSCPxj,

However, a lockbox on one chain is a WT on the other
> chain.  We can create a free lockbox on Ess, then use that lockbox as
> a WT on Tee, inflating TeeCoin.


I'm not sure if I follow what you are saying here. What do you mean by
'free lockbox'? I was assuming that I created an arbitrary blockchain, say
ChrisChain, that is NOT pegged to the bitcoin blockchain? I.e. the tokens
on ChrisChain are worthless. Then I create a lockbox on ChrisChain with my
worthless tokens and attempt to transfer them into TeeCoin's chain? However
this doesn't make sense with


However, this parameter is used to determine if it is a WT.  Sidechain
> consensus should require that freely-created lockboxes set this
> parameter to 0, so that a side block that creates free lockboxes where
> this parameter is non-zero is an invalid side block.  Then a sidechain
> will only treat a lockbox on another chain as a WT if the wtFlag
> parameter is nonzero.  This way, freely-created lockboxes are not
> valid WT.  Valid WT must lock actual, already unlocked coins, not
> create new locked coins.
>

because I could arbitrarily set this parameter to 0. It seems that a
sidechain upon inception should pay all of it's tokens to a single UTXO and
prevent minting of coins after that. I'm fairly certain this is what
elements does in it's genesis block.

The is unrelated to the problem above, but it will be a problem in
sidchain-headers-on-mainchain if we have a limited amount of mining slots
in the coinbase_tx output vector.

Let us assume we have a fixed set of sidechain slots in the coinbase output
vector, in this case 10. However there are 15 competing sidechains for
these 10 slots. It may be possible for sidechains (say 15 sidechains) to
compete indefinitely for these 10 slots -- causing indefinite forks. Let us
say sidechain 10 and sidechain 11 alternate block hashes in
coinbase_tx.vout[10] output. This means that a WT^ will never be considered
valid because it will appear to mainchain miners that there are competing
forks of the SAME sidechain, when in reality it is two unique sidechains
competing to mine the the limited coinbase output vector space.

-Chris

On Fri, Sep 8, 2017 at 9:56 AM, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> Good morning,
>
> Chris mentioned the use of OP_WITHDRAWPROOFVERIFY.  I've come to realize
> that this is actually superior to use OP_WITHDRAWPROOFVERIFY with a
> sidechain-headers-on-mainchain approach.
>
> Briefly, a payment to OP_WITHDRAWPROOFVERIFY is an instruction to transfer
> value from the mainchain to a sidechain.  Thus, a payment to
> OP_WITHDRAWPROOFVERIFY includes the sidechain to pay to, and a commitment
> to a sidechain address (or whatever is the equivalent to a sidechain
> address).
>
> Various OP_WITHDRAWPROOFVERIFY explanations exist.  Most of them include
> OP_REORGPROOFVERIFY.  With sidechain-headers-on-mainchain, however, there
> is
> no need for reorg proofs.  This is because, the mainchain can see, in real
> time, which branch of the sidechain is getting extended.  Thus if someone
> attempts to defraud a sidechain by forking the sidechain to an invalid
> state, sidechainers can immediately detect this on the mainchain and
> immediately act to prevent the invalid fork from being advanced.  After
> all, a reorg proof is really just an SPV proof that is longer than some
> previous SPV proof, that shows that the previous SPV proof is incorrect,
> by showing that the block at the specified height of the WT is not present
> on a longer SPV proof.
>
> Since sidechain-headers-on-mainchain implies merge mining of sidechains,
> with no option to have independent proof-of-work of sidechains, the
> sidechain's entire history is recorded on the mainchain, visible to all
> mainchain nodes.
>
> --
>
> An advantage of sidechain-headers-on-mainchain is a side-to-side peg
> without
> passing through the mainchain.
> That is, a 2-way peg between any two chains, whether side or main.
>
> Sidechains supporting side-to-side transfer would require supporting
> OP_WITHDRAWPROOFVERIFY, but not any of the other parts of sidechains.
>
> We must consider a WT format (withdrawal transaction) that is compatible
> with an OP_WITHDRAWPROOFVERIFY Bitcoin transaction.
>
> ***That is, a lockbox UTXO on one chain is a WT on another chain.***
>
> Sidechains need not follow the mainchain format for its normal
> transactions, only for WT transactions that move coins across chains.
>
> For this, mainchain should also have its own "sidechain ID".  Perhaps a
> sidechain ID of 0 would be appropriate for mainchain, as its status as
> mainchain.
>
> Suppose we have two sidechains, Ess and Tee, both of which support
> side-to-side pegs.
>
> An Ess fullnode is a Bitcoin fullnode, but an Ess fullnode is not
> necessarily a Tee fullnode, and vice versa.
>
> A lockbox redemption in sidechain-headers-on-mainchain is simply a spend of
> a lockbox, pointing to the sidechain header containing WT, the merkle tree
> path to the WT transaction from the h* commitment of the header, the output
> which locks, and so on as per usual OP_WITHDRAWPROOFVERIFY.
>
> Then a sidechain can create tokens from nothing, that are locked in a
> OP_WITHDRAWPROOFVERIFY lockbox; this is the only way to create sidecoin.
> When transferring into a sidechain from mainchain, or anywhere, the
> sidechain either creates tokens locked into OP_WITHDRAWPROOFVERIFY, or
> looks for an existing UTXO with OP_WITHDRAWPROOFVERIFY from the source
> chain and spends them (the latter is preferred as it is fewer
> transactions and less space on the sideblock, reducing sidechain fees).
>
> OP_WITHDRAWPROOFVERIFY on a sidechain would query the mainchain fullnodes.
> Whatever rules allow lockbox unlocking on mainchain, will also be the same
> rules that allow lockbox unlocking on sidechains.
> A mainchain RPC can even be made to simplify sidechain verification of
> side-to-side pegs, and to ensure that sidechains follow the same consensus
> rules for OP_WITHDRAWPROOFVERIFY.
>
> So if we want transfer TeeCoin to EssCoin, we spend into a
> OP_WITHDRAWPROOFVERIFY lockbox on Teechain pointing to Esschain (i.e. a
> Tee->Ess lockbox).  This lockbox is itself a WT from the point of view of
> Esschain.  On Esschain, we look for an existing Ess->Tee lockbox, or
> create a Ess->Tee lockbox of our own for a EssCoin fee.  Then we create a
> spend of the Ess->Tee lockbox on Esschain, wait until spending is
> possible, and then post that transaction on Esschain.
>
> Again, with sidechain-headers-on-mainchain, reorg proofs are unnecessary,
> since any invalid chain should be quickly buried by a valid chain,
> unless the economic majority decides that a sidechain is not worth
> protecting.
>
> --
>
> All is not well, however.  Remember, on a sidechain, we can create new
> sidecoin for free, provided they are in a lockbox.  Unlocking that
> lockbox would require a valid WT on the chain that the lockbox is
> dedicated to.  However, a lockbox on one chain is a WT on the other
> chain.  We can create a free lockbox on Ess, then use that lockbox as
> a WT on Tee, inflating TeeCoin.
>
> Instead, we add an additional parameter, wtFlag, to
> OP_WITHDRAWPROOFVERIFY.
> This parameter is ignored by OP_WITHDRAWPROOFVERIFY opcode.
>
> However, this parameter is used to determine if it is a WT.  Sidechain
> consensus should require that freely-created lockboxes set this
> parameter to 0, so that a side block that creates free lockboxes where
> this parameter is non-zero is an invalid side block.  Then a sidechain
> will only treat a lockbox on another chain as a WT if the wtFlag
> parameter is nonzero.  This way, freely-created lockboxes are not
> valid WT.  Valid WT must lock actual, already unlocked coins, not
> create new locked coins.
>
> On Bitcoin, of course, this parameter must always be nonzero, since
> freely-created lockboxes are not allowed on mainchain, as asset
> issuance on mainchain is already fixed.
>
> --
>
> Let us now flesh out how WT and lockboxes look like.  As we mentioned, a
> lockbox on one chain is a WT on the destination chain.  Or to be more
> precise, what a destination chain sees as a WT, is a lockbox on the source
> chain.
>
> Thus, a lockbox is a Bitcoin-formatted transaction output paying to the
> scriptPubKey:
>
>   <sidechain address commitment> <sidechain ID> OP_WITHDRAWPROOFVERIFY
>
> (assuming a softfork, additional OP_DROP operations may occur after
> OP_WITHDRAWPROOFVERIFY)
>
> Suppose the above lockbox is paid to in the Bitcoin mainchain, with the
> sidechain ID being the ID of Esschain.  This is itself a WT transaction
> from the point of view of Esschain, on the principle that a lockbox on
> one chain is a WT on another chain.
>
> Assuming Esschain is a brand-new sidechain, it has no EssCoins yet.  The
> sidechain allows the arbitrary creation of sidecoin provided the new
> sidecoins are in a lockbox whose sidechain address commitment is 0.  So
> in Esschain, we create the same coins on a UTXO paying to the
> scriptPubKey:
>
>   0 0 OP_WITHDRAWPROOFVERIFY
>
> The first 0 is the sidechain address commitment, which is 0 since this
> output was not created by transferring to a sidechain; we
> reuse the sidechain address commitment as the wtFlag.  The
> second 0 is the mainchain's ID.  The above is a lockbox from the point of
> view of Esschain.  It is not a WT on mainchain, however, because the
> sidechain address commitment is 0, which we use also as the wtFlag
> parameter.
>
> Now, how does a main-to-side peg work?  After creating the above output on
> Esschain, we now spend the output with the below scriptSig:
>
>   <mainchain output ID> <mainchain WT transaction> <merkle path to WT
> transaction> <mainchain block hash>
>
> On Esschain, OP_WITHDRAWPROOFVERIFY then verifies that the mainchain block
> hash is a valid past block of the mainchain, then locates the mainchain
> header.  It then checks the merkle tree path to the mainchain WT
> transaction,
> confirming that the mainchain contains that transaction, and confirms that
> the
> indicated output is in fact, a payment to an OP_WITHDRAWPROOFVERIFY, which
> pushes the Esschain ID, and with a nonzero sidechain address commitment.
>
> (Esschain also needs to ensure that a single WT is not used to unlock
> multiple lockboxes on Esschain; the easiest way is to add it to a set,
> but this set cannot be pruned; other ways of ensuring only a WT is only
> used to unlock once might be designed)
>
> On Esschain, the sidechain does one final check: the transaction that
> spends
> an OP_WITHDRAWPROOFVERIFY must have an output that pays to the sidechain
> address committed to, and that output's value must be the same as the value
> locked in the mainchain.
>
> (for now, I think all lockboxes must have the same fixed amount, for
> simplicity)
>
> Now suppose we want to convert back our EssCoin to Bitcoin.  We create a
> lockbox on Esschain, paying to the below:
>
>   <bitcoin P2SH address> 0 OP_WITHDRAWPROOFVERIFY
>
> The bitcoin P2SH address is mainchain address commitment; for simplicity
> we just use P2SH on mainchain as it can encode any address.  The 0 is the
> mainchain ID.  The above Esschain lockbox is itself a WT from Esschain to
> mainchain.
>
> Then, we look for an unspent lockbox on Esschain whose sidechain ID is the
> Esschain ID.  Note that we can select any lockbox with the correct
> sidechain ID, regardless of the sidechain address commitment it may have.
>
> Locating an appropriate mainchain lockbox for Esschain coins, we then
> provide the below scriptSig, paying out to the bitcoin P2SH address we
> selected:
>
>   <esschain output ID> <esschain WT tx> <merkle path to WT tx> <esschain
> block header hash>
>
> On mainchain, we check that the indicated sidechain block header hash is a
> block header on the longest chain of Esschain.  We check it has sufficient
> depth.  Then we check if the merkle path to the WT tx is correct and goes
> to esschain WT tx.  Finally, we check the indicated output ID, and check
> that
> it is indeed an Esschain lockbox dedicated to mainchain.  Finally, we check
> that the transaction has an output that spends the lockbox amount to the
> specified bitcoin P2SH address.
>
> (similarly mainchain nees to ensure that the Esschain WT is only used
> once)
>
> The key insight here is that side-to-side pegs are just like side-to-main
> pegs.  Suppose instead we want to transfer our coins from Esscoin to
> Teecoin.  We would instead pay to the following lockbox on Esschain:
>
>   <teecoin address commitment> <teechain ID> OP_WITHDRAWPROOFVERIFY
>
> Then a Teechain transaction spending some Tee->Ess lockbox (or a fresh
> lockbox if there are no Tee->Ess lockboxes on Teechain) is created.
> We proceed as if it were a side-to-main peg, except it is a peg to
> Teechain, either creating or unlocking TeeCoins.  Indeed, mainchain
> fullnodes may even provide an RPC for checking OP_WITHDRAWPROOFVERIFY,
> so as to reduce risk that a sidechain breaks consensus due to buggy
> code.
>
> --
>
> All is still not well with side-to-side pegs, however.
>
> Suppose the economic majority decides that Esschain must die.  Perhaps it
> has some irrecoverable security bug, perhaps it adds features that allow
> Esschain fullnodes to kill baby seals, perhaps a successful theft of
> Esschain lockboxes was performed and Esscoins are now functionally
> worthless.  Killing a sidechain is done by bribing miners to put invalid
> values into h*, and thus stealing Bitcoin->Ess lockboxes.
>
> If Esschain dies, however, and the economic majority is not prepared to
> keep
> Esschain dead, it is possible to unlock Tee->Ess lockboxes on Teechain.
> Unlocking existing Tee->Ess lockboxes on Teechain is safe, since they
> represent coins that were locked into Bitcoin->Tee lockboxes.  However,
> it is still possible to create "free" Tee->Ess lockboxes on Teechain, then
> provide an invalid Tee->Ess WT lockbox on the now-moribund Esschain to
> unlock the free Tee->Ess lockbox on Teechain, inflating TeeCoin value.
> Thus in the presence of side-to-side pegs, the death of even one sidechain
> represents the death of every other sidechain!
>
> Thus, to properly kill Esschain, the economic majority should spam the
> Esschain headers slot with a fixed value, say 0, forever.  This makes it
> very difficult to create a Tee->Ess WT lockbox on Esschain, as you would
> now be able to reverse a one-way hash function.
>
> Alternatively, Teechain can softfork so that Tee->Ess lockboxes are no
> longer creatable or spendable.  However, the death of Esschain requires
> that all other sidechains, including Youchain, Veechain, Dubyachain, and
> so on, to softfork similarly.
>
> Perhaps both can be done: first the economic majority wanting to kill
> Esschain starts spamming it with invalid spends of Bitcoin->Ess lockboxes,
> then when all Bitcoin->Ess lockboxes have been stolen, spam it with 0s
> until all other sidechains have banned free Ess lockboxes on their chains.
> Then, the economic majority can leave Esschain dead, and a later softfork
> of mainchain prevents Esschain from being extended and allows mainchain
> fullnodes to prune Esschain headers.
>
> --
>
> Thieves will still have the same difficulty stealing from sidechains, but
> now their payoff is increased.  If a thief wants to steal Esschain
> lockboxes, then it is possible to pack an invalid Esschain block full of
> invalid WT to other chains.  Even chains that don't have lockboxes to
> Esschain can create lockboxes to Esschain for free.  Thus, instead of
> stealing only one lockbox at a time on mainchain, the thief can steal one
> lockbox on mainchain, and on every sidechain that supports side-to-side
> pegs, at a time.  The risk/reward ratio may shift drastically in that case.
>
> However, this does mean that users of one chain must pay attention to
> attacks on other chains, not just the chain they use.  If Teechain has no
> side-to-side pegs, then Teechain users will not care if Esschain is under
> attack.  But if side-to-side pegs are allowed on Teechain, then Teechain
> users must also care about Esschain's health, as well as the health of
> every other sidechain in existence.  Mainchain is protected since free
> lockboxes are not creatable on mainchain.  Each sidechain is not; thus
> the user of any sidechain must also stand by users of every other
> sidechain, or else they all fall apart.  Of course, this could more
> simply lead to "I will not use Teechain even if it would be useful to me,
> because if I use Teechain, I have to care about Esschain and Youchain and
> whatever."
>
> --
>
> Side-to-side pegs are useful to allow better liquidity and provide
> arbitrage quickly between sidechains, without having to pass through
> mainchain.  Otherwise, Esscoin may be valued slightly lower than Bitcoin,
> then Teecoin valued slightly higher than Bitcoin, creating a larger
> difference between Esscoin and Teecoin values than what a full
> side-to-side peg could support.  2-way pegs from mainchain
> to sidechain stabilize sidecoin with respect to maincoin.  Side-to-side
> pegs stabilize all sidecoins to all other sidecoins.
>
> Side-to-side pegs are enabled implicitly by sidechain-headers-on-
> mainchain,
> as all sidechain fullnodes must necessarily be mainchain fullnodes, and
> any mainchain fullnode can judge the validity of any WT from any sidechain
> without a miner voting period.
>
> Side-to-side pegs are a generalization of main-to-side and side-to-main
> pegs.  A sidechain can simply implement OP_WITHDRAWPROOFVERIFY and allow
> free lockboxes, and that is sufficient for the sidechain to support
> imports of bitcoin from mainchain and from any other sidechain.
>
> Side-to-side pegs seem to imply that all pegs must have the same bitcoin
> value transferred.  What that value must be, is something that may be
> debated endlessly.
>
> A side-to-side peg is a cut-through of a side-to-main peg from
> one sidechain into a main-to-side peg into another sidechain.  If a
> withdrawal from side-to-main peg would be accepted by mainchain, then
> another sidechain could, in principle, accept a proof that would
> authorize a side-to-main peg directly as a side-to-side peg.
>
> Side-to-side pegs make attacks on sidechains more lucrative, as it
> becomes possible to print sidecoins by successfully attacking a
> different sidechain.
>
> Drivechain cannot implement side-to-side pegs, as WT validity is
> voted on by mainchain miners, and asking mainchain miners about
> side-to-side pegs requires mainchain miners to be aware of both
> sidechains.  Sidechain-headers-on-mainchain publishes SPV proofs
> continuously to the mainchain, and since any sidechain fullnode is
> also a mainchain fullnode (since sidechains are mergemined), then
> every sidechain fullnode is automatically capable of accessing
> and verifying SPV proofs for every other sidechain.
>
> However, the pegging here seems less flexible than the pegging
> supported by drivechain.  Drivechain lets pegs be any size, with
> miner voting being the basis of knowing how much money is owned
> by whom.
>
> Regards,
> ZmnSCPxj
>

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

<div dir=3D"ltr">Hi ZmnSCPxj,<br><br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex">However, a lockbox on one chain is a WT on the other<br><div>ch=
ain.=C2=A0 We can create a free lockbox on Ess, then use that lockbox as<br=
></div>a WT on Tee, inflating TeeCoin.</blockquote><div><br></div><div>I&#3=
9;m not sure if I follow what you are saying here. What do you mean by &#39=
;free lockbox&#39;? I was assuming that I created an arbitrary blockchain, =
say ChrisChain, that is NOT pegged to the bitcoin blockchain? I.e. the toke=
ns on ChrisChain are worthless. Then I create a lockbox on ChrisChain with =
my worthless tokens and attempt to transfer them into TeeCoin&#39;s chain? =
However this doesn&#39;t make sense with</div><div><br></div><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>However, this =
parameter is used to determine if it is a WT.=C2=A0 Sidechain<br></div><div=
>consensus should require that freely-created lockboxes set this<br></div><=
div>parameter to 0, so that a side block that creates free lockboxes where<=
br></div><div>this parameter is non-zero is an invalid side block.=C2=A0 Th=
en a sidechain<br></div><div>will only treat a lockbox on another chain as =
a WT if the wtFlag<br></div><div>parameter is nonzero.=C2=A0 This way, free=
ly-created lockboxes are not<br></div><div>valid WT.=C2=A0 Valid WT must lo=
ck actual, already unlocked coins, not<br></div>create new locked coins.</d=
iv></blockquote><div><br></div><div> because I could arbitrarily set this p=
arameter to 0. It seems that a sidechain upon inception should pay all of i=
t&#39;s tokens to a single UTXO and prevent minting of coins after that. I&=
#39;m fairly certain this is what elements does in it&#39;s genesis block. =
<br></div><div><br></div><div>The is unrelated to the problem above, but it=
 will be a problem in sidchain-headers-on-mainchain if we have a limited am=
ount of mining slots in the coinbase_tx output vector. <br></div><div><br><=
/div><div>Let us assume we have a fixed set of sidechain slots in the coinb=
ase output vector, in this case 10. However there are 15 competing sidechai=
ns for these 10 slots. It may be possible for sidechains (say 15 sidechains=
) to compete indefinitely for these 10 slots -- causing indefinite forks. L=
et us say sidechain 10 and sidechain 11 alternate block hashes in coinbase_=
tx.vout[10] output. This means that a WT^ will never be considered valid be=
cause it will appear to mainchain miners that there are competing forks of =
the SAME sidechain, when in reality it is two unique sidechains competing t=
o mine the the limited coinbase output vector space. <br></div><div><br></d=
iv><div>-Chris<br></div></div><div class=3D"gmail_extra"><br><div class=3D"=
gmail_quote">On Fri, Sep 8, 2017 at 9:56 AM, ZmnSCPxj <span dir=3D"ltr">&lt=
;<a href=3D"mailto:ZmnSCPxj@protonmail.com" target=3D"_blank">ZmnSCPxj@prot=
onmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Goo=
d morning,<br></div><div><br></div><div>Chris mentioned the use of OP_WITHD=
RAWPROOFVERIFY.=C2=A0 I&#39;ve come to realize<br></div><div>that this is a=
ctually superior to use OP_WITHDRAWPROOFVERIFY with a<br></div><div>sidecha=
in-headers-on-mainchain approach.<br></div><div><br></div><div>Briefly, a p=
ayment to OP_WITHDRAWPROOFVERIFY is an instruction to transfer<br></div><di=
v>value from the mainchain to a sidechain.=C2=A0 Thus, a payment to<br></di=
v><div>OP_WITHDRAWPROOFVERIFY includes the sidechain to pay to, and a commi=
tment<br></div><div>to a sidechain address (or whatever is the equivalent t=
o a sidechain<br></div><div>address).<br></div><div><br></div><div>Various =
OP_WITHDRAWPROOFVERIFY explanations exist.=C2=A0 Most of them include<br></=
div><div>OP_REORGPROOFVERIFY.=C2=A0 With sidechain-headers-on-<wbr>mainchai=
n, however, there is<br></div><div>no need for reorg proofs.=C2=A0 This is =
because, the mainchain can see, in real<br></div><div>time, which branch of=
 the sidechain is getting extended.=C2=A0 Thus if someone<br></div><div>att=
empts to defraud a sidechain by forking the sidechain to an invalid<br></di=
v><div>state, sidechainers can immediately detect this on the mainchain and=
<br></div><div>immediately act to prevent the invalid fork from being advan=
ced.=C2=A0 After<br></div><div>all, a reorg proof is really just an SPV pro=
of that is longer than some<br></div><div>previous SPV proof, that shows th=
at the previous SPV proof is incorrect,<br></div><div>by showing that the b=
lock at the specified height of the WT is not present<br></div><div>on a lo=
nger SPV proof.<br></div><div><br></div><div>Since sidechain-headers-on-mai=
nchain implies merge mining of sidechains,<br></div><div>with no option to =
have independent proof-of-work of sidechains, the<br></div><div>sidechain&#=
39;s entire history is recorded on the mainchain, visible to all<br></div><=
div>mainchain nodes.<br></div><div><br></div><div>--<br></div><div><br></di=
v><div>An advantage of sidechain-headers-on-mainchain is a side-to-side peg=
 without<br></div><div>passing through the mainchain.<br></div><div>That is=
, a 2-way peg between any two chains, whether side or main.<br></div><div><=
br></div><div>Sidechains supporting side-to-side transfer would require sup=
porting<br></div><div>OP_WITHDRAWPROOFVERIFY, but not any of the other part=
s of sidechains.<br></div><div><br></div><div>We must consider a WT format =
(withdrawal transaction) that is compatible<br></div><div>with an OP_WITHDR=
AWPROOFVERIFY Bitcoin transaction.<br></div><div><br></div><div>***That is,=
 a lockbox UTXO on one chain is a WT on another chain.***<br></div><div><br=
></div><div>Sidechains need not follow the mainchain format for its normal<=
br></div><div>transactions, only for WT transactions that move coins across=
 chains.<br></div><div><br></div><div>For this, mainchain should also have =
its own &quot;sidechain ID&quot;.=C2=A0 Perhaps a<br></div><div>sidechain I=
D of 0 would be appropriate for mainchain, as its status as<br></div><div>m=
ainchain.<br></div><div><br></div><div>Suppose we have two sidechains, Ess =
and Tee, both of which support<br></div><div>side-to-side pegs.<br></div><d=
iv><br></div><div>An Ess fullnode is a Bitcoin fullnode, but an Ess fullnod=
e is not<br></div><div>necessarily a Tee fullnode, and vice versa.<br></div=
><div><br></div><div>A lockbox redemption in sidechain-headers-on-mainchain=
 is simply a spend of<br></div><div>a lockbox, pointing to the sidechain he=
ader containing WT, the merkle tree<br></div><div>path to the WT transactio=
n from the h* commitment of the header, the output<br></div><div>which lock=
s, and so on as per usual OP_WITHDRAWPROOFVERIFY.<br></div><div><br></div><=
div>Then a sidechain can create tokens from nothing, that are locked in a<b=
r></div><div>OP_WITHDRAWPROOFVERIFY lockbox; this is the only way to create=
 sidecoin.<br></div><div>When transferring into a sidechain from mainchain,=
 or anywhere, the<br></div><div>sidechain either creates tokens locked into=
 OP_WITHDRAWPROOFVERIFY, or<br></div><div>looks for an existing UTXO with O=
P_WITHDRAWPROOFVERIFY from the source<br></div><div>chain and spends them (=
the latter is preferred as it is fewer<br></div><div>transactions and less =
space on the sideblock, reducing sidechain fees).<br></div><div><br></div><=
div>OP_WITHDRAWPROOFVERIFY on a sidechain would query the mainchain fullnod=
es.<br></div><div>Whatever rules allow lockbox unlocking on mainchain, will=
 also be the same<br></div><div>rules that allow lockbox unlocking on sidec=
hains.<br></div><div>A mainchain RPC can even be made to simplify sidechain=
 verification of<br></div><div>side-to-side pegs, and to ensure that sidech=
ains follow the same consensus<br></div><div>rules for OP_WITHDRAWPROOFVERI=
FY.<br></div><div><br></div><div>So if we want transfer TeeCoin to EssCoin,=
 we spend into a<br></div><div>OP_WITHDRAWPROOFVERIFY lockbox on Teechain p=
ointing to Esschain (i.e. a<br></div><div>Tee-&gt;Ess lockbox).=C2=A0 This =
lockbox is itself a WT from the point of view of<br></div><div>Esschain.=C2=
=A0 On Esschain, we look for an existing Ess-&gt;Tee lockbox, or<br></div><=
div>create a Ess-&gt;Tee lockbox of our own for a EssCoin fee.=C2=A0 Then w=
e create a<br></div><div>spend of the Ess-&gt;Tee lockbox on Esschain, wait=
 until spending is<br></div><div>possible, and then post that transaction o=
n Esschain.<br></div><div><br></div><div>Again, with sidechain-headers-on-<=
wbr>mainchain, reorg proofs are unnecessary,<br></div><div>since any invali=
d chain should be quickly buried by a valid chain,<br></div><div>unless the=
 economic majority decides that a sidechain is not worth<br></div><div>prot=
ecting.<br></div><div><br></div><div>--<br></div><div><br></div><div>All is=
 not well, however.=C2=A0 Remember, on a sidechain, we can create new<br></=
div><div>sidecoin for free, provided they are in a lockbox.=C2=A0 Unlocking=
 that<br></div><div>lockbox would require a valid WT on the chain that the =
lockbox is<br></div><div>dedicated to.=C2=A0 However, a lockbox on one chai=
n is a WT on the other<br></div><div>chain.=C2=A0 We can create a free lock=
box on Ess, then use that lockbox as<br></div><div>a WT on Tee, inflating T=
eeCoin.<br></div><div><br></div><div>Instead, we add an additional paramete=
r, wtFlag, to<br></div><div>OP_WITHDRAWPROOFVERIFY.<br></div><div>This para=
meter is ignored by OP_WITHDRAWPROOFVERIFY opcode.<br></div><div><br></div>=
<div>However, this parameter is used to determine if it is a WT.=C2=A0 Side=
chain<br></div><div>consensus should require that freely-created lockboxes =
set this<br></div><div>parameter to 0, so that a side block that creates fr=
ee lockboxes where<br></div><div>this parameter is non-zero is an invalid s=
ide block.=C2=A0 Then a sidechain<br></div><div>will only treat a lockbox o=
n another chain as a WT if the wtFlag<br></div><div>parameter is nonzero.=
=C2=A0 This way, freely-created lockboxes are not<br></div><div>valid WT.=
=C2=A0 Valid WT must lock actual, already unlocked coins, not<br></div><div=
>create new locked coins.<br></div><div><br></div><div>On Bitcoin, of cours=
e, this parameter must always be nonzero, since<br></div><div>freely-create=
d lockboxes are not allowed on mainchain, as asset<br></div><div>issuance o=
n mainchain is already fixed.<br></div><div><br></div><div>--<br></div><div=
><br></div><div>Let us now flesh out how WT and lockboxes look like.=C2=A0 =
As we mentioned, a<br></div><div>lockbox on one chain is a WT on the destin=
ation chain.=C2=A0 Or to be more<br></div><div>precise, what a destination =
chain sees as a WT, is a lockbox on the source<br></div><div>chain.<br></di=
v><div><br></div><div>Thus, a lockbox is a Bitcoin-formatted transaction ou=
tput paying to the<br></div><div>scriptPubKey:<br></div><div><br></div><div=
>=C2=A0 &lt;sidechain address commitment&gt; &lt;sidechain ID&gt; OP_WITHDR=
AWPROOFVERIFY<br></div><div><br></div><div>(assuming a softfork, additional=
 OP_DROP operations may occur after<br></div><div>OP_WITHDRAWPROOFVERIFY)<b=
r></div><div><br></div><div>Suppose the above lockbox is paid to in the Bit=
coin mainchain, with the<br></div><div>sidechain ID being the ID of Esschai=
n.=C2=A0 This is itself a WT transaction<br></div><div>from the point of vi=
ew of Esschain, on the principle that a lockbox on<br></div><div>one chain =
is a WT on another chain.<br></div><div><br></div><div>Assuming Esschain is=
 a brand-new sidechain, it has no EssCoins yet.=C2=A0 The<br></div><div>sid=
echain allows the arbitrary creation of sidecoin provided the new<br></div>=
<div>sidecoins are in a lockbox whose sidechain address commitment is 0.=C2=
=A0 So<br></div><div>in Esschain, we create the same coins on a UTXO paying=
 to the<br></div><div>scriptPubKey:<br></div><div><br></div><div>=C2=A0 0 0=
 OP_WITHDRAWPROOFVERIFY<br></div><div><br></div><div>The first 0 is the sid=
echain address commitment, which is 0 since this<br></div><div>output was n=
ot created by transferring to a sidechain; we<br></div><div>reuse the sidec=
hain address commitment as the wtFlag.=C2=A0 The<br></div><div>second 0 is =
the mainchain&#39;s ID.=C2=A0 The above is a lockbox from the point of<br><=
/div><div>view of Esschain.=C2=A0 It is not a WT on mainchain, however, bec=
ause the<br></div><div>sidechain address commitment is 0, which we use also=
 as the wtFlag<br></div><div>parameter.<br></div><div><br></div><div>Now, h=
ow does a main-to-side peg work?=C2=A0 After creating the above output on<b=
r></div><div>Esschain, we now spend the output with the below scriptSig:<br=
></div><div><br></div><div>=C2=A0 &lt;mainchain output ID&gt; &lt;mainchain=
 WT transaction&gt; &lt;merkle path to WT transaction&gt; &lt;mainchain blo=
ck hash&gt;<br></div><div><br></div><div>On Esschain, OP_WITHDRAWPROOFVERIF=
Y then verifies that the mainchain block<br></div><div>hash is a valid past=
 block of the mainchain, then locates the mainchain<br></div><div>header.=
=C2=A0 It then checks the merkle tree path to the mainchain WT<br></div><di=
v>transaction,<br></div><div>confirming that the mainchain contains that tr=
ansaction, and confirms that<br></div><div>the<br></div><div>indicated outp=
ut is in fact, a payment to an OP_WITHDRAWPROOFVERIFY, which<br></div><div>=
pushes the Esschain ID, and with a nonzero sidechain address commitment.<br=
></div><div><br></div><div>(Esschain also needs to ensure that a single WT =
is not used to unlock<br></div><div>multiple lockboxes on Esschain; the eas=
iest way is to add it to a set,<br></div><div>but this set cannot be pruned=
; other ways of ensuring only a WT is only<br></div><div>used to unlock onc=
e might be designed)<br></div><div><br></div><div>On Esschain, the sidechai=
n does one final check: the transaction that spends<br></div><div>an OP_WIT=
HDRAWPROOFVERIFY must have an output that pays to the sidechain<br></div><d=
iv>address committed to, and that output&#39;s value must be the same as th=
e value<br></div><div>locked in the mainchain.<br></div><div><br></div><div=
>(for now, I think all lockboxes must have the same fixed amount, for<br></=
div><div>simplicity)<br></div><div><br></div><div>Now suppose we want to co=
nvert back our EssCoin to Bitcoin.=C2=A0 We create a<br></div><div>lockbox =
on Esschain, paying to the below:<br></div><div><br></div><div>=C2=A0 &lt;b=
itcoin P2SH address&gt; 0 OP_WITHDRAWPROOFVERIFY<br></div><div><br></div><d=
iv>The bitcoin P2SH address is mainchain address commitment; for simplicity=
<br></div><div>we just use P2SH on mainchain as it can encode any address.=
=C2=A0 The 0 is the<br></div><div>mainchain ID.=C2=A0 The above Esschain lo=
ckbox is itself a WT from Esschain to<br></div><div>mainchain.<br></div><di=
v><br></div><div>Then, we look for an unspent lockbox on Esschain whose sid=
echain ID is the<br></div><div>Esschain ID.=C2=A0 Note that we can select a=
ny lockbox with the correct<br></div><div>sidechain ID, regardless of the s=
idechain address commitment it may have.<br></div><div><br></div><div>Locat=
ing an appropriate mainchain lockbox for Esschain coins, we then<br></div><=
div>provide the below scriptSig, paying out to the bitcoin P2SH address we<=
br></div><div>selected:<br></div><div><br></div><div>=C2=A0 &lt;esschain ou=
tput ID&gt; &lt;esschain WT tx&gt; &lt;merkle path to WT tx&gt; &lt;esschai=
n block header hash&gt;<br></div><div><br></div><div>On mainchain, we check=
 that the indicated sidechain block header hash is a<br></div><div>block he=
ader on the longest chain of Esschain.=C2=A0 We check it has sufficient<br>=
</div><div>depth.=C2=A0 Then we check if the merkle path to the WT tx is co=
rrect and goes<br></div><div>to esschain WT tx.=C2=A0 Finally, we check the=
 indicated output ID, and check that<br></div><div>it is indeed an Esschain=
 lockbox dedicated to mainchain.=C2=A0 Finally, we check<br></div><div>that=
 the transaction has an output that spends the lockbox amount to the<br></d=
iv><div>specified bitcoin P2SH address.<br></div><div><br></div><div>(simil=
arly mainchain nees to ensure that the Esschain WT is only used<br></div><d=
iv>once)<br></div><div><br></div><div>The key insight here is that side-to-=
side pegs are just like side-to-main<br></div><div>pegs.=C2=A0 Suppose inst=
ead we want to transfer our coins from Esscoin to<br></div><div>Teecoin.=C2=
=A0 We would instead pay to the following lockbox on Esschain:<br></div><di=
v><br></div><div>=C2=A0 &lt;teecoin address commitment&gt; &lt;teechain ID&=
gt; OP_WITHDRAWPROOFVERIFY<br></div><div><br></div><div>Then a Teechain tra=
nsaction spending some Tee-&gt;Ess lockbox (or a fresh<br></div><div>lockbo=
x if there are no Tee-&gt;Ess lockboxes on Teechain) is created.<br></div><=
div>We proceed as if it were a side-to-main peg, except it is a peg to<br><=
/div><div>Teechain, either creating or unlocking TeeCoins.=C2=A0 Indeed, ma=
inchain<br></div><div>fullnodes may even provide an RPC for checking OP_WIT=
HDRAWPROOFVERIFY,<br></div><div>so as to reduce risk that a sidechain break=
s consensus due to buggy<br></div><div>code.<br></div><div><br></div><div>-=
-<br></div><div><br></div><div>All is still not well with side-to-side pegs=
, however.<br></div><div><br></div><div>Suppose the economic majority decid=
es that Esschain must die.=C2=A0 Perhaps it<br></div><div>has some irrecove=
rable security bug, perhaps it adds features that allow<br></div><div>Essch=
ain fullnodes to kill baby seals, perhaps a successful theft of<br></div><d=
iv>Esschain lockboxes was performed and Esscoins are now functionally<br></=
div><div>worthless.=C2=A0 Killing a sidechain is done by bribing miners to =
put invalid<br></div><div>values into h*, and thus stealing Bitcoin-&gt;Ess=
 lockboxes.<br></div><div><br></div><div>If Esschain dies, however, and the=
 economic majority is not prepared to keep<br></div><div>Esschain dead, it =
is possible to unlock Tee-&gt;Ess lockboxes on Teechain.<br></div><div>Unlo=
cking existing Tee-&gt;Ess lockboxes on Teechain is safe, since they<br></d=
iv><div>represent coins that were locked into Bitcoin-&gt;Tee lockboxes.=C2=
=A0 However,<br></div><div>it is still possible to create &quot;free&quot; =
Tee-&gt;Ess lockboxes on Teechain, then<br></div><div>provide an invalid Te=
e-&gt;Ess WT lockbox on the now-moribund Esschain to<br></div><div>unlock t=
he free Tee-&gt;Ess lockbox on Teechain, inflating TeeCoin value.<br></div>=
<div>Thus in the presence of side-to-side pegs, the death of even one sidec=
hain<br></div><div>represents the death of every other sidechain!<br></div>=
<div><br></div><div>Thus, to properly kill Esschain, the economic majority =
should spam the<br></div><div>Esschain headers slot with a fixed value, say=
 0, forever.=C2=A0 This makes it<br></div><div>very difficult to create a T=
ee-&gt;Ess WT lockbox on Esschain, as you would<br></div><div>now be able t=
o reverse a one-way hash function.<br></div><div><br></div><div>Alternative=
ly, Teechain can softfork so that Tee-&gt;Ess lockboxes are no<br></div><di=
v>longer creatable or spendable.=C2=A0 However, the death of Esschain requi=
res<br></div><div>that all other sidechains, including Youchain, Veechain, =
Dubyachain, and<br></div><div>so on, to softfork similarly.<br></div><div><=
br></div><div>Perhaps both can be done: first the economic majority wanting=
 to kill<br></div><div>Esschain starts spamming it with invalid spends of B=
itcoin-&gt;Ess lockboxes,<br></div><div>then when all Bitcoin-&gt;Ess lockb=
oxes have been stolen, spam it with 0s<br></div><div>until all other sidech=
ains have banned free Ess lockboxes on their chains.<br></div><div>Then, th=
e economic majority can leave Esschain dead, and a later softfork<br></div>=
<div>of mainchain prevents Esschain from being extended and allows mainchai=
n<br></div><div>fullnodes to prune Esschain headers.<br></div><div><br></di=
v><div>--<br></div><div><br></div><div>Thieves will still have the same dif=
ficulty stealing from sidechains, but<br></div><div>now their payoff is inc=
reased.=C2=A0 If a thief wants to steal Esschain<br></div><div>lockboxes, t=
hen it is possible to pack an invalid Esschain block full of<br></div><div>=
invalid WT to other chains.=C2=A0 Even chains that don&#39;t have lockboxes=
 to<br></div><div>Esschain can create lockboxes to Esschain for free.=C2=A0=
 Thus, instead of<br></div><div>stealing only one lockbox at a time on main=
chain, the thief can steal one<br></div><div>lockbox on mainchain, and on e=
very sidechain that supports side-to-side<br></div><div>pegs, at a time.=C2=
=A0 The risk/reward ratio may shift drastically in that case.<br></div><div=
><br></div><div>However, this does mean that users of one chain must pay at=
tention to<br></div><div>attacks on other chains, not just the chain they u=
se.=C2=A0 If Teechain has no<br></div><div>side-to-side pegs, then Teechain=
 users will not care if Esschain is under<br></div><div>attack.=C2=A0 But i=
f side-to-side pegs are allowed on Teechain, then Teechain<br></div><div>us=
ers must also care about Esschain&#39;s health, as well as the health of<br=
></div><div>every other sidechain in existence.=C2=A0 Mainchain is protecte=
d since free<br></div><div>lockboxes are not creatable on mainchain.=C2=A0 =
Each sidechain is not; thus<br></div><div>the user of any sidechain must al=
so stand by users of every other<br></div><div>sidechain, or else they all =
fall apart.=C2=A0 Of course, this could more<br></div><div>simply lead to &=
quot;I will not use Teechain even if it would be useful to me,<br></div><di=
v>because if I use Teechain, I have to care about Esschain and Youchain and=
<br></div><div>whatever.&quot;<br></div><div><br></div><div>--<br></div><di=
v><br></div><div>Side-to-side pegs are useful to allow better liquidity and=
 provide<br></div><div>arbitrage quickly between sidechains, without having=
 to pass through<br></div><div>mainchain.=C2=A0 Otherwise, Esscoin may be v=
alued slightly lower than Bitcoin,<br></div><div>then Teecoin valued slight=
ly higher than Bitcoin, creating a larger<br></div><div>difference between =
Esscoin and Teecoin values than what a full<br></div><div>side-to-side peg =
could support.=C2=A0 2-way pegs from mainchain<br></div><div>to sidechain s=
tabilize sidecoin with respect to maincoin.=C2=A0 Side-to-side<br></div><di=
v>pegs stabilize all sidecoins to all other sidecoins.<br></div><div><br></=
div><div>Side-to-side pegs are enabled implicitly by sidechain-headers-on-<=
wbr>mainchain,<br></div><div>as all sidechain fullnodes must necessarily be=
 mainchain fullnodes, and<br></div><div>any mainchain fullnode can judge th=
e validity of any WT from any sidechain<br></div><div>without a miner votin=
g period.<br></div><div><br></div><div>Side-to-side pegs are a generalizati=
on of main-to-side and side-to-main<br></div><div>pegs.=C2=A0 A sidechain c=
an simply implement OP_WITHDRAWPROOFVERIFY and allow<br></div><div>free loc=
kboxes, and that is sufficient for the sidechain to support<br></div><div>i=
mports of bitcoin from mainchain and from any other sidechain.<br></div><di=
v><br></div><div>Side-to-side pegs seem to imply that all pegs must have th=
e same bitcoin<br></div><div>value transferred.=C2=A0 What that value must =
be, is something that may be<br></div><div>debated endlessly.<br></div><div=
><br></div><div>A side-to-side peg is a cut-through of a side-to-main peg f=
rom<br></div><div>one sidechain into a main-to-side peg into another sidech=
ain.=C2=A0 If a<br></div><div>withdrawal from side-to-main peg would be acc=
epted by mainchain, then<br></div><div>another sidechain could, in principl=
e, accept a proof that would<br></div><div>authorize a side-to-main peg dir=
ectly as a side-to-side peg.<br></div><div><br></div><div>Side-to-side pegs=
 make attacks on sidechains more lucrative, as it<br></div><div>becomes pos=
sible to print sidecoins by successfully attacking a<br></div><div>differen=
t sidechain.<br></div><div><br></div><div>Drivechain cannot implement side-=
to-side pegs, as WT validity is<br></div><div>voted on by mainchain miners,=
 and asking mainchain miners about<br></div><div>side-to-side pegs requires=
 mainchain miners to be aware of both<br></div><div>sidechains.=C2=A0 Sidec=
hain-headers-on-mainchain publishes SPV proofs<br></div><div>continuously t=
o the mainchain, and since any sidechain fullnode is<br></div><div>also a m=
ainchain fullnode (since sidechains are mergemined), then<br></div><div>eve=
ry sidechain fullnode is automatically capable of accessing<br></div><div>a=
nd verifying SPV proofs for every other sidechain.<br></div><div><br></div>=
<div>However, the pegging here seems less flexible than the pegging<br></di=
v><div>supported by drivechain.=C2=A0 Drivechain lets pegs be any size, wit=
h<br></div><div>miner voting being the basis of knowing how much money is o=
wned<br></div><div>by whom.<br></div><div><br></div><div>Regards,<br></div>=
<div>ZmnSCPxj<br></div></blockquote></div><br></div>

--94eb2c05d7c483e5bc0558b33941--