From: Rusty Russell <rusty@rustcorp.com.au>
To: Brandon Black <freedom@reardencode.com>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <ZTKMWr5x_JjaLnIG@console>
References: <87v8b2vu4q.fsf@rustcorp.com.au> <ZTKMWr5x_JjaLnIG@console>
Date: Sun, 22 Oct 2023 14:46:33 +1030
Message-ID: <87edhnwau6.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [bitcoin-dev] Examining ScriptPubkeys in Bitcoin Script
Precedence: list

Brandon Black <freedom@reardencode.com> writes:
> 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).

I would have to write the scripts exactly (and I'm already uncomfortable
that I haven't actually tested the ones I wrote so far!) to properly
evaluate.

In general, script makes it hard to do N-input evaluation (having no
iteration).  It would be useful to attempt this though, as it might
enlighted us as to OP_TXHASH input selection: for example, we might want
to have an "all *but* one input" mode for this kind of usage.

Dealing with satsoshi amounts is possible, but really messy (that's my next
post).

>> 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.

Given these examples, I think it's clear that OP_MULTISHA256 is almost
as powerful as OP_CAT, without the stack limit problems.  And OP_2SHA256
is not sufficient in general for CScriptNum generation, for example.

> 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.

That's definitely a premature optimization to save two opcodes.

Cheers,
Rusty.