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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <melvincarvalho@gmail.com>) id 1XkHOq-00015X-SZ
for bitcoin-development@lists.sourceforge.net;
Fri, 31 Oct 2014 18:58:16 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.177 as permitted sender)
client-ip=209.85.217.177; envelope-from=melvincarvalho@gmail.com;
helo=mail-lb0-f177.google.com;
Received: from mail-lb0-f177.google.com ([209.85.217.177])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1XkHOo-0003W3-1d
for bitcoin-development@lists.sourceforge.net;
Fri, 31 Oct 2014 18:58:16 +0000
Received: by mail-lb0-f177.google.com with SMTP id 10so6472631lbg.22
for <bitcoin-development@lists.sourceforge.net>;
Fri, 31 Oct 2014 11:58:07 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.219.3 with SMTP id pk3mr28552702lbc.18.1414781887220;
Fri, 31 Oct 2014 11:58:07 -0700 (PDT)
Received: by 10.112.1.234 with HTTP; Fri, 31 Oct 2014 11:58:07 -0700 (PDT)
In-Reply-To: <CALqxMTHeipZZrJ_NSXK9vxiO83gSDgM6TA7T7XNBS3LtmuK2KA@mail.gmail.com>
References: <CALqxMTHeipZZrJ_NSXK9vxiO83gSDgM6TA7T7XNBS3LtmuK2KA@mail.gmail.com>
Date: Fri, 31 Oct 2014 19:58:07 +0100
Message-ID: <CAKaEYhL_N3TgTffwegXJ4pYqXURg7haCQgi2LgLPiSpotazLug@mail.gmail.com>
From: Melvin Carvalho <melvincarvalho@gmail.com>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=001a11c3d9fad2925a0506bc934d
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(melvincarvalho[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1XkHOo-0003W3-1d
Cc: Bitcoin-Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there
a way to do bitcoin-staging?)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 31 Oct 2014 18:58:17 -0000
--001a11c3d9fad2925a0506bc934d
Content-Type: text/plain; charset=UTF-8
On 22 October 2014 23:54, Adam Back <adam@cypherspace.org> wrote:
> For those following this thread, we have now written a paper
> describing the side-chains, 2-way pegs and compact SPV proofs.
> (With additional authors Andrew Poelstra & Andrew Miller).
>
> http://blockstream.com/sidechains.pdf
>
A very well written paper, thank you for putting it together and sharing.
Given it's the 6 year birthday of satoshi's white paper, I just read
through it again.
I find it interesting that bitcoin is never defined in Satoshi's paper,
indeed, it never appears after the first word.
The term Electronic Coin is defined.
The terminology of bitcoin / altcoin / altchain / blockchain in this paper
still leaves me slightly uneasy, and I try to use the terms electronic coin
and electronic cash, more often.
If satoshi were to come back and continue his work, would it be an altcoin,
would it be "The" blockchain, would it be bitcoin, or would what we know as
bitcoin become an alt. I suspect these questions are nothing more than
academic curiosity.
But I think I'll get more used to it over time :)
In any case, happy birthday "bitcoin" :)
>
> Adam
>
> On 16 March 2014 15:58, Adam Back <adam@cypherspace.org> wrote:
> > So an update on 1-way pegging (aka bitcoin staging, explained in quoted
> text
> > at bottom): it turns out secure 2-way pegging is also possible (with some
> > bitcoin change to help support it). The interesting thing is this allows
> > interoperability in terms of being able to move bitcoin into and out of a
> > side chain. The side chains may have some different parameters, or
> > experimental things people might want to come up with (subject to some
> > minimum compatibility at the level of being able to produce an SPV proof
> of
> > a given form).
> >
> > At the time of the 1-way peg discussion I considered 2-way peg as
> desirable
> > and it seemed plausible with bitcoin changes, but the motivation for
> 1-way
> > peg was to make it less risky to make changes on bitcoin, so that seemed
> > like a catch-22 loop. Also in the 2-way peg thought experiment I had not
> > realized how simple it was to still impose a security firewall in the
> 2-way
> > peg also.
> >
> >
> > So Greg Maxwell proposed in Dec last year a practically compact way to do
> > 2-way pegging using SPV proofs. And also provided a simple argument of
> how
> > this can provide a security firewall. (Security firewall means the
> impact
> > of security bugs on the side-chain is limited to the people with coins in
> > it; bitcoin holders who did not use it are unaffected). [1]
> >
> > How it works:
> >
> > 1. to maintain the 21m coins promise, you start a side-chain with no
> > in-chain mining subsidy, all bitcoin creation happens on bitcoin chain
> (as
> > with 1-way peg). Reach a reasonable hash rate. (Other semantics than
> 1:1
> > peg should be possible, but this is the base case).
> >
> > 2. you move coins to the side-chain by spending them to a fancy script,
> > which suspends them, and allows them to be reanimated by the production
> of
> > an SPV proof of burn on the side-chain.
> >
> > 3. the side-chain has no mining reward, but it allows you to mint coins
> at
> > no mining cost by providing an SPV proof that the coin has been
> suspended as
> > in 2 on bitcoin. The SPV proof must be buried significantly before being
> > used to reduce risk of reorganization. The side-chain is an SPV client
> to
> > the bitcoin network, and so maintains a view of the bitcoin hash chain
> (but
> > not the block data).
> >
> > 4. the bitcoin chain is firewalled from security bugs on the side chain,
> > because bitcoin imposes the rule that no more coins can be reanimated
> than
> > are currently suspend (with respect to a given chain).
> >
> > 5. to simplify what they hypothetical bitcoin change would need to
> consider
> > and understand, after a coin is reanimated there is a maturity period
> > imposed (say same as fresh mined coins). During the maturity period the
> > reanimation script allows a fraud proof to spend the coins back. A fraud
> > bounty fee (equal to the reanimate fee) can be offered by the mover to
> > incentivize side-chain full nodes to watch reanimations and search for
> fraud
> > proofs.
> >
> > 6. a fraud proof is an SPV proof with a longer chain showing that the
> proof
> > of burn was orphaned.
> >
> > There are a few options to compress the SPV proof, via Fiat-Shamir
> transform
> > to provide a compact proof of amount work contained in a merkle tree of
> > proofs of work (as proposed by Fabien Coelho link on
> > http://hashcash.org/papers/) with params like 90% of work is proven.
> But
> > better is something Greg proposed based on skip-lists organized in a
> tree,
> > where 'lucky' proofs of work are used to skip back further. (Recalling
> that
> > if you search for a 64-bit leading-0 proof-of-work, half the time you
> get a
> > 65-bit, quarter 66-bit etc.) With this mechanism you can accurately
> > prove the amount of proof of work in a compressed tree (rather than
> ~90%).
> >
> >
> > Apart from pegging from bitcoin to a side-chain, if a private chain is
> made
> > with same rules to the side-chain it becomes possible with some
> > modifications to the above algorithm to peg the side-chain to a private
> > chain. Private chain meaning a chain with the same format but signature
> of
> > single server in place of hashing, and timestamping of the block
> signatures
> > in the mined side chain. And then reactive security on top of that by
> full
> > nodes/auditors trying to find fraud proofs (rewrites of history relative
> to
> > side-chain mined time-stamp or approved double-spends). The reaction is
> to
> > publish a fraud proof and move coins back to the side chain, and then
> > regroup on a new server. (Open transactions has this audit + reactive
> model
> > but as far as I know does it via escrow, eg the voting pools for k of n
> > escrow of the assets on the private server.) I also proposed the same
> > reactive audit model but for auditable namespaces [4].
> >
> > Private chains add some possiblity for higher scaling, while retaining
> > bitcoin security properties. (You need to add the ability for a user to
> > unilaterally move his coins to the side-chain they came from in event the
> > chain server refuses to process transactions involving them. This
> appears
> > to be possible if you have compatible formats on the private chain and
> > side-chain).
> >
> >
> > This pegging discussion involved a number of #bitcoin-wizards, Greg
> Maxwell,
> > Matt Corallo, Pieter Wuille, Jorge Timon, Mark Freidenbach, Luke Dashjr.
> The
> > 2-way peg seems to have first been described by Greg. Greg thought of
> > 2-way pegging in the context of ZK-SNARKS and the coinwitness thread [2].
> > (As a ZK-SNARK could compactly prove full validation of a side chain
> rules).
> >
> > There was also something seemingly similar sounding but not described in
> > detail by Alex Mizrahi in the context of color coins in this post [3].
> >
> > Adam
> >
> > [1] http://download.wpsoftware.net/bitcoin/wizards/2013-12-18.txt
> > [2] https://bitcointalk.org/index.php?topic=277389.40
> > [3] https://bitcointalk.org/index.php?topic=277389.msg4167554#msg4167554
> > [4] http://www.cypherspace.org/p2p/auditable-namespace.html
> >
> > On Mon, Oct 14, 2013 at 08:08:07PM +0200, Adam Back wrote:
> >>
> >> Coming back to the staging idea, maybe this is a realistic model that
> >> could
> >> work. The objective being to provide a way for bitcoin to move to a
> live
> >> beta and stable being worked on in parallel like fedora vs RHEL or
> >> odd/even
> >> linux kernel versions.
> >>
> >> Development runs in parallel on bitcoin 1.x beta (betacoin) and bitcoin
> >> 0.x
> >> stable and leap-frogs as beta becomes stable after testing.
> >>
> >> Its a live beta, meaning real value, real contracts. But we dont want
> it
> >> to
> >> be an alt-coin with a floating value exactly, we want it to be bitcoin,
> >> but
> >> the bleeding edge bitcoin so we want to respect the 21 million coin
> limit,
> >> and allow coins to move between bitcoin and betacoin with some necessary
> >> security related restrictions.
> >>
> >> There is no mining reward on the betacoin network (can be merge mined
> for
> >> security), and the way you opt to move a bitcoin into the betacoin
> network
> >> is to mark it as transferred in some UTXO recognized way. It cant be
> >> reanimated, its dead. (eg spend to a specific recognized invalid
> address
> >> on
> >> the bitcoin network). In this way its not really a destruction, but a
> >> move,
> >> moving the coin from bitcoin to betacoin network.
> >>
> >> This respects the 21 million coin cap, and avoids betacoin bugs flowing
> >> back
> >> and affecting bitcoin security or value-store properties. Users may buy
> >> or
> >> swap betacoin for bitcoin to facilitate moving money back from betacoin
> to
> >> bitcoin. However that is market priced so the bitcoin network is
> security
> >> insulated from beta. A significant security bug in beta would cause a
> >> market freeze, until it is rectified.
> >>
> >> The cost of a betacoin is capped at one BTC because no one will pay more
> >> than one bitcoin for a betacoin because they could alternatively move
> >> their
> >> own coin. The reverse is market priced.
> >>
> >> Once bitcoin beta stabalizes, eg say year or two type of time-frame, a
> >> decision is reached to promote 1.0 beta to 2.0 stable, the remaining
> >> bitcoins can be moved, and the old network switched off, with mining
> past
> >> a
> >> flag day moving to the betacoin.
> >>
> >> During the beta period betacoin is NOT an alpha, people can rely on it
> and
> >> use it in anger for real value transactions. eg if it enables more
> script
> >> features, or coin coloring, scalabity tweaks etc people can use it.
> >> Probably for large value store they are always going to prefer
> >> bitcoin-stable, but applications that need the coloring features, or
> >> advanced scripting etc can go ahead and beta.
> >>
> >> Bitcoin-stable may pull validated changes and merge them, as a way to
> pull
> >> in any features needed in the shorter term and benefit from the betacoin
> >> validation. (Testing isnt as much validation as real-money at stake
> >> survivability).
> >>
> >> The arguments are I think that:
> >>
> >> - it allows faster development allowing bitcoin to progress features
> >> faster,
> >>
> >> - it avoids mindshare dilution if alternatively an alt-coin with a hit
> >> missing feature takes off;
> >>
> >> - it concentrates such useful-feature alt activities into one OPEN
> source
> >> and OPEN control foundation mediated area (rather than suspected land
> >> grabs on colored fees or such like bitcoin respun as a business model
> >> things),
> >>
> >> - maybe gets the developers that would've been working on their pet
> >> alt-coin, or their startup alt-coin to work together putting more
> >> developers, testers and resources onto something with open control
> (open
> >> source does not necessarily mean that much) and bitcoin mindshare
> >> branding, its STILL bitcoin, its just the beta network.
> >>
> >> - it respects the 21 million limit, starting new mining races probably
> >> dillutes the artificial scarcity semantic
> >>
> >> - while insulating bitcoin from betacoin security defects (I dont mean
> >> betacoin as a testnet, it should have prudent rigorous testing like
> >> bitcoin, just the very act of adding a feature creates risk that
> bitcoin
> >> stable can be hesitant to take).
> >>
> >> Probably the main issue as always is more (trustable) very high caliber
> >> testers and developers. Maybe if the alt-coin minded startups and
> >> developers donate their time to bitcoin-beta (or bitcoin-stable) for the
> >> bits they are missing, we'll get more hands to work on something of
> >> reusable
> >> value to humanity, in parallel with their startup's objectives and as a
> >> way
> >> for them to get their needed features, while giving back to the bitcoin
> >> community, and helping bitcoin progress faster.
> >>
> >> Maybe bitcoin foundation could ask for BTC donations to hire more
> >> developers
> >> and testers full time. $1.5b of stored value should be interested to
> safe
> >> guard their value store, and develop the transaction features.
> >>
> >> Adam
> >>
> >> On Mon, May 20, 2013 at 02:34:06AM -0400, Alan Reiner wrote:
> >>>
> >>> This is exactly what I was planning to do with the
> >>> inappropriately-named "Ultimate Blockchain Compression". [...]
> >>>
> >>> For it to really work, it's gotta be part of the mainnet validation
> >>> rules, but no way it can be evaluated realistically without some kind
> of
> >>> "staging".
> >>
> >>
> >>> On 5/19/2013 11:08 AM, Peter Vessenes wrote:
> >>>
> >>> I think this is a very interesting idea. As Bitcoiners, we often stuff
> >>> things into the 'alt chain' bucket in our heads; I wonder if this idea
> >>> works better as a curing period, essentially an extended version of
> the
> >>> current 100 block wait for mined coins.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--001a11c3d9fad2925a0506bc934d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On 22 October 2014 23:54, Adam Back <span dir=3D"ltr"><<a href=3D"ma=
ilto:adam@cypherspace.org" target=3D"_blank">adam@cypherspace.org</a>></=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex">For those following this thr=
ead, we have now written a paper<br>
describing the side-chains, 2-way pegs and compact SPV proofs.<br>
(With additional authors Andrew Poelstra & Andrew Miller).<br>
<br>
<a href=3D"http://blockstream.com/sidechains.pdf" target=3D"_blank">http://=
blockstream.com/sidechains.pdf</a><br></blockquote><div><br></div><div>A ve=
ry well written paper, thank you for putting it together and sharing.<br></=
div><div><br></div><div>Given it's the 6 year birthday of satoshi's=
white paper, I just read through it again.<br><br></div><div>I find it int=
eresting that bitcoin is never defined in Satoshi's paper, indeed, it n=
ever appears after the first word.<br><br></div><div>The term Electronic Co=
in is defined. <br><br></div><div>The terminology of bitcoin / altcoin / al=
tchain / blockchain in this paper still leaves me slightly uneasy, and I tr=
y to use the terms electronic coin and electronic cash, more often.=C2=A0 <=
br><br></div><div>If satoshi were to come back and continue his work, would=
it be an altcoin, would it be "The" blockchain, would it be bitc=
oin, or would what we know as bitcoin become an alt.=C2=A0 I suspect these =
questions are nothing more than academic curiosity.<br></div><div><br>But I=
think I'll get more used to it over time :)<br><br></div><div>In any c=
ase, happy birthday "bitcoin" :)<br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex">
<br>
Adam<br>
<br>
On 16 March 2014 15:58, Adam Back <<a href=3D"mailto:adam@cypherspace.or=
g">adam@cypherspace.org</a>> wrote:<br>
> So an update on 1-way pegging (aka bitcoin staging, explained in quote=
d text<br>
> at bottom): it turns out secure 2-way pegging is also possible (with s=
ome<br>
> bitcoin change to help support it).=C2=A0 The interesting thing is thi=
s allows<br>
> interoperability in terms of being able to move bitcoin into and out o=
f a<br>
> side chain.=C2=A0 The side chains may have some different parameters, =
or<br>
> experimental things people might want to come up with (subject to some=
<br>
> minimum compatibility at the level of being able to produce an SPV pro=
of of<br>
> a given form).<br>
><br>
> At the time of the 1-way peg discussion I considered 2-way peg as desi=
rable<br>
> and it seemed plausible with bitcoin changes, but the motivation for 1=
-way<br>
> peg was to make it less risky to make changes on bitcoin, so that seem=
ed<br>
> like a catch-22 loop.=C2=A0 Also in the 2-way peg thought experiment I=
had not<br>
> realized how simple it was to still impose a security firewall in the =
2-way<br>
> peg also.<br>
><br>
><br>
> So Greg Maxwell proposed in Dec last year a practically compact way to=
do<br>
> 2-way pegging using SPV proofs.=C2=A0 And also provided a simple argum=
ent of how<br>
> this can provide a security firewall.=C2=A0 (Security firewall means t=
he impact<br>
> of security bugs on the side-chain is limited to the people with coins=
in<br>
> it; bitcoin holders who did not use it are unaffected). [1]<br>
><br>
> How it works:<br>
><br>
> 1. to maintain the 21m coins promise, you start a side-chain with no<b=
r>
> in-chain mining subsidy, all bitcoin creation happens on bitcoin chain=
(as<br>
> with 1-way peg).=C2=A0 Reach a reasonable hash rate.=C2=A0 (Other sema=
ntics than 1:1<br>
> peg should be possible, but this is the base case).<br>
><br>
> 2. you move coins to the side-chain by spending them to a fancy script=
,<br>
> which suspends them, and allows them to be reanimated by the productio=
n of<br>
> an SPV proof of burn on the side-chain.<br>
><br>
> 3. the side-chain has no mining reward, but it allows you to mint coin=
s at<br>
> no mining cost by providing an SPV proof that the coin has been suspen=
ded as<br>
> in 2 on bitcoin.=C2=A0 The SPV proof must be buried significantly befo=
re being<br>
> used to reduce risk of reorganization.=C2=A0 The side-chain is an SPV =
client to<br>
> the bitcoin network, and so maintains a view of the bitcoin hash chain=
(but<br>
> not the block data).<br>
><br>
> 4. the bitcoin chain is firewalled from security bugs on the side chai=
n,<br>
> because bitcoin imposes the rule that no more coins can be reanimated =
than<br>
> are currently suspend (with respect to a given chain).<br>
><br>
> 5. to simplify what they hypothetical bitcoin change would need to con=
sider<br>
> and understand, after a coin is reanimated there is a maturity period<=
br>
> imposed (say same as fresh mined coins).=C2=A0 During the maturity per=
iod the<br>
> reanimation script allows a fraud proof to spend the coins back.=C2=A0=
A fraud<br>
> bounty fee (equal to the reanimate fee) can be offered by the mover to=
<br>
> incentivize side-chain full nodes to watch reanimations and search for=
fraud<br>
> proofs.<br>
><br>
> 6. a fraud proof is an SPV proof with a longer chain showing that the =
proof<br>
> of burn was orphaned.<br>
><br>
> There are a few options to compress the SPV proof, via Fiat-Shamir tra=
nsform<br>
> to provide a compact proof of amount work contained in a merkle tree o=
f<br>
> proofs of work (as proposed by Fabien Coelho link on<br>
> <a href=3D"http://hashcash.org/papers/" target=3D"_blank">http://hashc=
ash.org/papers/</a>) with params like 90% of work is proven.=C2=A0 But<br>
> better is something Greg proposed based on skip-lists organized in a t=
ree,<br>
> where 'lucky' proofs of work are used to skip back further.=C2=
=A0 (Recalling that<br>
> if you search for a 64-bit leading-0 proof-of-work, half the time you =
get a<br>
> 65-bit, quarter 66-bit etc.)=C2=A0 With this mechanism you can accurat=
ely<br>
> prove the amount of proof of work in a compressed tree (rather than ~9=
0%).<br>
><br>
><br>
> Apart from pegging from bitcoin to a side-chain, if a private chain is=
made<br>
> with same rules to the side-chain it becomes possible with some<br>
> modifications to the above algorithm to peg the side-chain to a privat=
e<br>
> chain.=C2=A0 Private chain meaning a chain with the same format but si=
gnature of<br>
> single server in place of hashing, and timestamping of the block signa=
tures<br>
> in the mined side chain.=C2=A0 And then reactive security on top of th=
at by full<br>
> nodes/auditors trying to find fraud proofs (rewrites of history relati=
ve to<br>
> side-chain mined time-stamp or approved double-spends).=C2=A0 The reac=
tion is to<br>
> publish a fraud proof and move coins back to the side chain, and then<=
br>
> regroup on a new server.=C2=A0 (Open transactions has this audit + rea=
ctive model<br>
> but as far as I know does it via escrow, eg the voting pools for k of =
n<br>
> escrow of the assets on the private server.) I also proposed the same<=
br>
> reactive audit model but for auditable namespaces [4].<br>
><br>
> Private chains add some possiblity for higher scaling, while retaining=
<br>
> bitcoin security properties.=C2=A0 (You need to add the ability for a =
user to<br>
> unilaterally move his coins to the side-chain they came from in event =
the<br>
> chain server refuses to process transactions involving them.=C2=A0 Thi=
s appears<br>
> to be possible if you have compatible formats on the private chain and=
<br>
> side-chain).<br>
><br>
><br>
> This pegging discussion involved a number of #bitcoin-wizards, Greg Ma=
xwell,<br>
> Matt Corallo, Pieter Wuille, Jorge Timon, Mark Freidenbach, Luke Dashj=
r. The<br>
> 2-way peg seems to have first been described by Greg.=C2=A0 Greg thoug=
ht of<br>
> 2-way pegging in the context of ZK-SNARKS and the coinwitness thread [=
2].<br>
> (As a ZK-SNARK could compactly prove full validation of a side chain r=
ules).<br>
><br>
> There was also something seemingly similar sounding but not described =
in<br>
> detail by Alex Mizrahi in the context of color coins in this post [3].=
<br>
><br>
> Adam<br>
><br>
> [1] <a href=3D"http://download.wpsoftware.net/bitcoin/wizards/2013-12-=
18.txt" target=3D"_blank">http://download.wpsoftware.net/bitcoin/wizards/20=
13-12-18.txt</a><br>
> [2] <a href=3D"https://bitcointalk.org/index.php?topic=3D277389.40" ta=
rget=3D"_blank">https://bitcointalk.org/index.php?topic=3D277389.40</a><br>
> [3] <a href=3D"https://bitcointalk.org/index.php?topic=3D277389.msg416=
7554#msg4167554" target=3D"_blank">https://bitcointalk.org/index.php?topic=
=3D277389.msg4167554#msg4167554</a><br>
> [4] <a href=3D"http://www.cypherspace.org/p2p/auditable-namespace.html=
" target=3D"_blank">http://www.cypherspace.org/p2p/auditable-namespace.html=
</a><br>
><br>
> On Mon, Oct 14, 2013 at 08:08:07PM +0200, Adam Back wrote:<br>
>><br>
>> Coming back to the staging idea, maybe this is a realistic model t=
hat<br>
>> could<br>
>> work.=C2=A0 The objective being to provide a way for bitcoin to mo=
ve to a live<br>
>> beta and stable being worked on in parallel like fedora vs RHEL or=
<br>
>> odd/even<br>
>> linux kernel versions.<br>
>><br>
>> Development runs in parallel on bitcoin 1.x beta (betacoin) and bi=
tcoin<br>
>> 0.x<br>
>> stable and leap-frogs as beta becomes stable after testing.<br>
>><br>
>> Its a live beta, meaning real value, real contracts.=C2=A0 But we =
dont want it<br>
>> to<br>
>> be an alt-coin with a floating value exactly, we want it to be bit=
coin,<br>
>> but<br>
>> the bleeding edge bitcoin so we want to respect the 21 million coi=
n limit,<br>
>> and allow coins to move between bitcoin and betacoin with some nec=
essary<br>
>> security related restrictions.<br>
>><br>
>> There is no mining reward on the betacoin network (can be merge mi=
ned for<br>
>> security), and the way you opt to move a bitcoin into the betacoin=
network<br>
>> is to mark it as transferred in some UTXO recognized way.=C2=A0 It=
cant be<br>
>> reanimated, its dead.=C2=A0 (eg spend to a specific recognized inv=
alid address<br>
>> on<br>
>> the bitcoin network).=C2=A0 In this way its not really a destructi=
on, but a<br>
>> move,<br>
>> moving the coin from bitcoin to betacoin network.<br>
>><br>
>> This respects the 21 million coin cap, and avoids betacoin bugs fl=
owing<br>
>> back<br>
>> and affecting bitcoin security or value-store properties.=C2=A0 Us=
ers may buy<br>
>> or<br>
>> swap betacoin for bitcoin to facilitate moving money back from bet=
acoin to<br>
>> bitcoin.=C2=A0 However that is market priced so the bitcoin networ=
k is security<br>
>> insulated from beta.=C2=A0 A significant security bug in beta woul=
d cause a<br>
>> market freeze, until it is rectified.<br>
>><br>
>> The cost of a betacoin is capped at one BTC because no one will pa=
y more<br>
>> than one bitcoin for a betacoin because they could alternatively m=
ove<br>
>> their<br>
>> own coin.=C2=A0 The reverse is market priced.<br>
>><br>
>> Once bitcoin beta stabalizes, eg say year or two type of time-fram=
e, a<br>
>> decision is reached to promote 1.0 beta to 2.0 stable, the remaini=
ng<br>
>> bitcoins can be moved, and the old network switched off, with mini=
ng past<br>
>> a<br>
>> flag day moving to the betacoin.<br>
>><br>
>> During the beta period betacoin is NOT an alpha, people can rely o=
n it and<br>
>> use it in anger for real value transactions.=C2=A0 eg if it enable=
s more script<br>
>> features, or coin coloring, scalabity tweaks etc people can use it=
.<br>
>> Probably for large value store they are always going to prefer<br>
>> bitcoin-stable, but applications that need the coloring features, =
or<br>
>> advanced scripting etc can go ahead and beta.<br>
>><br>
>> Bitcoin-stable may pull validated changes and merge them, as a way=
to pull<br>
>> in any features needed in the shorter term and benefit from the be=
tacoin<br>
>> validation.=C2=A0 (Testing isnt as much validation as real-money a=
t stake<br>
>> survivability).<br>
>><br>
>> The arguments are I think that:<br>
>><br>
>> - it allows faster development allowing bitcoin to progress featur=
es<br>
>> faster,<br>
>><br>
>> - it avoids mindshare dilution if alternatively an alt-coin with a=
hit<br>
>>=C2=A0 missing feature takes off;<br>
>><br>
>> - it concentrates such useful-feature alt activities into one OPEN=
source<br>
>>=C2=A0 and OPEN control foundation mediated area (rather than suspe=
cted land<br>
>>=C2=A0 grabs on colored fees or such like bitcoin respun as a busin=
ess model<br>
>>=C2=A0 things),<br>
>><br>
>> - maybe gets the developers that would've been working on thei=
r pet<br>
>>=C2=A0 alt-coin, or their startup alt-coin to work together putting=
more<br>
>>=C2=A0 developers, testers and resources onto something with open c=
ontrol (open<br>
>>=C2=A0 source does not necessarily mean that much) and bitcoin mind=
share<br>
>>=C2=A0 branding, its STILL bitcoin, its just the beta network.<br>
>><br>
>> - it respects the 21 million limit, starting new mining races prob=
ably<br>
>>=C2=A0 dillutes the artificial scarcity semantic<br>
>><br>
>> - while insulating bitcoin from betacoin security defects (I dont =
mean<br>
>>=C2=A0 betacoin as a testnet, it should have prudent rigorous testi=
ng like<br>
>>=C2=A0 bitcoin, just the very act of adding a feature creates risk =
that bitcoin<br>
>>=C2=A0 stable can be hesitant to take).<br>
>><br>
>> Probably the main issue as always is more (trustable) very high ca=
liber<br>
>> testers and developers.=C2=A0 Maybe if the alt-coin minded startup=
s and<br>
>> developers donate their time to bitcoin-beta (or bitcoin-stable) f=
or the<br>
>> bits they are missing, we'll get more hands to work on somethi=
ng of<br>
>> reusable<br>
>> value to humanity, in parallel with their startup's objectives=
and as a<br>
>> way<br>
>> for them to get their needed features, while giving back to the bi=
tcoin<br>
>> community, and helping bitcoin progress faster.<br>
>><br>
>> Maybe bitcoin foundation could ask for BTC donations to hire more<=
br>
>> developers<br>
>> and testers full time.=C2=A0 $1.5b of stored value should be inter=
ested to safe<br>
>> guard their value store, and develop the transaction features.<br>
>><br>
>> Adam<br>
>><br>
>> On Mon, May 20, 2013 at 02:34:06AM -0400, Alan Reiner wrote:<br>
>>><br>
>>>=C2=A0 This is exactly what I was planning to do with the<br>
>>>=C2=A0 inappropriately-named "Ultimate Blockchain Compress=
ion".=C2=A0 [...]<br>
>>><br>
>>>=C2=A0 For it to really work, it's gotta be part of the mai=
nnet validation<br>
>>>=C2=A0 rules, but no way it can be evaluated realistically with=
out some kind of<br>
>>>=C2=A0 "staging".<br>
>><br>
>><br>
>>>=C2=A0 On 5/19/2013 11:08 AM, Peter Vessenes wrote:<br>
>>><br>
>>>=C2=A0 I think this is a very interesting idea. As Bitcoiners, =
we often stuff<br>
>>>=C2=A0 things into the 'alt chain' bucket in our heads;=
I wonder if this idea<br>
>>>=C2=A0 works better as a curing period, essentially an extended=
version of the<br>
>>>=C2=A0 current 100 block wait for mined coins.<br>
<br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div></div>
--001a11c3d9fad2925a0506bc934d--
|