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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
