Date: Thu, 02 Sep 2021 21:02:55 +0000
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
Precedence: list

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