summaryrefslogtreecommitdiff
path: root/7a/587808be0dfcd932ea63d51d9796b10db9bf24
blob: 9758f5f27d11bb4d03a113479012174110fc7d8c (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
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 CA8D2C013A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 31 Dec 2020 23:26:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id AEE6086814
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 31 Dec 2020 23:26:43 +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 OzHUZSHg+Bl0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 31 Dec 2020 23:26:41 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch
 [185.70.40.140])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 236D0867FC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 31 Dec 2020 23:26:41 +0000 (UTC)
Date: Thu, 31 Dec 2020 23:26:24 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1609457195;
 bh=cdljkHICT32u6NSNFhRV3cvGnY5kEppvfm3qXSQkS5M=;
 h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
 b=vhX0HUORBrXO4nug7bMUtdRTLgxat4YMBGEUK5OYHvuPpOPTaCZ430zuMOatg/UWr
 knc/K5sPCKqcQRoA00cuR0a7fJZikaqFGIWKizWojU9Ywf8rG9eulU6cRV8ZBimAxs
 xG/e244EG+Ep6o6t2F8rFjSZqvLJDqc/8J7Y+i4M=
To: Ruben Somsen <rsomsen@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <6eK97Mb_R3DEEsCsBa7_t2qi8dEiChCRNWFowyTY-hrpDcKcR_lrb8tfWh6jMpzS5tz1GL8odiXRNig5W9F83ryZD2WQ7vjOFxoJatFhhSo=@protonmail.com>
In-Reply-To: <CAPv7TjaZEPviBw=tAk7eZ1Wc_FCdRuyHB0xK+Wr3QREB75BwHw@mail.gmail.com>
References: <CAPv7TjaZEPviBw=tAk7eZ1Wc_FCdRuyHB0xK+Wr3QREB75BwHw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Softchains: Sidechains as a Soft Fork via
	Proof-of-Work Fraud Proofs
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, 31 Dec 2020 23:26:43 -0000

Good morning Ruben, and list,

First and foremost --- what is the point of sidechains, in the first place?

If sidechains are for experimental new features, then softforking in a new =
sidechain with novel untested new features would be additionally risky --- =
as you note, a bug in the sidechain consensus may cause non-deterministic c=
onsensus in the sidechain which would propagate into mainchain.
Federated sidechains, which already are enabled on current Bitcoin, are saf=
er here, as mainchain will only care about the k-of-n signature that the fe=
deration agrees on, and if the federation is unable to come to consensus du=
e to a sidechain consensus bug, "fails safe" in that it effectively disable=
s the peg-out back to mainchain and restricts the consensus problem to the =
sidechain.

If sidechains are for scaling, then I would like to remind anyone reading t=
his that ***blockchains do not scale***, and adding more blockchains for th=
e purpose of scaling is *questionable*.
"I have a scaling problem.
I know, I will add a sidechain!
Now I have two scaling problems."

Ultimately, proof-of-work is about energy expenditure, and you would be spl=
itting the global energy budget for blockchain security among multiple bloc=
kchains, thus making each blockchain easier to 51%.

Regards,
ZmnSCPxj

> Hi everyone,
>
> This post describes a fully decentralized two-way peg sidechain design. A=
ctivating new sidechains requires a soft fork, hence the name softchains. T=
he key aspect is that all softchains are validated by everyone via Proof-of=
-Work Fraud Proofs (PoW FP) -- a slow but very efficient consensus mechanis=
m that only requires the validation of disputed blocks. This does increase =
the validation burden of mainchain full nodes, but only by a minimal amount=
 (~100MB per chain per year). It's similar to drivechains[0], but without t=
he major downside of having to rely on miners, since all Bitcoin full node =
users can efficiently validate each sidechain.
>
> Proof-of-Work Fraud Proofs
>
> Last year I posted the idea of PoW FP to the Bitcoin mailing list[1][2]. =
The idea is that we can use the existence of a fork in Bitcoin's PoW as evi=
dence that a block might be invalid (i.e. a proof of potential fraud). When=
ever this occurs, we download the block in question to verify whether it wa=
s valid (and available), and reject it if it was not. We forego the need fo=
r maintaining a UTXO set with UTXO set commitments (such as utreexo[3]), by=
 assuming that the commitment inside the last block to exist in both forks =
