From: Rusty Russell <rusty@rustcorp.com.au>
To: Anthony Towns <aj@erisian.com.au>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <ZTtgFPG4tTeZMnYn@erisian.com.au>
References: <ZTtgFPG4tTeZMnYn@erisian.com.au>
Date: Sat, 28 Oct 2023 15:19:30 +1030
Message-ID: <87r0lfz6zp.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
Subject: Re: [bitcoin-dev] Examining ScriptPubkeys in Bitcoin Script
Precedence: list

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.