Summarizing some discussions I’ve had on X and elsewhere about this:
Recursion, counters, Spookchains
Any covenant-capable hash/template proposal that lets the hash (or the signature on a hash) only appear in the unlock script enables some form of deleted key recursion. Deleted key constructions are obviously limited by how well the covenant creator can convince folks that they have actually deleted the key, but let’s accept that if they are enabled they will likely be used.
Comparing the deleted key recursion enabled by the various possible hashes, it appears that SIGHASH_SINGLE type hashes enable potentially useful (or scary, depending on perspective) constructions (a la Spookchains / hashrate escrow). With SIGHASH_ALL type hashes, a new deleted key counter covenant would need to be created and trusted for each possible withdrawal, removing the TOFU security. In that case users would simply use federated withdrawals, skipping the whole countdown process.
I’m not sure if dropping the SIGHASH_SINGLE modes from this proposal (or APO by extension) would satisfy most or all of those concerned about spooky deleted key recursion.
Helping Ark (or similar protocols)
There are clear use cases for a CTV/APO-like hash that hashes either all scripts other than the input being verified, all outpoints other than the input being verified, or both. This kind of “every other input” hashing creates quadratic hashing, so I’ve been hesitant to include it. @4moonsettler pointed out that for CTV-style execution this isn’t a problem because there would be a hash loop making it impossible to include more than 1 such hash in a transaction. For OP_TEMPLATEHASH/OP_TXHASH-style execution, it becomes possible to create many megabytes of hashing in a consensus-valid transaction.
One possible solution here would be to allow at most one hash-every-other mode hash in any given transaction. This of course would make reasoning about scripts more difficult - OP_TEMPLATEHASH might fail validation due to how it is combined with other inputs.
Another solution would be to instead include hash-the-next modes - where the template hash commits to the next input’s script/outpoint only. These would work fine for Ark, I think, but are a bit odd. https://twitter.com/brqgoo/status/1694090272009797687
Responses have been quite interesting. I’m going to write down a version of OP_TEMPLATEHASH which does not include SIGHASH_SINGLE-like modes, and tries to cover as many variations on what input-related data is hashed as I can think of without introducing quadratic hashing.