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
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
|
Return-Path: <freedom@reardencode.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 037C2C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2022 15:25:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id D833461002
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2022 15:25:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=reardencode.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id pmgJ89j0y-WQ
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2022 15:25:11 +0000 (UTC)
X-Greylist: delayed 00:08:53 by SQLgrey-1.8.0
Received: from mail.reardencode.com (mail.reardencode.com [206.125.169.165])
by smtp3.osuosl.org (Postfix) with ESMTPS id 1B45E60FED
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2022 15:25:11 +0000 (UTC)
Date: Tue, 10 May 2022 08:16:10 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=reardencode.com;
s=mail; t=1652195775;
bh=p5eNLSX/v7bT2Gxi8yab4JtOlTReaKEaLwAwjhZIR+Y=;
h=Date:From:To:Subject:References:In-Reply-To;
b=b285jzSjjzjTzv66cRPNMJ/P1y8VQdvzYRG5FSXOiRjqpHHzaxpRcFAvIhATNGOvg
nqQG9Qov9Xk5Kj3qthyf27QSeVJ4qvXFuoWA45XUa+l+51itYmJHDlKLXe6sLP8qI6
3pTWdj53dEcTdgVucFOE1v0hmiYEH+tVOLd0lUyI=
From: Brandon Black <freedom@reardencode.com>
To: Rusty Russell <rusty@rustcorp.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <YnqBuhbUGKmT+NW8@console>
Mail-Followup-To: Rusty Russell <rusty@rustcorp.com.au>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <87h75xoet1.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87h75xoet1.fsf@rustcorp.com.au>
X-Operating-System: Linux 5.10.93 x86_64
X-Mailman-Approved-At: Tue, 10 May 2022 15:35:06 +0000
Subject: Re: [bitcoin-dev] [PROPOSAL] OP_TX: generalized covenants reduced
to OP_CHECKTEMPLATEVERIFY
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: Tue, 10 May 2022 15:25:13 -0000
Hi Rusty,
Thanks for this. Seems like a productive direction to explore.
To me, one of the biggest limitations of CTV is that the script is
specific to the amount of the input being spent. OP_TX makes it
possible, although clumsy, to emulate OP_IN_OUT_AMOUNT, which could be
combined with CTV emulation less OPTX_SELECT_OUTPUT_AMOUNT32x2 to allow
a single script to be reused. Given that potential, I wonder if
OPTX_SELECT_IN_OUT_AMOUNT32x2 would be worth adding to the initial set
of flags.
With that addition, a small script can be constructed for a relocatable,
batchable construction (eg. as a building block for vaults):
OPTX_SEPARATELY|OPTX_UNHASHED|OPTX_INPUTNUM OP_TX OP_DUP
OPTX_SELECT_VERSION|
OPTX_SELECT_LOCKTIME|
OPTX_SELECT_INPUT_SINGLE|
OPTX_SELECT_INPUT_SCRIPT|
OPTX_SELECT_INPUT_NSEQUENCE|
OPTX_SELECT_OUTPUT_SINGLE|
OPTX_SELECT_OUTPUT_SCRIPTPUBKEY|
OPTX_SELECT_IN_OUT_AMOUNT32x2 OP_TX <expectedhash> OP_EQUAL
* Additional inputs and change outputs can be added
* Could commit to 0 fee and still be useful
* Arbitrary amounts can be sent to the same script
* There is no txid predictability (unlike CTV)
* Anyone could rearrange such input/output pairs after broadcast
* Not suitable for some uses
* Potentially helpful for others
Best,
--Brandon
On 2022-05-10 (Tue) at 20:05:54 +0930, Rusty Russell via bitcoin-dev wrote:
> Hi all,
>
> TL;DR: a v1 tapscript opcode for generic covenants, but
> OP_SUCCESS unless it's used a-la OP_CHECKTEMPLATEVERIFY. This gives an
> obvious use case, with clean future expansion. OP_NOP4 can be
> repurposed in future as a shortcut, if experience shows that to be a
> useful optimization.
>
> (This proposal builds on Russell O'Connor's TXHASH[1], with Anthony
> Towns' modification via extending the opcode[2]; I also notice on
> re-reading that James Lu had a similar restriction idea[3]).
>
> Details
> -------
>
> OP_TX, when inside v1 tapscript, is followed by 4 bytes of flags.
> Unknown flag patterns are OP_SUCCESS, though for thoroughness some future
> potential uses are documented here. Note that pushing more than 1000
> elements on the stack or an element more than 512 bytes will hit the
> BIP-342 resource limits and fail.
>
> Defined bits
> ------------
>
> (Only those marked with * have to be defined for this soft fork; the
> others can have semantics later).
>
> OPTX_SEPARATELY: treat fields separately (vs concatenating)
> OPTX_UNHASHED: push on the stack without hashing (vs SHA256 before push)
>
> - The first nicely sidesteps the lack of OP_CAT, and the latter allows
> OP_TXHASH semantics (and avoid stack element limits).
>
> OPTX_SELECT_VERSION*: version
> OPTX_SELECT_LOCKTIME*: nLocktime
> OPTX_SELECT_INPUTNUM*: current input number
> OPTX_SELECT_INPUTCOUNT*: number of inputs
> OPTX_SELECT_OUTPUTCOUNT*: number of outputs
>
> OPTX_INPUT_SINGLE: if set, pop input number off stack to apply to
> OPTX_SELECT_INPUT_*, otherwise iterate through all.
> OPTX_SELECT_INPUT_TXID: txid
> OPTX_SELECT_INPUT_OUTNUM: txout index
> OPTX_SELECT_INPUT_NSEQUENCE*: sequence number
> OPTX_SELECT_INPUT_AMOUNT32x2: sats in, as a high-low u31 pair
> OPTX_SELECT_INPUT_SCRIPT*: input scriptsig
> OPTX_SELECT_INPUT_TAPBRANCH: ?
> OPTX_SELECT_INPUT_TAPLEAF: ?
>
> OPTX_OUTPUT_SINGLE: if set, pop input number off stack to apply to
> OPTX_SELECT_OUTPUT_*, otherwise iterate through all.
> OPTX_SELECT_OUTPUT_AMOUNT32x2*: sats out, as a high-low u31 pair
> OPTX_SELECT_OUTPUT_SCRIPTPUBKEY*: output scriptpubkey
>
> OPTX_SELECT_19...OPTX_SELECT_31: future expansion.
>
> OP_CHECKTEMPLATEVERIFY is approximated by the following flags:
> OPTX_SELECT_VERSION
> OPTX_SELECT_LOCKTIME
> OPTX_SELECT_INPUTCOUNT
> OPTX_SELECT_INPUT_SCRIPT
> OPTX_SELECT_INPUT_NSEQUENCE
> OPTX_SELECT_OUTPUTCOUNT
> OPTX_SELECT_OUTPUT_AMOUNT32x2
> OPTX_SELECT_OUTPUT_SCRIPTPUBKEY
> OPTX_SELECT_INPUTNUM
>
> All other flag combinations result in OP_SUCCESS.
>
> Discussion
> ----------
>
> By enumerating exactly what can be committed to, it's absolutely clear
> what is and isn't committed (and what you need to think about!).
>
> The bits which separate concatenation and hashing provide a simple
> mechanism for template-style (i.e. CTV-style) commitments, or for
> programatic treatment of individual elements (e.g. amounts, though the
> two s31 style is awkward: a 64-bit push flag could be added in future).
>
> The lack of double-hashing of scriptsigs and other fields means we
> cannot simply re-use hashing done for SIGHASH_ALL.
>
> The OP_SUCCESS semantic is only valid in tapscript v1, so this does not
> allow covenants for v0 segwit or pre-segwit inputs. If covenants prove
> useful, dedicated opcodes can be provided for those cases (a-la
> OP_CHECKTEMPLATEVERIFY).
>
> Cheers,
> Rusty.
>
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019813.html
> [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019819.html
> [3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019816.html
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
--Brandon
|
