public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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.


  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 [bitcoin-dev] Examining ScriptPubkeys in Bitcoin Script 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.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=freedom@reardencode.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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