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
|
Return-Path: <quantumas3@gmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id D00EEC016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2020 21:43:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id CC4E888876
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2020 21:43:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id quk8IQ4JAb5W
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2020 21:43:33 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-qt1-f195.google.com (mail-qt1-f195.google.com
[209.85.160.195])
by hemlock.osuosl.org (Postfix) with ESMTPS id E401988874
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2020 21:43:32 +0000 (UTC)
Received: by mail-qt1-f195.google.com with SMTP id z2so5972644qts.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 Jun 2020 14:43:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=zdGPsetx55fGjACqX3+JXw5wp8MMqKmwf3KFWU2Y6xE=;
b=lR2+kH1GcLrxl8mRQO9XCqR8fpxlmUOKu8TLXWu1cf1gGn9U1Fj1ruGCbzY57l1BBI
cbCt2k9hATz9iX3Pe/W/cq69VLt4WFgAN/xBEuFJIv9UfVFCCf+7WHAW7LEpFYJuudx3
t+olCr3MXH9hV/O01JCbPQnNM62IJrWGibmNu/BHgaeMaf7ijkl29JSi2aL7djZw9Xzh
2U9fr9D/YsA4yjyFObOsPXGKNMxmvRhVHOVzoH7IHPW1n6woirIDLsvMEIdm5QBkkoe8
MuGlUsG3T6vk//q/1cGevRg7dYo7Pmj9ootxQIKbzQyWxmt3hR/ul8YScQ0rKI6Eu/oW
fcvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=zdGPsetx55fGjACqX3+JXw5wp8MMqKmwf3KFWU2Y6xE=;
b=SeSZAJVYFLrXsEUpDA+HXSunh81j/Zb1nZFxKK89lKzknS4jFEYxlmWfzNy3yvoOPT
C/XlACM36MQyuBY1WN/tDfRbp7C3nvJvzhsSpVcrZFGvMm2sK52DLcXEbna03HS031EA
2Ckvelxisgj8J7VXViAesiPLq8ocONLx+sTtfOtGRIt9Y4NZXrI0YRuKk+OBMqOzWVnO
l2QoSSCpB2IHR9OEzcQfYD1d6jn6maw463H+EP1QK3tHDoOZQR0S4JYL+2V05L78ez2w
4CN6AMvC93dn5kZJyufS1CjtFTdiN8p2wiEk2uzBv0ZOSY3UakVJBTebCHFQ7ifA5Sg2
GmRA==
X-Gm-Message-State: AOAM532ubjlT2kkRPiyHMQqzANZicMNwL73M/CHFnAKPwSH3DSmwYK1C
kDY3OOP+vA3kw/z3c/ny7cJFZiQVXvtfMcW8/dp+xIRE
X-Google-Smtp-Source: ABdhPJyz9gpQJ2AXGTg5NnzTwj7saxc+FKO0brZkQoMUhpQKbj4GRFVC2cVnfoW3EnbuFb7P97TSy+2X2M1BpV3Iiik=
X-Received: by 2002:ac8:75c4:: with SMTP id z4mr14736688qtq.371.1593121411696;
Thu, 25 Jun 2020 14:43:31 -0700 (PDT)
MIME-Version: 1.0
From: Cloud Strife <quantumas3@gmail.com>
Date: Thu, 25 Jun 2020 17:43:20 -0400
Message-ID: <CAHeORgLcir=hZSoiDAE2hfttW71tiMNor0updmgRc2z-W-v=ow@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="000000000000d40dcd05a8ef7b83"
X-Mailman-Approved-At: Thu, 25 Jun 2020 23:14:51 +0000
Subject: [bitcoin-dev] Bitcoin 2-way-pegged childchains via Proof of Burn
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2020 21:43:33 -0000
--000000000000d40dcd05a8ef7b83
Content-Type: text/plain; charset="UTF-8"
Hi everyone,
I am hoping to get a critique on a proposal of how to
construct childchains "on-top" of Bitcoin without requiring any changes to
Bitcoin itself nor requiring any user or miner to be aware of them.
The childchain is Bitcoin-aware and simulates the properties of Proof of
Work by requiring continuous burning of Bitcoin in return for the fees on
the childchain.
The childchain tip is selected by highest total accumulated Bitcoin burnt
(with goal to simulate total accumulated work) for that full chained set of
childchain block commits.
The only asset on the childchain is a 2-way-peg coin that's secured in
value without oracles or collateral by requiring that each valid child
chain block must not only burn Bitcoin, but must always use a small % of
the burnt amount to deterministically reimburse withdrawals from the
childchain.
Childchain -> mainchain :: user burns the child-BTC and is added to
withdrawal queue filled as part of validity requirements by childchain
"miners" until filled 1:1 on mainchain or more. Note that occasionally
overpaying a widthdrawal does not break 1:1 peg as there's no fixed size
1:1 pool of coins necessary.
mainchain -> childchain :: user burns BTC (independent of mining
childchain) and is issued equivalent 1:1 child-BTC on the childchain
While childchains are less secure than the mainchain, both the childchain
security and the 2-way-peg accuracy might be an acceptable option for lower
value tx on scale determined by the burning rate.
Childchains would replace the need for any additional Proof of Work chains
for new blockchains to introduce any complexity (e.g. mimblewimble
childchain).
They would effectively use Proof of Work done on Bitcoin as proxy for
unforgeable costliness and benefit from Bitcoin's censorship resistance and
data availability. Large numbers of low value tx that might be priced out
of using the main chain could possibly in bulk provide enough childchain
fees combined through childchain miners to afford much higher mainchain
fees like "batching for fees".
It also has the "benefits" claimed by proof of stake like no energy
consumption without relying on internal permissions or tokens, trusted
distributions, or centralizing mechanisms like staking by simulating proof
of work. It should allow both growing the Bitcoin ecosystem and replace the
need to create alternative cryptocurrencies just to make a new blockchain.
More detailed write up available here:
https://bitcointalk.org/index.php?topic=5214173.0
I am hoping for a review if there's an overlooked issue or maybe interest
to create a proof of concept.
Thank you
-CS
--000000000000d40dcd05a8ef7b83
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div>Hi everyone,</div><div><br></div><di=
v>I am hoping to get a critique on a proposal of how to construct=C2=A0chil=
dchains=C2=A0"on-top" of Bitcoin without requiring any changes to=
Bitcoin itself nor requiring any user or miner to be aware of them.</div><=
div><br></div><div>The childchain is Bitcoin-aware and simulates the proper=
ties of Proof of Work by requiring continuous burning of Bitcoin in return =
for the fees on the childchain.<br></div><div><br></div><div>The childchain=
=C2=A0tip is selected by highest total accumulated Bitcoin burnt (with goal=
to simulate total accumulated work) for that full chained set of childchai=
n block commits.</div><div><br></div><div>The only asset on the childchain=
=C2=A0is a 2-way-peg coin that's secured in value without oracles or co=
llateral by requiring that each valid child chain block must not only burn =
Bitcoin, but must always use a small % of the burnt amount to deterministic=
ally reimburse=C2=A0withdrawals from the childchain.</div><div><br></div><d=
iv>Childchain -> mainchain :: user burns the child-BTC and is added to w=
ithdrawal queue filled as part of validity requirements by childchain "=
;miners" until filled 1:1 on mainchain or more. Note that occasionally=
overpaying a widthdrawal does not break 1:1 peg as there's no fixed si=
ze 1:1 pool of coins necessary.</div><div><br></div><div>mainchain -> ch=
ildchain :: user burns BTC (independent of mining childchain) and is issued=
equivalent 1:1 child-BTC on the childchain</div><div><br></div><div>While =
childchains=C2=A0are less secure than the mainchain, both the childchain se=
curity and the 2-way-peg accuracy might be an acceptable option for lower v=
alue tx on scale determined by the burning rate.=C2=A0</div><div><br></div>=
<div>Childchains would replace the need for any additional Proof of Work ch=
ains for new blockchains to introduce any complexity (e.g. mimblewimble chi=
ldchain).</div><div><br></div><div>They would effectively use Proof of Work=
done on Bitcoin as proxy for unforgeable costliness and benefit from Bitco=
in's censorship resistance and data availability. Large numbers of low =
value tx that might be priced out of using the main chain could possibly in=
bulk provide enough childchain fees combined through childchain miners to =
afford much higher mainchain fees like "batching for fees".</div>=
<div><br></div><div>It also has the "benefits" claimed by proof o=
f stake like no energy consumption without relying on internal permissions =
or tokens, trusted distributions, or centralizing mechanisms like staking b=
y simulating proof of work. It should allow both growing the Bitcoin ecosys=
tem and replace the need to create alternative cryptocurrencies just to mak=
e a new blockchain.</div><div><br></div><div>More detailed write up availab=
le here:=C2=A0<a href=3D"https://bitcointalk.org/index.php?topic=3D5214173.=
0" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D5214173.0</a=
>=C2=A0=C2=A0</div><div><br></div><div>I am hoping for a review if there=
9;s an overlooked issue or maybe interest to create a proof of concept.</di=
v><div><br></div><div>Thank you</div><div>-CS</div></div></div>
--000000000000d40dcd05a8ef7b83--
|
