I think the original COSHV implementation had the hash appear a push *after*
the CTV opcode.
https://github.com/JeremyRubin/bips/blob/op-checkoutputshashverify/bip-coshv.mediawiki
Yes you are of course correct. My memory failed me, should've looked up the BIP :)
With either APO or CTV alone you can do an arbitrarily long chain of commitments,
adding CSFS and discarding the CSFS private key allows
you to have a single commitment that can be reused indefinitely.
With APO alone, you can use one of two constructs:
1. Trustless, Finite - using a chain of pre-computed transactions where the signature for the next transaction is committed to in the scriptPubKey. This has similar properties to what you can get with CTV alone.
2. Trusted, Infinite - using a simple non-committed signature spending back to the
same address. This has similar properties to your CTV+CSFS construct.
Does adding CSFS enable any additional designs?
I think it's impossible to get Trustless, Infinite short of having full introspection abilities (CAT/TXHASH/Elements-like), right?
With Elements it's pretty straightforward, something like `OP_PUSHCURRENTINPUTINDEX
OP_INSPECTINPUTSCRIPTPUBKEY <0> OP_INSPECTOUTPUTSCRIPTPUBKEY
OP_ROT OP_EQUALVERIFY OP_EQUAL`
You could have CTV commit to two inputs, with the second input's entire
value being burnt to fees, but that's fairly annoying
Yes, preparing an exact-sized utxo for fees is indeed annoying. However it's not much different from CPFP - an extra tx with the same overall number of inputs/outputs, only around 46vB less efficient[0] (assuming you need change[1]). So at least for some use-cases it's not terrible either.
One important difference is that for a BMM-like bidding system, losing bids would still pay tx fees (and take up chain space) for creating the fee utxo, unlike with CPFP where only the winning bid pays fees. But for other cases, the difference would be negligible.
Of course, the most WU-optimal construct is APO|SINGLE (implying ACP) that you mentioned, where no extra transaction is needed at all.
[0] Assuming you need to use N coins for fees and that change is needed, with an exact-sized fee utxo you have a N-in, 2-out tx to prepare the fee utxo, then a 2-in, 1-out for the main tx - for a total of N+2 inputs and 3 outputs. With CPFP, its 1-in, 2-out for the main tx, then a N+1-in, 1-out tx for the CPFP fee bump - also for a total of N+2 inputs and 3 outputs. However, with CPFP you could use Pay-to-Anchor (while the fee utxo has to be key-encumbered), saving 65WU for one input plus 30vB/120WU for one output, making it more efficient by a total of 185WU/46vB (assuming the fee utxo uses key-path P2TR).
[1] If you happen to have an existing utxo to pay fees with, the 2-input CTV template would be as efficient as it gets, on par with APO|SINGLE. This can be extended to combos of multiple utxos, by adding more CTV tapleaves for different numbers of inputs (at a slight cost of larger control blocks). With large wallets it could be plausible to find such combos.
Cheers,