Re: [bitcoin-dev] Drivechain: BIP 300 and 301
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/92026026-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 ___ 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
> 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 ___ 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
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/92026026-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 zmnsc...@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
Re: [bitcoin-dev] Drivechain: BIP 300 and 301
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
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
___
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
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
[bitcoin-dev] Drivechain: BIP 300 and 301
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
