path: root/2d/c62296947ebd354c49c9cd913e64180ee0bf9c

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D53F3C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Sep 2021 21:03:05 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id C848C606E3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Sep 2021 21:03:05 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level: 
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=protonmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Jxc1eFDlL6HV
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Sep 2021 21:03:04 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 452306075D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  2 Sep 2021 21:03:04 +0000 (UTC)
Date: Thu, 02 Sep 2021 21:02:55 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1630616580;
 bh=6qLOdWwPcwQer5PDtDkfvsABqRltZ5zZftQfZrja0QY=;
 h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From;
 b=fre9Fpp7VKQ3zr0OwISlo3DjLWgxbLRWdfEDci6Lwgv0zcQQsOwtb2uPewca3eUq5
 KlR9AvXMThPyukWAmkvb4OQyQtE3N9Kja0lGI6/yisnDa+gEoIrF3tgeRtnTT85hYn
 EOHBDM7NdtRNczzZkX6TahyNIuFHKoHS1X2g0gAQ=
To: Prayank <prayank@tutanota.de>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <3dyAATLXbsE7WBzpVIc0s4sRkSFhR_5NN04uUgx3o9LH48IKR6EHL3V45PfpRM96yxHXdsjd7WC7MGuPlBw7MRpCkpXRsB-WI7i3-Nr13Ew=@protonmail.com>
In-Reply-To: <MibU_fn--3-2@tutanota.de>
References: <MibU_fn--3-2@tutanota.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Drivechain: BIP 300 and 301
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, 02 Sep 2021 21:03:06 -0000

Good morning Prayank,

Just to be clear, neither Liquid nor RSK, as of my current knowledge, are D=
rivechain systems.

Instead, they are both federated sidechains.
The money owned by a federated sidechain is, as far s the Bitcoin blockchai=
n is concerned, really owned by the federation that.runs the sidechain.

Basically, a mainchain->sidechain transfer is done by paying to a federatio=
n k-of-n address and a coordination signal of some kind (details depending =
on federated sidechain) to create the equivalent coins on the sidechain.
A sidechain->mainchain transfer is done by requesting some coins on the sid=
echain to be destroyed, and then the federation will send some of its mainc=
hain k-of-n coins into whatever address you indicate you want to use on the=
 mainchain.

In theory, a sufficient quorum of the federation can decide to ignore the s=
idechain data entirely and spend the mainchain money arbitrarily, and the m=
ainchain layer will allow this (being completely ignorant of he sidechain).

In such federated sidechains, the federation is often a fixed predetermined=
 signing set, and changes to that federation are expected to be rare.

Federated sidechains are ultimately custodial; as noted above, the federati=
on could in theory abscond with the funds completely, and the mainchain wou=
ld not care if the sidechain federation executes its final exit strategy an=
d you lose your funds.
One can consider federated sidechains to be a custodian with multiple perso=
nality disorder, that happens to use a blockchain to keep its individual su=
b-personalities coordinated with each other, but ultimately control of the =
money is contingent on the custodian following the dictates of the supposed=
 owners of the coin.
From a certain point of view, it is actually immaterial that there is a sep=
arate blockchain called the "sidechain" --- it is simply that a blockchain =
is used to coordinate the custodians of the coin, but in principle any othe=
r coordination mechanism can be used between them, including a plain databa=
se.


With Drivechains, custody of the sidechain funds is held by mainchain miner=
s.
Again, this is still a custodial setup.
A potential issue here is that the mainchain miners cannot be identified (t=
he entire point is anonymity of miners is possible), which may be of concer=
n.

In particular, note that solely on mainchain, all that miners determine is =
the *ordering* and *timing* of transactions.
Let us suppose that there is a major 51% attack attempt on the Bitcoin bloc=
kchain.
We expect that such an attack will be temporary --- individuals currently n=
ot mining may find that their HODLings are under threat of the 51% attack, =
and may find it more economic to run miners at a loss, in order to protect =
their stacks rather than lose it.
Thus, we expect that a 51% attack will be temporary, as other miners will a=
rise inevitably to take back control of transaction processing.
https://github.com/libbitcoin/libbitcoin-system/wiki/Threat-Level-Paradox

In particular, on the mainchain, 51% miners cannot reverse deep history.
If you have coins you have not moved since 2017, for example, the 51% attac=
k is expected to take about 4 years before it can begin to threaten your ow=
nership of those coins (hopefully, in those 4 years, you will get a clue an=
d start mining at a loss to protect your funds from outright loss, thus hel=
ping evict the 51% attacker).
51% miners can, in practice, only prevent transfers (censorship), not force=
 transfer of funds (confiscation).
Once the 51% attacker is evicted (and they will in general be evicted), the=
n coins you owned that were deeply confirmed remain under your control.

