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
|
Return-Path: <rusty@gandalf.ozlabs.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 54832C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2022 10:37:12 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 34BF64060B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2022 10:37:12 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.652
X-Spam-Level:
X-Spam-Status: No, score=-1.652 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 GSU2RZGQVhpk
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2022 10:37:11 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from gandalf.ozlabs.org (mail.ozlabs.org
[IPv6:2404:9400:2221:ea00::3])
by smtp2.osuosl.org (Postfix) with ESMTPS id EAEF9400FB
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 10 May 2022 10:37:10 +0000 (UTC)
Received: by gandalf.ozlabs.org (Postfix, from userid 1011)
id 4KyDxW5TXSz4ySZ; Tue, 10 May 2022 20:37:03 +1000 (AEST)
From: Rusty Russell <rusty@rustcorp.com.au>
To: "Bitcoin Protocol Discussion" <bitcoin-dev@lists.linuxfoundation.org>
Date: Tue, 10 May 2022 20:05:54 +0930
Message-ID: <87h75xoet1.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain
Subject: [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 10:37:12 -0000
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
|
