Good morning AJ, > ZmnSCPaj, are you arguing that drivechains are bad for bitcoin or are you > arguing that it would be unwise to opt into a drivechain? Those are very > different arguments. If drivechains compromised things for normal bitcoin > nodes that ignore drivechains, then I agree that would be serious reason to > reject drivechains outright and reject things that allow it to happen. > However, if all you're saying is that people can shoot themselves in the foot > with drivechains, then avoiding drivechains should not be a significant > design consideration for bitcoin but rather for those who might consider > spending their time working on drivechains.
Neither. My argument is simply: * If Drivechains are bad for whatever reason, we should not add recursive covenants. * Otherwise, go ahead and add recursive covenants. Drivechains are not a scaling solution [FOOTNOTE 1] and I personally am interested only in scaling solutions, adding more non-scaling-useable functionality is not of interest to me and I do not really care (but I would *prefer* if people focus on scaling-useable functionality, like `SIGHASH_NOINPUT`, `OP_EVICT`, `OP_CTV`, `OP_TLUV` probably without the self-replace capability). I bring this up simply because I remembered those arguments against Drivechains, and as far as I could remember, those were the reasons for not adding Drivechains. But if there is consensus that those arguments are bogus, then go ahead --- add Drivechains and/or recursive covenants. I do not intend to utilize them any time soon anyway. My second position is that in general I am wary of adding Turing-completeness, due precisely to Principle of Least Power. A concern is that, since it turns out recursive covenants are sufficient to implement Drivechains, recursive covenants may also enable *other* techniques, currently unknown, which may have negative effects on Bitcoin, or which would be considered undesirable by a significant section of the userbase. Of course, I know of no such technique, but given that a technique (Drivechains) which before would have required its own consensus change, turns out to be implementable inside recursive covenants, then I wonder if there are other things that would have required their own consensus change that are now *also* implementable purely in recursive covenants. Of course, that is largely just stop energy, so if there is *now* consensus that Drivechains are not bad, go ahead, add recursive covenants (but please can we add `SIGHASH_NOINPUT` and `OP_CTV` first?). Regards, ZmnSCPxj [FOOTNOTE 1] Sidechains are not a scaling solution, or at least, are beaten in raw scaling by Lightning. Blockchains are inefficient (THAT IS PRECISELY THE PROBLEM WHY YOU NEED A SCALING SOLUTION FOR BITCOIN THAT WAS LIKE THE FIRST RESPONSE TO SATOSHI ON THE CYPHERPUNK MAILING LIST) and you have to show your transaction to everyone. While sidechains imply that particular subsets are the only ones interested in particular transactions, compare how large a sidechain-participant-set would be expected to be, to how many people learn of a payment over the Lightning Network. If you want a sidechain to be as popular as LN, then you expect its participant set to be about as large as LN as well, and on a sidechain, a transaction is published to all sidechain participants, but on the LN, only a tiny tiny tiny fraction of the network is involved in any payment. Thus LN is a superior scaling solution. Now you might conter-argue that you can have multiple smaller sidechains and just use HTLCs to trade across them (i.e. microchains). I would then counter-counter-argue that bringing this to the most extreme conclusion, you would have tons of sidechains with only 2 participants each, and then you would pay by transferring across multiple participants in a chain of HTLCs and look, oh wow, surprise surprise, you just got the Lightning Network. LN wins. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
