Hi Rusty, Please see my post in the other email thread https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019886.html The differences in this regard are several, and worth understanding beyond "you can iterate CTV". I'd note a few clear examples for showing that "CTV is just as powerful" is not a valid claim: 1) CTV requires the contract to be fully enumerated and is non-recursive. For example, a simple contract that allows n participants to take an action in any order requires factorially many pre-computations, not just linear or constant. For reference, 24! is about 2**80. Whereas for a more interpretive covenant -- which is often introduced with the features for recursion -- you can compute the programs for these addresses in constant time. 2) CTV requires the contract to be fully enumerated: For example, a simple contract one could write is "Output 0 script matches Output 1", and the set of outcomes is again unbounded a-priori. With CTV you need to know the set of pairs you'd like to be able to expand to a-priori 3) Combining 1 and 2, you could imagine recursing on an open-ended thing like creating many identical outputs over time but not constraining what those outputs are. E.g., Output 0 matches Input 0, Output 1 matches Output 2. I think for your point the inverse seems to hold: for the limited situations we might want to set up, CTV often ends up being sufficient because usually we can enumerate all the possible outcomes we'd like (or at least find a mapping onto such a construction). CTV is indeed very powerful, but as I demonstrated above, not powerful in the same way ("Complexity Class") that OP_TX or TXHASH might be. At the very least we should clearly understand *what* and *why* we are advocating for more sophisticated designs and have a thorough understanding of the protocol complexity we are motivated to introduce the expanded functionality. Further, if one advocates for TX/TXHASH on a featureful basis, it's at least a technical ACK on the functionality CTV is introducing (as it is a subset) and perhaps a disagreement on project management, which I think is worth noting. There is a very wide gap between "X is unsafe" and "I prefer Y which X is a subset of ''. I'll close by repeating : Whether that [the recursive/open ended properties] is an issue or not precluding this sort of design or not, I defer to others. Best, Jeremy Best, Jeremy -- @JeremyRubin On Tue, Feb 15, 2022 at 12:46 AM Rusty Russell wrote: > Jeremy Rubin writes: > > Rusty, > > > > Note that this sort of design introduces recursive covenants similarly to > > how I described above. > > > > Whether that is an issue or not precluding this sort of design or not, I > > defer to others. > > Good point! > > But I think it's a distinction without meaning: AFAICT iterative > covenants are possible with OP_CTV and just as powerful, though > technically finite. I can constrain the next 100M spends, for > example: if I insist on those each having incrementing nLocktime, > that's effectively forever. > > Thanks! > Rusty. >