[bitcoin-dev] Drivechain: BIP 300 and 301

[bitcoin-dev] Drivechain: BIP 300 and 301

[Prayank]

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

printf("Hello, World!");

What are your thoughts on Drivechain and associated BIPs?

This article compares Liquid and Lightning: https://blog.liquid.net/six-differences-between-liquid-and-lightning/. Two things from it that I am interested in while evaluating Drivechain:

1.Trust model
2.On-Ramps and Off-Ramps

Other things:

1.Security of Bitcoin (Layer 1)
2.Bitcoin transactions and fees expected on layer 1 because of Drivechain

Similarities and Differences between RSK and Ethereum: https://medium.com/iovlabs-innovation-stories/similarities-and-differences-between-rsk-and-ethereum-e480655eff37

Paul Sztorc had mentioned few things about fees in this video: https://youtu.be/oga8Pwbq9M0?t=481 I am interested to know same for LN, Liquid and Rootstock as well so asked a question on Bitcoin Stackexchange today: https://bitcoin.stackexchange.com/questions/109466/bitcoin-transactions-associated-with-layer-2-projects

Two critiques are mentioned here: https://www.drivechain.info/peer-review/peer-review-new/ with lot of names. I don't agree with everything mentioned on project website although any comments on technical things that can help Bitcoin and Bitcoin projects will be great.

Why discuss here and not on Twitter?

1.Twitter is not the best place for such discussions. There are some interesting threads but Its mostly used for followers, likes, retweets etc. and people can write anything for it.
2.Avoid misinformation, controversies etc. 

My personal opinion:

We should encourage sidechain projects. I don't know much about Drivechain to form a strong opinion but concept looks good which can help in making better sidechains.

----------------------------------------------------------------------------------------------------------------------


The website used in the slides of above YouTube video is misleading for few reasons:

1.Blocks mined everyday (in MB) for Bitcoin is ~150 MB. It is ~600 MB for Ethereum. Block limits for Bitcoin is ~4 MB per 10 minutes and ~500 MB for Ethereum. If full nodes will be run by few organizations on AWS we can basically do everything on chain. However the main goal isn't too make money and create an illusion to do something innovative, primary goal was/is decentralized network that allows settlement of payments.

2.Bitcoin uses UTXO model while Ethereum uses Account model. Basic difference in transactions for two is explained in an article https://coinmetrics.io/on-data-and-certainty/. Irony is the website in the slides for screenshot is using Coinmetrics API and this misleading website is even shared by Coinmetrics team on Twitter. So in some cases you are doing more transactions, paying more fees for work which could have been done with less. Inefficiency.

3.Failed transactions paying fees on Ethereum everyday, no such transactions on Bitcoin.

4.Other improvements that affect fees: Segwit, Layer 2, Batching, UTXO consolidation, Fee estimation, Coin selection, Exchanges, Wallets etc.


-- 
Prayank

A3B1 E430 2298 178F

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

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

[Erik Aronesty]

drivechain is a cool proposal.   i don't think there's a ton of
obvious risk to the network itself (not slow, not too much work for
nodes, etc), but it seems to encourage "bad behavior", not sure the
incentives line up to prevent thefts, and not sure that won't turn
around and bite bitcoin's main chain.

of course stacks can do this even without drivechain, so not sure what
we're hiding from there

if you're talking about extensions there's lightning-compatible
mimblewimble, which is probably more important, since it gets bitcoin
to global-scale payments, while improving fungibility, and probably
can't be implemented safely via drivechain



