Hi Jacob,

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.
Replies on the specifics inline.

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

> 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
hashed-template approach (CTV) if the template is the same.

> 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
to the input index without any tweak to the current APO proposal.

> 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
<tx hash> OP_CTV OP_VERIFY <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
slightly more general covenant primitives [1]. :-)

Antoine

[0] See the OP for rationale[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html

[0] Cf the OP for the rationale