I think you are a bit confused about how CTV and (tweaked) APO covenants compare. Both would commit to the

same template, so one isn't "safer" than the other. Just more efficient in how it commits to the template.

> While I agree with the arguments in favour of (optional ANYONECANPAY) APOAS in lieu of CTV in the short-term (given the additional benefit of enabling Eltoo), there's a point to add in favour of CTV (or similar) in the long-term beyond as an optimisation.

In the long term, we'd hopefully have more powerful covenants to enable more interesting applications. At this

point CTV would be an optimisation for these covenant constructions instead of an APO one.

My request for feedback was more about the short term, where some are requesting the activation of CTV to

start playing with covenants before we settle on the way forward to more useful covenant. Not that i'm in

favour of it, but if it gains sufficient traction then i believe there is a case for instead doing a tweaked

APO that would optionally commit to the input index, nSequences, etc..[0] I think this addresses the technical

debt concerns of CTV once we have more interesting covenants, as no covenant can entirely emulate a signature

> With APOAS-based covenants, the signature message algorithm is tied to both the covenant commitment and transaction validation. Coupling these things introduces a trade-off between safety and flexibility with covenant-based applications.

What do you mean "tied to the transaction validation"? To me "transaction validation" is what a node does to

check whether a block is valid, but you probably mean something else here.

With APOAS-based covenants, the signature message *is* the covenant commitment. I don't see how it is coupled

to anything else. I also don't see how it could ever differ in safety or flexibility with another

> E.g. the maximally safe and restricted covenant commits to all inputs and outputs of the transaction (using SIGHASH ALL). However, a less restricted covenant commits to, for example, a single input and a single output (using ANYONECANPAY|SINGLE) but opens itself up to attacks making use of transaction malleability and signature replay.

Indeed the APO approach is more flexible as sighash types may be combined. You can opt-in to more

malleability. I don't think it's a bad thing. Now, sure, the commitment may be replayed, but it's inherent to

any commitment that doesn't commit to the prevout (whether it is CTV or APO, or any other type of templated

covenant that you'd place in the ScriptPubKey) otherwise you'd have a circular hash dependency.

If you are talking about the "half spend" by which two coins with the same covenant get spent in the same

transaction, then committing to the input index fixes this. Interestingly the instance you give *does* commit

> If instead we separate the covenant commitment from the signatures to validate transactions (as with CTV and TXHASH + CHECKSIGFROMSTACK) then we by-pass this trade-off.

CTV doesn't "separate the signature and the commitment", it doesn't need a signature. Sure one can be added to

further restrict a spending path, but it isn't necessary since the transaction is pre-defined and can't be

malleated. It also sounds like you imply the APO covenant is using a "real" signature. It's not. The pubkey

may well be G. The signature is just a roundabout way to access the hash. So if you wanted to have, say, a

covenant only available to a participant you'd go the same way with either CTV or APO covenants:

<covenant sig> <0x01 G> OP_CHECKSIGVERIFY <Alice pubkey> OP_CHECKSIG

> The flexibility of additional templates with new CTV versions or with the TXHASH primitive seems to me to enable significantly more utility for covenant-based applications.

TXHASH would definitely enable more utility. Additional templates with new CTV versions would require a new

soft fork for new (hardcoded) usecases. But i'm not going to restart the conversation around the benefits of