On 2023-10-20 (Fri) at 14:10:37 +1030, Rusty Russell via bitcoin-dev wrote: > I've done an exploration of what would be required (given > OP_TX/OP_TXHASH or equivalent way of pushing a scriptPubkey on the > stack) to usefully validate Taproot outputs in Bitcoin Script. Such > functionality is required for usable vaults, at least.
So you're proposing this direction as an alternative to the more constrained OP_UNVAULT that replaces a specific leaf in the taptree in a specific way? I think the benefits of OP_UNVAULT are pretty big vs. a generic construction (e.g. ability to unvault multiple inputs sharing the same scriptPubkey to the same output). > TL;DR: if we have OP_TXHASH/OP_TX, and add OP_MULTISHA256 (or OP_CAT), > OP_KEYADDTWEAK and OP_LESS (or OP_CONDSWAP), and soft-fork weaken the > OP_SUCCESSx rule (or pop-script-from-stack), we can prove a two-leaf > tapscript tree in about 110 bytes of Script. This allows useful > spending constraints based on a template approach. I agree that this is what is needed. I started pondering this in response to some discussion about the benefits of OP_CAT or OP_2SHA256 for BitVM. Personally I'd use OP_TAGGEDCATHASH that pops a tag (empty tag can be special cased to plain sha256) and a number (n) of elements to hash, then tagged-hashes the following 'n' elements from the stack. Best, --Brandon _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
