From: Rusty Russell <rusty@rustcorp•com.au>
To: Brandon Black <freedom@reardencode•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Examining ScriptPubkeys in Bitcoin Script
Date: Sun, 22 Oct 2023 14:46:33 +1030 [thread overview]
Message-ID: <87edhnwau6.fsf@rustcorp.com.au> (raw)
In-Reply-To: <ZTKMWr5x_JjaLnIG@console>
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.
next prev parent reply other threads:[~2023-10-23 2:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-20 3:40 Rusty Russell
2023-10-20 14:19 ` Brandon Black
2023-10-22 4:16 ` Rusty Russell [this message]
2023-10-27 7:00 ` Anthony Towns
2023-10-28 4:49 ` Rusty Russell
2023-10-30 16:20 ` James O'Beirne
2023-10-31 2:24 ` Rusty Russell
2023-10-31 13:05 ` Anthony Towns
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87edhnwau6.fsf@rustcorp.com.au \
--to=rusty@rustcorp$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=freedom@reardencode$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox