Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id BEAA7C000E for ; Fri, 3 Sep 2021 09:47:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id A65C161490 for ; Fri, 3 Sep 2021 09:47:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 (2048-bit key) header.d=tutanota.de 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 be0-9csZocjg for ; Fri, 3 Sep 2021 09:47:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) by smtp3.osuosl.org (Postfix) with ESMTPS id 83A6B605E7 for ; Fri, 3 Sep 2021 09:47:48 +0000 (UTC) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w1.tutanota.de (Postfix) with ESMTP id B1D9CFA0564; Fri, 3 Sep 2021 09:47:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1630662465; s=s1; d=tutanota.de; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=d5kfYLCiQ0pfUXyxct8Vjr3rWxJuuTtJoK12c5ad+qI=; b=WZ0nsXWql+o8gU6enY2TDpJVfJ8MzuMDHOANsNE5k44Zrz22GFXm2mttpw2a6Yvm tHe5E9WtKpcCDUPyr4eRzXxz0S2zeLiAfFS4pf6sZxAfM2h+Qm0N0Rq3ZnsoNQmL09w 983P30tl9tNyggwqhkh2Gh6MuwO2Qh+lTHB1Wfgf+Qxv6YpTlcMcYb4FyK8HeyzXo4G /Gjxe+jChNKNrpe2AuWrvOBQaqyLFklGKPWQLQATfNHntrsusUNv+oee5VKaqb/hGvG O42eVx7Pl91Cfxb0BYOd2d/Zy6MPBWLXf97afs44KhyzfWdPsB4jbfCy12NbbHSiDZv h9pK/ZkBNg== Date: Fri, 3 Sep 2021 11:47:45 +0200 (CEST) From: Prayank To: ZmnSCPxj Message-ID: In-Reply-To: <3dyAATLXbsE7WBzpVIc0s4sRkSFhR_5NN04uUgx3o9LH48IKR6EHL3V45PfpRM96yxHXdsjd7WC7MGuPlBw7MRpCkpXRsB-WI7i3-Nr13Ew=@protonmail.com> References: <3dyAATLXbsE7WBzpVIc0s4sRkSFhR_5NN04uUgx3o9LH48IKR6EHL3V45PfpRM96yxHXdsjd7WC7MGuPlBw7MRpCkpXRsB-WI7i3-Nr13Ew=@protonmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_69236_1936841571.1630662465710" X-Mailman-Approved-At: Fri, 03 Sep 2021 10:09:40 +0000 Cc: Bitcoin Dev 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2021 09:47:50 -0000 ------=_Part_69236_1936841571.1630662465710 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Good morning=C2=A0ZmnSCPxj, Thanks for sharing all the details. One thing that I am not sure about: >=C2=A0* We already ***know*** that blockchains cannot scale > * Your plan for scaling is to make ***more*** blockchains? Scaling Bitcoin can be different from scaling Bitcoin sidechains. You can e= xperiment with lot of things on sidechains to scale which isn't true for Bi= tcoin. Most important thing is requirements for running a node differ. Its = easy to run a node for LN, Liquid and Rootstock right now. Will it remain t= he same? I am not sure. LND:=C2=A0https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.= md Liquid:=C2=A0https://help.blockstream.com/hc/en-us/articles/900002026026-Ho= w-do-I-set-up-a-Liquid-node- Rootstock:=C2=A0https://developers.rsk.co/rsk/node/install/ >=C2=A0More to the point: what are sidechains **for**? Smart contracts are possible on Bitcoin but with limited functionality so l= ot of applications are not possible using Bitcoin (Layer1). Some of these d= on't even make sense on Layer 1 and create other issues like MEV however de= ploying them on sidechains should not affect base layer. >=C2=A0Increasing the Drivechain security parameter leads to slower sidecha= in->mainchin withdrawals, effectively a bottleneck on how much can be trans= ferred sidechain->mainchain. I think 'withdrawals' is the part which can be improved in Drivechain. Not = sure about any solution at this point or trade-offs involved but making few= changes can help Drivechain and Bitcoin. I agree with everything else you explained and emails like these will be he= lpful for everyone trying to understand what's going on with Layer 2 on Bit= coin. --=20 Prayank A3B1 E430 2298 178F Sep 3, 2021, 02:32 by ZmnSCPxj@protonmail.com: > Good morning Prayank, > > Just to be clear, neither Liquid nor RSK, as of my current knowledge, are= Drivechain systems. > > Instead, they are both federated sidechains. > The money owned by a federated sidechain is, as far s the Bitcoin blockch= ain is concerned, really owned by the federation that.runs the sidechain. > > Basically, a mainchain->sidechain transfer is done by paying to a federat= ion k-of-n address and a coordination signal of some kind (details dependin= g on federated sidechain) to create the equivalent coins on the sidechain. > A sidechain->mainchain transfer is done by requesting some coins on the s= idechain to be destroyed, and then the federation will send some of its mai= nchain k-of-n coins into whatever address you indicate you want to use on t= he mainchain. > > In theory, a sufficient quorum of the federation can decide to ignore the= sidechain data entirely and spend the mainchain money arbitrarily, and the= mainchain layer will allow this (being completely ignorant of he sidechain= ). > > In such federated sidechains, the federation is often a fixed predetermin= ed signing set, and changes to that federation are expected to be rare. > > Federated sidechains are ultimately custodial; as noted above, the federa= tion could in theory abscond with the funds completely, and the mainchain w= ould not care if the sidechain federation executes its final exit strategy = and you lose your funds. > One can consider federated sidechains to be a custodian with multiple per= sonality disorder, that happens to use a blockchain to keep its individual = sub-personalities coordinated with each other, but ultimately control of th= e money is contingent on the custodian following the dictates of the suppos= ed owners of the coin. > From a certain point of view, it is actually immaterial that there is a s= eparate blockchain called the "sidechain" --- it is simply that a blockchai= n is used to coordinate the custodians of the coin, but in principle any ot= her coordination mechanism can be used between them, including a plain data= base. > > > With Drivechains, custody of the sidechain funds is held by mainchain min= ers. > Again, this is still a custodial setup. > A potential issue here is that the mainchain miners cannot be identified = (the entire point is anonymity of miners is possible), which may be of conc= ern. > > In particular, note that solely on mainchain, all that miners determine i= s the *ordering* and *timing* of transactions. > Let us suppose that there is a major 51% attack attempt on the Bitcoin bl= ockchain. > We expect that such an attack will be temporary --- individuals currently= not 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 protec= t their stacks rather than lose it. > Thus, we expect that a 51% attack will be temporary, as other miners will= arise 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% att= ack is expected to take about 4 years before it can begin to threaten your = ownership of those coins (hopefully, in those 4 years, you will get a clue = and start mining at a loss to protect your funds from outright loss, thus h= elping evict the 51% attacker). > 51% miners can, in practice, only prevent transfers (censorship), not for= ce transfer of funds (confiscation). > Once the 51% attacker is evicted (and they will in general be evicted), t= hen coins you owned that were deeply confirmed remain under your control. > > With Drivechains, however, sidechain funds can be confiscated by a 51% at= tacker, by forcing a bogus sidechain->mainchain withdrawal. > The amount of time it takes is simply the security parameter of the Drive= chain spec. > It does not matter if you were holding those funds in the sidechain for s= everal years without moving them --- a 51% attacker that is able to keep co= ntrol of the mainchain blockchain, for the Drivechain security parameter, w= ill be capable of confiscating sidechain funds outright. > Thus, even if the 51% attacker is evicted, then your coins in the sidecha= in can be confiscated and no longer under your control. > > Increasing the Drivechain security parameter leads to slower sidechain->m= ainchin withdrawals, effectively a bottleneck on how much can be transferre= d sidechain->mainchain. > While exchanges may exist that allow sidechain->mainchain withdrawal fast= er, those can only operate if the number of coins exiting the sidechain is = approximately equal to coins entering the sidechain (remember, it is an *ex= change*, coins are not actually moved from one to the other). > If there is a "thundering herd" problem, then exchanges will saturate and= the sidechain->mainchain withdrawal mechanism has to come into play, and i= f the Drivechain security parameter (which secures sidechains from 51% atta= ck confiscation) > In a "thundering herd" situation, the peg can be lost, meaning that sidec= hain coins become devalued relative to mainchain coins they are purportedly= equivalent to. > > A "thundering herd" exiting the sidechain can happen, for example, if the= sidechain is primarily used to prototype a new feature, and the feature is= demonstrably so desirable that Bitcoin Core actually adds it. > In that case, the better security of the mainchain becomes desirable, and= the sidechain no longer has a unique feature to incentivize keeping your f= unds there (since mainchain has/will have that feature). > In that case, the sidechain coin value can transiently drop due to the si= dechain->mainchain withdrawal bottleneck caused by the Drivechain security = parameter. > And if the value can temporarily drop, well, it is not much of a peg, the= n. > > * If the Drivechain security parameter is too low, then a short 51% attac= k is enough to confiscate all sidechain coins. > * If the Drivechain seucrity parameter is too large, then a coincidental = large number of sidechain->mainchain exits risks triggering a thundering he= rd that temporarily devalues the sidechain value relative to mainchain. > > Against 51% attack confiscation, Paul Sztorc I believe proposes a "nuclea= r option" where mainchain fullnodes are upgraded to ignore historical block= s created by the 51% attacker. > The point is that a 51% attacker takes on the risk that confiscation will= simply cause everyone to evict all miners and possibly destroy Bitcoin ent= irely, and rational 51% attackers will not do so, since then their mining h= ardware becomes useless. > I believe this leads to a situation where a controversial chainsplit of a= sidechain can effectively "infect" mainchain, with competing mainchain min= ers with different views of the sidechain censoring each other, thus removi= ng 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 b= etter off getting a bunch of developer friends together and creating a fede= ration that runs the sidechain so you can tinker on new features with frien= ds. > * This is how SegWit was prototyped in Elements Alpha, the predecessor o= f 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= to 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 Liqui= d, or miner federations like in Drivechains) have custodial risk if you put= your funds in them. > The only way to avoid the custodial risk is if ***you*** were one of the = signatories of the federation, and the federation was an n-of-n. > > Now, let us consider a 2-of-2 federation, the smallest possible federatio= n. > As long as *you* are one of the two signatories, you have no custodial ri= sk in putting funds in this federation --- nothing can happen to the mainch= ain funds without your say-so, so the federation cannot confiscate your fun= ds. > > And again, there is no real need to use a big, inefficient data structure= like a **blockchain**. > In fact, in a 2-of-2 federation, there are only two members, so a lot of = the blockchain overhead can be reduced to just a bunch of fairly simple pro= tocol messages you send to each other, no need for a heavy history-retainin= g append-only data structure. > > Of course, only you and the other signatory in this 2-of-2 federation can= safely keep funds in that federation. > You cannot pay a third party with those funds, because that third party n= ow takes on custodial risk, you and your coutnerparty can collude to steal = the funds of the third party. > However, suppose your counterparty was a member of another 2-of-2 federat= ion, 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 co= uterparty if that couterparty pays the third party. > > And guess what? > That is just Lightning Network. > > Regards, > ZmnSCPxj > ------=_Part_69236_1936841571.1630662465710 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good morning ZmnSCPxj,