With Drivechains, however, sidechain funds can be confiscated by a 51% atta=
cker, by forcing a bogus sidechain->mainchain withdrawal.
The amount of time it takes is simply the security parameter of the Drivech=
ain spec.
It does not matter if you were holding those funds in the sidechain for sev=
eral years without moving them --- a 51% attacker that is able to keep cont=
rol of the mainchain blockchain, for the Drivechain security parameter, wil=
l be capable of confiscating sidechain funds outright.
Thus, even if the 51% attacker is evicted, then your coins in the sidechain=
 can be confiscated and no longer under your control.

Increasing the Drivechain security parameter leads to slower sidechain->mai=
nchin withdrawals, effectively a bottleneck on how much can be transferred =
sidechain->mainchain.
While exchanges may exist that allow sidechain->mainchain withdrawal faster=
, those can only operate if the number of coins exiting the sidechain is ap=
proximately equal to coins entering the sidechain (remember, it is an *exch=
ange*, coins are not actually moved from one to the other).
If there is a "thundering herd" problem, then exchanges will saturate and t=
he sidechain->mainchain withdrawal mechanism has to come into play, and if =
the Drivechain security parameter (which secures sidechains from 51% attack=
 confiscation)
In a "thundering herd" situation, the peg can be lost, meaning that sidecha=
in coins become devalued relative to mainchain coins they are purportedly e=
quivalent to.

A "thundering herd" exiting the sidechain can happen, for example, if the s=
idechain is primarily used to prototype a new feature, and the feature is d=
emonstrably so desirable that Bitcoin Core actually adds it.
In that case, the better security of the mainchain becomes desirable, and t=
he sidechain no longer has a unique feature to incentivize keeping your fun=
ds there (since mainchain has/will have that feature).
In that case, the sidechain coin value can transiently drop due to the side=
chain->mainchain withdrawal bottleneck caused by the Drivechain security pa=
rameter.
And if the value can temporarily drop, well, it is not much of a peg, then.

* If the Drivechain security parameter is too low, then a short 51% attack =
is enough to confiscate all sidechain coins.
* If the Drivechain seucrity parameter is too large, then a coincidental la=
rge number of sidechain->mainchain exits risks triggering a thundering herd=
 that temporarily devalues the sidechain value relative to mainchain.

Against 51% attack confiscation, Paul Sztorc I believe proposes a "nuclear =
option" where mainchain fullnodes are upgraded to ignore historical blocks =
created by the 51% attacker.
The point is that a 51% attacker takes on the risk that confiscation will s=
imply cause everyone to evict all miners and possibly destroy Bitcoin entir=
ely, and rational 51% attackers will not do so, since then their mining har=
dware becomes useless.
I believe this leads to a situation where a controversial chainsplit of a s=
idechain can effectively "infect" mainchain, with competing mainchain miner=
s with different views of the sidechain censoring each other, thus removing=
 isolation of the sidechain from the mainchain.

--

More to the point: what are sidechains **for**?

* If sidechains are for prototyping new features, then you are probably bet=
ter off getting a bunch of developer friends together and creating a federa=
tion that runs the sidechain so you can tinker on new features with friends=
.
  * This is how SegWit was prototyped in Elements Alpha, the predecessor of=
 Liquid.
* If sidechains are for scaling, then:
  * We already ***know*** that blockchains cannot scale.
  * Your plan for scaling is to make ***more*** blockchains?
    Which we know cannot scale, right?
  * Good luck.

Now, if we were to consider scaling...

As I pointed out above, in principle a federated sidechain simply decided t=
o use a blockchain to coordinate the federation members.
Nothing really prevents the federation from using a different mechanims.

In addition, federations (whether signer federations like in RSK or Liquid,=
 or miner federations like in Drivechains) have custodial risk if you put y=
our funds in them.
The only way to avoid the custodial risk is if ***you*** were one of the si=
gnatories of the federation, and the federation was an n-of-n.

Now, let us consider a 2-of-2 federation, the smallest possible federation.
As long as *you* are one of the two signatories, you have no custodial risk=
 in putting funds in this federation --- nothing can happen to the mainchai=
n funds without your say-so, so the federation cannot confiscate your funds=
.

And again, there is no real need to use a big, inefficient data structure l=
ike a **blockchain**.
In fact, in a 2-of-2 federation, there are only two members, so a lot of th=
e blockchain overhead can be reduced to just a bunch of fairly simple proto=
col messages you send to each other, no need for a heavy history-retaining =
append-only data structure.

Of course, only you and the other signatory in this 2-of-2 federation can s=
afely keep funds in that federation.
You cannot pay a third party with those funds, because that third party now=
 takes on custodial risk, you and your coutnerparty can collude to steal th=
e funds of the third party.
However, suppose your counterparty was a member of another 2-of-2 federatio=
n, this time with the third party you want to pay.
You can use an atomic swap mechanism of some kind so that you pay your cout=
erparty if that couterparty pays the third party.

And guess what?
That is just Lightning Network.

Regards,
ZmnSCPxj