Subject: Re: [bitcoin-dev] Examining ScriptPubkeys in Bitcoin Script

From: Brandon Black <[email-masked]>
Date: Fri, 20 Oct 2023 07:19:06 -0700

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