Thanks for sharing all the details. One thing that I am not su= re about:

> = * We already ***know*** that blockchains cannot scale
> * Your plan for scaling is to make ***more*** blockchains?

Scaling Bitcoin can be di= fferent from scaling Bitcoin sidechains. You can experiment with lot of thi= ngs on sidechains to scale which isn't true for Bitcoin. Most important thi= ng is requirements for running a node differ. Its easy to run a node for LN= , Liquid and Rootstock right now. Will it remain the same? I am not sure.

LND: https://git= hub.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md

Liquid: https://help.blockstream= .com/hc/en-us/articles/900002026026-How-do-I-set-up-a-Liquid-node-

Rootstock: https://deve= lopers.rsk.co/rsk/node/install/

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

Smart contracts are possi= ble on Bitcoin but with limited functionality so lot of applications are no= t possible using Bitcoin (Layer1). Some of these don't even make sense on L= ayer 1 and create other issues like MEV however deploying them on sidechain= s should not affect base layer.

> Increasing the Drivechain security parameter leads to= slower sidechain->mainchin withdrawals, effectively a bottleneck on how= much can be transferred sidechain->mainchain.

I think 'withdrawals' is the part which can b= e improved in Drivechain. Not sure about any solution at this point or trad= e-offs involved but making few changes can help Drivechain and Bitcoin.

