path: root/7a/587808be0dfcd932ea63d51d9796b10db9bf24

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