On Thu, Sep 2, 2021 at 2:24 PM Prayank via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> printf("Hello, World!");
>
> What are your thoughts on Drivechain and associated BIPs?
>
> This article compares Liquid and Lightning: https://blog.liquid.net/six-differences-between-liquid-and-lightning/. Two things from it that I am interested in while evaluating Drivechain:
>
> 1.Trust model
> 2.On-Ramps and Off-Ramps
>
> Other things:
>
> 1.Security of Bitcoin (Layer 1)
> 2.Bitcoin transactions and fees expected on layer 1 because of Drivechain
>
> Similarities and Differences between RSK and Ethereum: https://medium.com/iovlabs-innovation-stories/similarities-and-differences-between-rsk-and-ethereum-e480655eff37
>
> Paul Sztorc had mentioned few things about fees in this video: https://youtu.be/oga8Pwbq9M0?t=481 I am interested to know same for LN, Liquid and Rootstock as well so asked a question on Bitcoin Stackexchange today: https://bitcoin.stackexchange.com/questions/109466/bitcoin-transactions-associated-with-layer-2-projects
>
> Two critiques are mentioned here: https://www.drivechain.info/peer-review/peer-review-new/ with lot of names. I don't agree with everything mentioned on project website although any comments on technical things that can help Bitcoin and Bitcoin projects will be great.
>
> Why discuss here and not on Twitter?
>
> 1.Twitter is not the best place for such discussions. There are some interesting threads but Its mostly used for followers, likes, retweets etc. and people can write anything for it.
> 2.Avoid misinformation, controversies etc.
>
> My personal opinion:
>
> We should encourage sidechain projects. I don't know much about Drivechain to form a strong opinion but concept looks good which can help in making better sidechains.
>
> ----------------------------------------------------------------------------------------------------------------------
>
>
> The website used in the slides of above YouTube video is misleading for few reasons:
>
> 1.Blocks mined everyday (in MB) for Bitcoin is ~150 MB. It is ~600 MB for Ethereum. Block limits for Bitcoin is ~4 MB per 10 minutes and ~500 MB for Ethereum. If full nodes will be run by few organizations on AWS we can basically do everything on chain. However the main goal isn't too make money and create an illusion to do something innovative, primary goal was/is decentralized network that allows settlement of payments.
>
> 2.Bitcoin uses UTXO model while Ethereum uses Account model. Basic difference in transactions for two is explained in an article https://coinmetrics.io/on-data-and-certainty/. Irony is the website in the slides for screenshot is using Coinmetrics API and this misleading website is even shared by Coinmetrics team on Twitter. So in some cases you are doing more transactions, paying more fees for work which could have been done with less. Inefficiency.
>
> 3.Failed transactions paying fees on Ethereum everyday, no such transactions on Bitcoin.
>
> 4.Other improvements that affect fees: Segwit, Layer 2, Batching, UTXO consolidation, Fee estimation, Coin selection, Exchanges, Wallets etc.
>
>
> --
> Prayank
>
> A3B1 E430 2298 178F
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[ZmnSCPxj]

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

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

[Prayank]

[-- 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 --]

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

[ZmnSCPxj]

Good morning Prayank,


> 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.

I would classify this as "prototyping new features" (i.e. it just happens to be a feature that theoretically improves blockchain scaling, with the sidechain as a demonstration and the goal eventually to get something like it into Bitcoin blockchain proper), not really scaling-by-sidechains/shards, so I think this is a fine example of "just make a federated sidechain" solution for the prototyping bit.

Do note that the above idea is a kernel for the argument that Drivechains simply allow for miner-controlled block size increases, an argument I have seen elsewhere but have no good links for, so take it is hearsay.

> 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/

LN will likely remain easy to install and maintain, especially if you use C-Lightning and CLBOSS *cough*.

> > 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.

Key being "should" --- as noted, part of the Drivechains security argument from Paul Sztorc is that a nuclear option can be deployed, which *possibly* means that issues in the sidechain may infect the mainchain.

Also see stuff like "smart contracts unchained": https://zmnscpxj.github.io/bitcoin/unchained.html
This allows creation of small federations which are *not* coordinated via inefficient blockchain structures.

So, really, my main point is: before going for the big heavy blockchain hammer, maybe other constructions are possible for any specific application?

>
> > 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.

It is precisely due to the fact that the mainchain cannot validate the sidechain rules, that side->main transfers must be bottlenecked, so that sidechain miners have an opportunity to gainsay any theft attempts that violate the sidechain rules.
Consider a similar parameter in Lightning when exiting non-cooperatively from a channel, which allows the other side to gainsay any theft attempts, a parameter which will still exist even in Decker-Russell-Osuntokun.

This parameter existed even in the old Blockstream sidechains proposal from sipa et al.
For the old Blockstream proposal the parameter is measured in sidechain blocks, and the sidechain has its own miners instead of riding off mainchain, but ultimately there exists a parameter that restricts the rate at which side->main transfers can be performed.

At least LN does not require any changes at the base layer (at least not anymore, after SegWit).

Regards,
ZmnSCPxj

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

[Prayank]

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

> of course stacks can do this even without drivechain, so not sure whatwe're hiding from there

Stacks is not a Bitcoin sidechain IMO. It has its own native token which isn't pegged to BTC. Premined.  It uses Bitcoin as a storage and broadcast medium for recording all blocks. Marketing with lot of misinformation. None of these things really help Bitcoin.

-- 
Prayank

A3B1 E430 2298 178F

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