I agree with everything els= e you explained and emails like these will be helpful for everyone trying t= o understand what's going on with Layer 2 on Bitcoin.

--
Prayank

A3B1 E430 2298 178F



=
Sep 3, 2021, 02:32 by ZmnSCPxj@protonmail.com:
Good morning Prayank,

Just to be clear, neither Liquid nor RSK, as of my current knowled= ge, are Drivechain systems.

Instead, they are = both federated sidechains.
The money owned by a federated sid= echain is, as far s the Bitcoin blockchain is concerned, really owned by th= e federation that.runs the sidechain.

Basicall= y, a mainchain->sidechain transfer is done by paying to a federation k-o= f-n address and a coordination signal of some kind (details depending on fe= derated sidechain) to create the equivalent coins on the sidechain.
A sidechain->mainchain transfer is done by requesting some coins = on the sidechain to be destroyed, and then the federation will send some of= its mainchain 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 sidechain data entirely a= nd spend the mainchain money arbitrarily, and the mainchain layer will allo= w this (being completely ignorant of he sidechain).

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

Federated sidechains are ultimately custodial= ; as noted above, the federation could in theory abscond with the funds com= pletely, and the mainchain would not care if the sidechain federation execu= tes its final exit strategy and you lose your funds.
One can = consider federated sidechains to be a custodian with multiple personality d= isorder, that happens to use a blockchain to keep its individual sub-person= alities 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 imm= aterial that there is a separate blockchain called the "sidechain" --- it i= s simply that a blockchain is used to coordinate the custodians of the coin= , but in principle any other coordination mechanism can be used between the= m, including a plain database.


