> If Drivechains are bad for whatever reason, we should not add recursive covenants.

Bad "for who" was the crux of my question to you. Even if drivechains are always bad for their users, I don't think that's a good enough reason to block things that could allow people to build user-space drivechains, as long as it doesn't negatively affect normal Bitcoin users. 

> Drivechains are not a scaling solution

I generally agree, more of a laboratory where many things (including scaling solutions) can be tested.

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

I think the principle of least power is a good one, but it cannot be dogma. I think your point about unknown consequences is reasonable and a study on that kind of thing would be quite valuable. The community has discussed it multiple times in the past, and so at least some thought has gone into it, with nothing very strong in opposition that I know of. Has anyone made a good summary/study of the kinds of things recursive covenants allows?

On Sat, Feb 26, 2022, 02:35 Prayank via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Good morning ZmnSCPxj,

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


Agree. I would be interested to know what is NOT possible once we have recursive covenants.

> 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?)


Agree and I think everything can be done in separate soft forks.




--
Prayank

A3B1 E430 2298 178F
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev