Hi darosior,
It's interesting to note that APOAS|SINGLE (with the ANYONECANPAY behaviour and without covering the spent input index) has some interesting uses for cases where the covenant only needs to restrict a single output (so useful for e.g. vaults or spacechains, but not for batch channels or congestion control).
For example in the vault use-case, it makes it possible to bump fees on the unvault tx by adding more inputs and a change output, as well as unvault multiple vaulted outputs in a single transaction.
For spacechains, it makes it possible to add the spaceblock hash OP_RETURN and pay fees directly in the tx chain, instead of having to use an additional tx to prepare an output that gets spent in the tx chain (see the diagram in [0]).
> via `sha_sequences` and maybe also `sha_amounts`
CTV does not commit to the input amounts. This has some practical implications:
1. If it is committed, sending an even slightly incorrect amount will make the covenant-encumbered spend path unusable.
With CTV, sending a slightly lower amount results in slightly lower fees, while any extra gets spent/burned on fees. The covenant spend path only becomes unusable if the amount is too low to cover for the outputs (+relay fee for it to also be standard).
2. The ability to allow for additional inputs with unknown amounts makes it possible to fee-bump the covenant spending transaction (with whole utxos and no change). You can have one tapleaf for spending the covenant output alone, and another one for attaching an extra fee input to it.
This also makes it possible to resolve the under-payment issue described in (1), by adding an input that covers the original intended amount.
So my suggestion would be to either not cover `sha_amounts` in the msg hash, or to make it optional behind a flag.
shesek