= With Drivechains, custody of the sidechain funds is held by mainchain miner= s.
Again, this is still a custodial setup.
A po= tential issue here is that the mainchain miners cannot be identified (the e= ntire point is anonymity of miners is possible), which may be of concern.

In particular, note that solely on mainchain, a= ll that miners determine is the *ordering* and *timing* of transactions.
Let us suppose that there is a major 51% attack attempt on the = Bitcoin blockchain.
We expect that such an attack will be tem= porary --- individuals currently not mining may find that their HODLings ar= e under threat of the 51% attack, and may find it more economic to run mine= rs 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 arise inevitably to take back control of transaction processing.
<= /div>
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 hav= e not moved since 2017, for example, the 51% attack is expected to take abo= ut 4 years before it can begin to threaten your ownership of those coins (h= opefully, in those 4 years, you will get a clue and start mining at a loss = to protect your funds from outright loss, thus helping evict the 51% attack= er).
51% miners can, in practice, only prevent transfers (cen= sorship), not force transfer of funds (confiscation).
Once th= e 51% attacker is evicted (and they will in general be evicted), then coins= you owned that were deeply confirmed remain under your control.
<= div>
With Drivechains, however, sidechain funds can be confis= cated by a 51% attacker, by forcing a bogus sidechain->mainchain withdra= wal.
The amount of time it takes is simply the security param= eter of the Drivechain spec.
It does not matter if you were h= olding those funds in the sidechain for several years without moving them -= -- a 51% attacker that is able to keep control of the mainchain blockchain,= for the Drivechain security parameter, will be capable of confiscating sid= echain funds outright.
Thus, even if the 51% attacker is evic= ted, then your coins in the sidechain can be confiscated and no longer unde= r your control.