is valid. As a result, we only need to download as many blocks (and their c=
orresponding UTXO set proofs) as there are orphans, which lowers the valida=
tion costs considerably compared to running a full node.
>
> In the past 4 months, Forkmonitor has registered 11 stale and invalid blo=
cks[4]. Extrapolating from that data, a PoW FP node verifying Bitcoin conse=
nsus would have to download and verify a little over 100MB per year in orde=
r to have consensus guarantees that come close to that of a full node:
> - All PoW headers (~4MB per year)
> - 3 x 11 =3D 33 full blocks (~2MB x 33 =3D 66MB)
> - UTXO merkle proofs (~1MB x 33 =3D 33MB with utreexo)
>
> The reason consensus is considered slow, is because we need to allow time=
 for a honest PoW minority to fork away from an invalid chain. If we assume=
 only 1% of all miners are honest, this means consensus slows down by 100x.=
 If you are normally satisfied waiting for 6 confirmations, you now need to=
 wait 600 confirmations. The longer you wait, the less honest miners you ne=
ed.
>
> Softchains
>
> In order to have two-way pegged sidechains, you need a succinct method fo=
r proving to the mainchain that a peg-out is valid. PoW FP provides exactly=
 that -- a low-bandwidth way of determining if a chain, and thus a peg-out,=
 is valid. The slowness of PoW FP consensus is not an issue, as peg-outs ca=
n be made arbitrarily slow (e.g. one year).
>
> The safest design would be a set of softchains that shares its consensus =
code with Bitcoin Core, with the addition of UTXO set commitments, and disa=
bling non-taproot address types to minimize certain resource usage issues[5=
]. All users validate the mainchain as usual with their full node, and all =
softchains are validated with PoW FP consensus. If a user is interested in =
directly using a specific softchain, they should run it as a full node in o=
rder to get fast consensus.
>
> Peg-ins occur by freezing coins on the mainchain and assigning them to a =
softchain. Peg-outs occur by creating a mainchain transaction that points t=
o a peg-out transaction on a softchain and waiting for a sufficient number =
of mainchain confirmations. If the peg-out transaction remains part of the =
softchain according to PoW FP consensus, the coins become spendable.
>
> The peg-in/peg-out mechanism itself would require a soft fork (the exact =
design is an open question), and subsequently every softchain that gets act=
ivated will also require a soft fork.
>
> Potential dangers
>
> Softchain consensus still requires a form of validation from mainchain us=
ers, which means that consensus bugs can have an adverse effect. In particu=
lar, if a softchain suffers from a non-deterministic consensus bug, it may =
be the case that a majority accepts a peg-in, while a minority rejects it. =
This specific scenario could cause a chain split in mainchain consensus. Th=
is is why it would be safest to base softchain designs on Bitcoin Core.
>
> Similarly, it can theoretically be possible that a softchain gets a major=
 reorg, invalidating a peg-out right as it would have become accepted on th=
e mainchain, thus splitting consensus. The slow peg-out process makes this =
increasingly unlikely, but not impossible. One thing that might help (or pe=
rhaps only make it worse) is introducing a consensus rule that disallows re=
orgs that are bigger than half the peg-out time (e.g. half a year, if the p=
eg-out is one year). This kind of rule does not actually solve this consens=
us problem, but instead pushes the problem forward so it plays out first on=
 the softchain, giving time to take action before the problem affects the m=
ainchain.
>
> It is also important that each softchain produces a non-trivial amount of=
 PoW, because if the difficulty is too low, the cost of creating forks and =
increasing the resource usage of PoW FP consensus goes down. It may therefo=
re make sense to have a minimum accepted difficulty for softchain blocks (s=
lowing down the chain when fees are not sufficient). Merged Mining could al=
so help here, since that would allow the softchains to potentially receive =
the same hashrate as Bitcoin (assuming all miners participate), but of cour=
se this would also put an additional validation burden on miners.
>
> In closing
>
> It may turn out that the consensus risks outlined above make this prohibi=
tively risky, but at the very least it seems worth exploring the possibilit=
ies. At a minimum it would provide more opt-in block space, and it could po=
tentially open the door to chains with entirely different consensus rules.
>
> Thank you for taking the time to read and comprehend my work. I will happ=
ily answer any questions and I look forward to any feedback on issues that =
I might have overlooked, and ideas on mitigating problems to ensure maximum=
 safety.
>
> Hopefully this will bring decentralized two-way peg sidechains one step c=
loser to becoming a reality.
>
> Happy new year, everyone.
>
> -- Ruben Somsen
>
> This post is mirrored and kept up-to-date here:
> https://gist.github.com/RubenSomsen/7ecf7f13dc2496aa7eed8815a02f13d1
>
> [0] Drivechains
> https://www.drivechain.info/
>
> [1] PoW FP
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016873=
.html
>
> [2] PoW FP without a soft fork
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/01=
7287.html
>
> [3]: utreexo
> https://eprint.iacr.org/2019/611.pdf
>
> [4]: Forkmonitor
> https://forkmonitor.info/notifications
>
> [5]: Harding on worst-case utreexo
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-September/01=
7298.html