From: Rusty Russell <rusty@rustcorp•com.au>
To: Anthony Towns <aj@erisian•com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Examining ScriptPubkeys in Bitcoin Script
Date: Sat, 28 Oct 2023 15:19:30 +1030 [thread overview]
Message-ID: <87r0lfz6zp.fsf@rustcorp.com.au> (raw)
In-Reply-To: <ZTtgFPG4tTeZMnYn@erisian.com.au>
Anthony Towns <aj@erisian•com.au> writes:
> On Fri, Oct 20, 2023 at 02:10:37PM +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.
>>
>> https://rusty.ozlabs.org/2023/10/20/examining-scriptpubkey-in-script.html
>>
>> (If anyone wants to collaborate to produce a prototype, and debug my
>> surely-wrong script examples, please ping me!)
>>
>> 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 think there's two reasons to think about this approach:
>
> (a) we want to do vault operations specifically, and this approach is
> a good balance between being:
> - easy to specify and implement correctly, and
> - easy to use correctly.
>
> (b) we want to make bitcoin more programmable, so that we can do
> contracting experiments directly in wallet software, without needing
> to justify new soft forks for each experiment, and this approach
> provides a good balance amongst:
> - opening up a wide range of interesting experiments,
> - making it easy to understand the scope/consequences of opening up
> those experiments,
> - being easy to specify and implement correctly, and
> - being easy to use correctly.
>
> Hopefully that's a fair summary? Obviously what balance is "good"
> is always a matter of opinion -- if you consider it hard to do soft
> forks, then it's perhaps better to err heavily towards being easy to
> specify/implement, rather than easy to use, for example.
>
> For (a) I'm pretty skeptical about this approach for vault operations
> -- it's not terribly easy to specify/implement (needing 5 opcodes, one
> of which has a dozen or so flags controlling how it behaves, then also
> needs to change the way OP_SUCCESS works), and it seems super complicated
> to use.
But AFAICT there are multiple perfectly reasonable variants of vaults,
too. One would be:
1. master key can do anything
2. OR normal key can send back to vault addr without delay
3. OR normal key can do anything else after a delay.
Another would be:
1. normal key can send to P2WPKH(master)
2. OR normal key can send to P2WPKH(normal key) after a delay.
> By comparison, while the bip 345 OP_VAULT proposal also proposes 3 new
> opcodes (OP_CTV, OP_VAULT, OP_VAULT_RECOVER) [0], those opcodes can be
> implemented fairly directly (without requiring different semantics for
> OP_SUCCESS, eg) and can be used much more easily [1].
I'm interested in vaults because they're a concrete example I can get my
head around. Not because I think they'll be widely used! So I feel
that anyone who has the ability to protect two distinct keys, and make
two transactions per transfer is not a great candidate for optimization
or convenience.
> I'm not sure, but I think the "deferred check" setup might also
> provide additional functionality beyond what you get from cross-input
> introspection; that is, with it, you can allow multiple inputs to safely
> contribute funds to common outputs, without someone being able to combine
> multiple inputs into a tx where the output amount is less than the sum
> of all the contributions. Without that feature, you can mimic it, but
> only so long as all the input scripts follow known templates that you
> can exactly match.
Agreed, I don't think you would implement anything but 1:1 unvaulting in
bitcoin script, except as a party trick.
> So to me, for the vault use case, the
> TXHASH/MULTISHA256/KEYADDTWEAK/LESS/CAT/OP_SUCCESS approach just doesn't
> really seem very appealing at all in practical terms: lots of complexity,
> hard to use, and doesn't really seem like it works very well even after
> you put in tonnes of effort to get it to work at all?
Well, I found the vault BIP really hard to understand. I think it wants
to be a new address format, not script opcodes.
I don't think spelling it out in script is actually that much more
complex to use, either. "Use these templates". And modulo
consolidation, I think it works as well.
> I think in the context of (b), ie enabling experimentation more generally,
> it's much more interesting. eg, CAT alone would allow for various
> interesting constraints on signatures ("you must sign this tx with the
> given R value -- so attempting to double spend, eg via a feebump, will
> reveal the corresponding private key"), and adding CSFS would allow you
> to include authenticated data in a script, eg market data sourced from
> a trusted oracle.
Oh, oracles like this are the first CSFS use case I've heard of that
doesn't seem like abusing signatures to do hashing; nice!
(Seems like there should be a way to do this without CSFS, but I can't
see it...)
> But even then, it still seems fairly crippled -- script is a very
> limited programming language, and it just isn't really very helpful
> if you want to do things that are novel. It doesn't allow you to (eg)
> loop over the inputs and select just the ones you're interested in, you
> need the opcode to do the looping for you, and that has to be hardcoded
> as a matter of consensus (eg, Steven Roose's TXHASH [2] proposal allows
> you to select the first-n inputs/outputs, but not the last-n).
Indeed, but I still think there's much room for improvement before a
replacement. It's hard to compare the hobbled script we have today with
an alternative, since most interesting cases are impossible.
Cheers,
Rusty.
next prev parent reply other threads:[~2023-10-28 4:50 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
2023-10-27 7:00 ` Anthony Towns
2023-10-28 4:49 ` Rusty Russell [this message]
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=87r0lfz6zp.fsf@rustcorp.com.au \
--to=rusty@rustcorp$(echo .)com.au \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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