Increasing the Drivechain secu= rity parameter leads to slower sidechain->mainchin withdrawals, effectiv= ely a bottleneck on how much can be transferred sidechain->mainchain.
While exchanges may exist that allow sidechain->mainchain wi= thdrawal faster, those can only operate if the number of coins exiting the = sidechain is approximately equal to coins entering the sidechain (remember,= it is an *exchange*, coins are not actually moved from one to the other).<= br>
If there is a "thundering herd" problem, then exchanges will = saturate and the sidechain->mainchain withdrawal mechanism has to come i= nto play, and if the Drivechain security parameter (which secures sidechain= s from 51% attack confiscation)
In a "thundering herd" situat= ion, the peg can be lost, meaning that sidechain coins become devalued rela= tive to mainchain coins they are purportedly equivalent to.
<= br>
A "thundering herd" exiting the sidechain can happen, for exa= mple, if the sidechain is primarily used to prototype a new feature, and th= e feature is demonstrably so desirable that Bitcoin Core actually adds it.<= br>
In that case, the better security of the mainchain becomes de= sirable, and the sidechain no longer has a unique feature to incentivize ke= eping your funds there (since mainchain has/will have that feature).
In that case, the sidechain coin value can transiently drop due to = the sidechain->mainchain withdrawal bottleneck caused by the Drivechain = security parameter.
And if the value can temporarily drop, we= ll, it is not much of a peg, then.

* If the Dr= ivechain security parameter is too low, then a short 51% attack is enough t= o confiscate all sidechain coins.
* If the Drivechain seucrit= y parameter is too large, then a coincidental large number of sidechain->= ;mainchain exits risks triggering a thundering herd that temporarily devalu= es 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 simply cause everyone to evict al= l miners and possibly destroy Bitcoin entirely, and rational 51% attackers = will not do so, since then their mining hardware becomes useless.
=
I believe this leads to a situation where a controversial chainsplit o= f a sidechain can effectively "infect" mainchain, with competing mainchain = miners with different views of the sidechain censoring each other, thus rem= oving isolation of the sidechain from the mainchain.

--

More to the point: what are sidechai= ns **for**?

* If sidechains are for prototypin= g new features, then you are probably better off getting a bunch of develop= er friends together and creating a federation that runs the sidechain so yo= u can tinker on new features with friends.
* This is how Seg= Wit was prototyped in Elements Alpha, the predecessor of Liquid.
<= div>* If sidechains are for scaling, then:
* We already ***k= now*** that blockchains cannot scale.
* Your plan for scalin= g is to make ***more*** blockchains?
Which we know cannot sc= ale, right?
* Good luck.

Now, i= f we were to consider scaling...

As I pointed = out above, in principle a federated sidechain simply decided to use a block= chain to coordinate the federation members.
Nothing really pr= events the federation from using a different mechanims.

<= /div>
In addition, federations (whether signer federations like in RSK = or Liquid, or miner federations like in Drivechains) have custodial risk if= you put your funds in them.
The only way to avoid the custod= ial risk is if ***you*** were one of the signatories of the federation, and= the federation was an n-of-n.

Now, let us con= sider 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 bi= g, inefficient data structure like a **blockchain**.
In fact,= in a 2-of-2 federation, there are only two members, so a lot of the blockc= hain overhead can be reduced to just a bunch of fairly simple protocol mess= ages you send to each other, no need for a heavy history-retaining append-o= nly data structure.

Of course, only you and th= e other signatory in this 2-of-2 federation can safely keep funds in that f= ederation.
You cannot pay a third party with those funds, bec= ause that third party now takes on custodial risk, you and your coutnerpart= y can collude to steal the funds of the third party.
However,= suppose your counterparty was a member of another 2-of-2 federation, this = time with the third party you want to pay.
You can use an ato= mic swap mechanism of some kind so that you pay your couterparty if that co= uterparty pays the third party.

And guess what= ?
That is just Lightning Network.

Regards,
ZmnSCPxj
<= br>
------=_Part_69236_1936841571.1630662465710--