1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
|
Return-Path: <rusty@gandalf.ozlabs.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 43987C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Oct 2023 04:50:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 1D2A740593
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Oct 2023 04:50:55 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 1D2A740593
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=rustcorp.com.au header.i=@rustcorp.com.au
header.a=rsa-sha256 header.s=202305 header.b=iB+IED+h
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.053
X-Spam-Level:
X-Spam-Status: No, score=-4.053 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249,
RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id kDrFsl-6gj8F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Oct 2023 04:50:53 +0000 (UTC)
Received: from gandalf.ozlabs.org (mail.ozlabs.org
[IPv6:2404:9400:2221:ea00::3])
by smtp2.osuosl.org (Postfix) with ESMTPS id E88DA40592
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 28 Oct 2023 04:50:52 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org E88DA40592
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rustcorp.com.au;
s=202305; t=1698468644;
bh=Lx2h83AVWU+edbFn/fGJS0axyqhojeVPoTKTbvRIGjI=;
h=From:To:Subject:In-Reply-To:References:Date:From;
b=iB+IED+hDrAw0Owek2yn0vFhkK3tY1X9aSZFL8BkSTEShc1vVcsEd/jIlT9hy0mZ6
57zTA4RdgVZH29DknGMlyayWG3TnqPz51CghewqMJ0E1jQgsrU6Y2jz+ul1i57sT6J
KjG4CJe02b+zMWK75NQbLRlt2/SvKLr//PcnJNhzt9HNxsilJVwFShSQtXwvRQTgIR
9HtFvXkhiJBadhtnl6Q0Vp9KnOk7kTaXHzpx/5yl/8sANZT2Lt2BxPcID8YZXqT9Vn
Bqhlqb0VITIkgIc/iWy7+9xQaLk6FOxW7XtCw6/GQBA3kbU0hJfVC8Q5WdqX+dhJ5F
1/3TK2GfFxihA==
Received: by gandalf.ozlabs.org (Postfix, from userid 1011)
id 4SHRtX33J3z4wcj; Sat, 28 Oct 2023 15:50:44 +1100 (AEDT)
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 28 Oct 2023 04:50:55 -0000
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.
|
