From: Brandon Black <freedom@reardencode•com>
To: Rusty Russell <rusty@rustcorp•com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Examining ScriptPubkeys in Bitcoin Script
Date: Fri, 20 Oct 2023 07:19:06 -0700 [thread overview]
Message-ID: <ZTKMWr5x_JjaLnIG@console> (raw)
In-Reply-To: <87v8b2vu4q.fsf@rustcorp.com.au>
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
next prev parent reply other threads:[~2023-10-20 14:26 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 [this message]
2023-10-22 4:16 ` Rusty Russell
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=ZTKMWr5x_JjaLnIG@console \
--to=freedom@reardencode$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=rusty@rustcorp$(echo .)com.au \
/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