Re: [bitcoin-dev] Drivechain: BIP 300 and 301

[Prayank <prayank@tutanota.de>]

[-- Attachment #1: Type: text/plain, Size: 11207 bytes --]

Good morning ZmnSCPxj,

Thanks for sharing all the details. One thing that I am not sure about:

> * 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 experiment with lot of things on sidechains to scale which isn't true for Bitcoin. 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 the same? I am not sure.

LND: https://github.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://developers.rsk.co/rsk/node/install/

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

Smart contracts are possible on Bitcoin but with limited functionality so lot of applications are not possible using Bitcoin (Layer1). Some of these don't even make sense on Layer 1 and create other issues like MEV however deploying them on sidechains 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 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 helpful for everyone trying to 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 knowledge, are Drivechain systems.
>
> Instead, they are both federated sidechains.
> The money owned by a federated sidechain is, as far s the Bitcoin blockchain is concerned, really owned by the federation that.runs the sidechain.
>
> Basically, a mainchain->sidechain transfer is done by paying to a federation 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 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 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 predetermined 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 completely, and the mainchain would 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 personality disorder, that happens to use a blockchain to keep its individual sub-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 separate blockchain called the "sidechain" --- it is simply that a blockchain is used to coordinate the custodians of the coin, but in principle any other coordination mechanism can be used between them, including a plain database.
>
>
> With Drivechains, custody of the sidechain funds is held by mainchain miners.
> 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 concern.
>
> 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 blockchain.
> 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 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.
> 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% attack 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 helping 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), then coins you owned that were deeply confirmed remain under your control.
>
> With Drivechains, however, sidechain funds can be confiscated by a 51% attacker, by forcing a bogus sidechain->mainchain withdrawal.
> The amount of time it takes is simply the security parameter of the Drivechain spec.
> It does not matter if you were holding 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 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->mainchin 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 approximately equal to coins entering the sidechain (remember, it is an *exchange*, 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 if the Drivechain security parameter (which secures sidechains from 51% attack confiscation)
> In a "thundering herd" situation, the peg can be lost, meaning that sidechain 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 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, 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 large 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 simply cause everyone to evict all 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 of a sidechain can effectively "infect" mainchain, with competing mainchain miners 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 better off getting a bunch of developer friends together and creating a federation 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 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 Liquid, 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 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 mainchain 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 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 protocol 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 safely 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 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 atomic swap mechanism of some kind so that you pay your couterparty if that couterparty pays the third party.
>
> And guess what?
> That is just Lightning Network.
>
> Regards,
> ZmnSCPxj
>


[-- Attachment #2: Type: text/html, Size: 13286 bytes --]