Non-exhaustive thoughts but better to have something written than nothing at all:
WANTING: There's no developer or larger community consensus on anything, so I marked anything I'm happy with as "Wanting" instead.
MEVil: The below discussion is predicated on the fact we as a community are no longer overly concerned with script enhancements creating mining centralization risk via MEVil.
SIGHASH_ALL emulation. Pretty understandable how to use, also not very exciting on its own unless you believe it's the step function in usability for Arg, Timeout Trees, and also believe those are game changers. It does show up in a lot of places are cleanups removing interactivity in protocols, especially when combined with OP_CSFS.
Straight forward, small design space, big payoffs when combined with interesting hashes on the stack.
No. The stated motivation is usage and app-specific vs f.e. OP_CAT https://delvingbitcoin.org/t/op-paircommit-as-a-candidate-for-addition-to-lnhance/1216/13#p-3575-op_cat-4 and also does not compose with anything that involves transaction introspection due to its specified tagged hash. It would likely become nearly completely redundant with OP_CAT and other existing opcodes, with very little vbyte savings. I know that's the point, but also, I don't like what's on the tin.
Not a game changer, but probably useful in conjunction with CSFS + interesting hashes on stack. Saves 8 vbytes? zzz?
Pushed the hardest by some awful people, but it's a common sense primitive if you're not worried about transaction introspection side-effect. Helps make merkle trees, mostly? Used stupidly, can becomes general introspection tool.
Not specified very well, but seems like OP_VAULT but instead of forwarding a script fragment, you replace the merkle root of the taptree. With OP_CAT + SHA2 this means you can arbitrarily build alternative taptrees. Optionally uses the "deferred checks" framework from OP_VAULT to forward value. I am still evaluating but currently a "?" outside of the possibility of it doing vaults and "value forwarding" delegation like schemes. It needs a BIP.
I'm really not that interested in the stated use-case of fraud proofs for verification of computation and I'm not sure it helps understand the proposal.
Co-uthor here. I think the proposal is too specific to be adopted even if I think it's technically ok. Maybe CCV instead? It has a BIP at least!
Builds interesting transaction introspection hashes for the stack, while not requiring bignum support. Would allow precommitted arbitrary transaction structures with single-transaction exogenous fees, provided you don't need txid stability. A superset of CTV. Could optionally replace fee bumping CPFPs for many proposed cases such as all ln-penalty/ln-symmetry transactions, including settlement and presigned HTLC transactions. Downside is many flag configurations; how to test these properly?
Enables cleaner payment channels and similar, but still too app-specific.
My "medium term" (I'm in no rush) aim would be a MVP package like:
- TXHASH, to push tx introspection hashes
- OP_CAT, assist computing other interesting hashes
- CSFS, to sign hashes on stack
Longer-term I'd rather look at Great Script Renaissance, BTC Lisp, or Simplicity. Bitcoin Script leaves a lot to be desired, and doing stuff right will likely cost.