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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 5D1DEC016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2020 00:57:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 40C1187E97
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2020 00:57:27 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id J2Vnv8b3ec7a
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2020 00:57:25 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by whitealder.osuosl.org (Postfix) with ESMTPS id D8FAA87E96
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 26 Jun 2020 00:57:24 +0000 (UTC)
Date: Fri, 26 Jun 2020 00:57:13 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1593133042;
bh=NeHyCQMiAHXL3LNFIPSlTqcqav7ckj0xb6b47tiXGPc=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
b=v4aKXSt0Mo/7MBUVxeBRIVXz7OtJ9hN4H3H+RzD178dhG1L/XARmZh2FGveNkAnRP
fH3PULdJkC9IGO8RK3iLoiasbOCtNFtUOL/aQrHNMN0um8a/M3F+rKF4p+p+yVqlyL
rZxBrJjX1SQZAUygpgfprBQ5O/nrFIpeZMmPNHtY=
To: Cloud Strife <quantumas3@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <okQj-0Wqe15uKxpyE__yGosi6QkxODpX2AVkebxFNXN3NXHOSA-Q10N_CMj8hSI1UGLObVDdM-wvmIAb2pklg4jX_vVPlpsr6EMMry5d7MM=@protonmail.com>
In-Reply-To: <CAHeORgLcir=hZSoiDAE2hfttW71tiMNor0updmgRc2z-W-v=ow@mail.gmail.com>
References: <CAHeORgLcir=hZSoiDAE2hfttW71tiMNor0updmgRc2z-W-v=ow@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [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: Fri, 26 Jun 2020 00:57:27 -0000
Good morning CS,
The difficulty is not so much the proof-of-whatever, but rather, the peg it=
self.
My understanding of your pegout from sidechain to mainchain is that this pe=
gout is very low-bandwidth, i.e. only a tiny amount can be pegged out at ea=
ch mainchain block.
This suggests to me that the sidecoin can still drop lower than maincoin du=
ring times when overall side-to-main flows are higher than main-to-side flo=
ws.
(atomic swaps cannot *maintain* a peg, they can only follow a peg if it exi=
sts; if the peg is weak, atomic swaps cannot strengthen it.
this is because atomic swaps allow a non-1:1 exchange rate, as in cross-cur=
rency atomic swaps.)
In any case, from my reading of your text, I seem, the goal is scaling ("ac=
ceptable option for lower value tx").
I studied sidechains some years ago, and, came to the conclusion that sidec=
hains are not good for scaling.
We already know that blockchains do not scale well (excessive bandwidth use=
, permanent records needed to support newcomers); thus, the scaling solutio=
n for cryptocurrency cannot be via **more** blockchains.
Hence, Lightning Network.
In Lightning Network, every channel is a consensus system between two parti=
cipants, hence every channel is a 2-of-2 (i.e. requires consensus of both p=
articipants to advance).
We use atomic swaps to transfer between channels and the blockchain.
The channel construction requires reference to an ultimate arbiter of any d=
ispute/non-consensus between the channel participants; this is provided by =
the blockchain layer off which the channel is based.
Thus blockchain for arbitration, channels for scaling.
Regards,
ZmnSCPxj
> Hi everyone,
>
> 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 i=
tself 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 t=
he childchain.
>
> 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 childchain block commits.
>
> The only asset on the childchain=C2=A0is a 2-way-peg coin that's secured =
in value without oracles or collateral by requiring that each valid child c=
hain block must not only burn Bitcoin, but must always use a small % of the=
burnt amount to deterministically reimburse=C2=A0withdrawals from the chil=
dchain.
>
> Childchain -> mainchain :: user burns the child-BTC and is added to withd=
rawal 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 coi=
ns necessary.
>
> mainchain -> childchain :: user burns BTC (independent of mining childcha=
in) and is issued equivalent 1:1 child-BTC on the childchain
>
> While childchains=C2=A0are less secure than the mainchain, both the child=
chain security and the 2-way-peg accuracy might be an acceptable option for=
lower value tx on scale determined by the burning rate.=C2=A0
>
> Childchains would replace the need for any additional Proof of Work chain=
s for new blockchains to introduce any complexity (e.g. mimblewimble childc=
hain).
>
> They would effectively use Proof of Work done on Bitcoin as proxy for unf=
orgeable costliness and benefit from Bitcoin's censorship resistance and da=
ta 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 lik=
e "batching for fees".
>
> It also has the "benefits" claimed by proof of stake like no energy consu=
mption without relying on internal permissions or tokens, trusted distribut=
ions, 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:=C2=A0https://bitcointalk.org/index=
.php?topic=3D5214173.0=C2=A0=C2=A0
>
> I am hoping for a review if there's an overlooked issue or maybe interest=
to create a proof of concept.
>
> Thank you
> -CS
|
