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
|
Return-Path: <bob@mcelrath.org>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id D5C84C0171
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Feb 2020 20:52:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id BD87285061
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Feb 2020 20:52:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id bcgcAwdUYw8f
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Feb 2020 20:52:07 +0000 (UTC)
X-Greylist: delayed 00:12:24 by SQLgrey-1.7.6
Received: from mcelrath.org (moya.mcelrath.org [50.31.3.130])
by hemlock.osuosl.org (Postfix) with ESMTPS id 0BAEE84F53
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 1 Feb 2020 20:52:06 +0000 (UTC)
Received: from mcelrath.org (localhost [127.0.0.1])
by mcelrath.org (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 011KdgrJ032029
(version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 1 Feb 2020 20:39:42 GMT
Received: (from mcelrath@localhost)
by mcelrath.org (8.14.4/8.14.4/Submit) id 011Kdg85032028
for bitcoin-dev@lists.linuxfoundation.org; Sat, 1 Feb 2020 20:39:42 GMT
X-Authentication-Warning: mcelrath.org: mcelrath set sender to
bob@mcelrath.org using -f
Date: Sat, 1 Feb 2020 20:39:42 +0000
From: Bob McElrath <bob@mcelrath.org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200201203941.GE28549@mcelrath.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Mailman-Approved-At: Sat, 01 Feb 2020 22:12:27 +0000
Subject: [bitcoin-dev] CTV through SIGHASH flags
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, 01 Feb 2020 20:52:09 -0000
We propose that OP_CHECKTEMPLATEVERIFY should behave more like CHECKSIG,
including a flags byte that specify what is hashed. This unifies the ways a
SigHash is computed, differing only in the final checksig which is omitted in
favor of chacking the hash directly. Having two paths to create a signature hash
introduces extra complexity, especially as concerns potential future SIGHASH
flag upgrades.
CTV omits inputs as part of its semantics, so CTV-type functionality using
CHECKSIG is also achievable if some form of NOINPUT flag is also deployed. With
NOINPUT alone, a standard CHECKSIG can be used to implement a covenant -- though
it uses an unnecessarily large number of bytes just to check a 32-byte hash.
Therefore, any pitfalls CTV intends to evade can be evaded by using a CHECKSIG,
if NOINPUT is deployed in some form, adding new flexibility. Beyond what's
possible with NOINPUT/ANYPREVOUT, CTV additionally commits to:
»·······1. Number of inputs
»·······2. Number of outputs
»·······3. Index of input
The justification given for committing to the number of inputs and outputs is
that "it makes CTV hashes easier to compute with script", however doing so would
require OP_CAT. It's noted that both of these are actually redundant
commitments. Since the constexpr requirement was removed, if OP_CAT were
enabled, this commitment to the input index could be evaded by computing the CTV
hash within the script, modifying the input index using data taken from the
witness. Therefore committing to the input index is a sender-specified-policy
choice, and not an anti-footgun measure for the redeemer. As such, it's
appropriate to consider committing to the input index using a flag instead.
I believe the above may be possible *without* a new opcode and simply with a
sighash flag. That is, consider a flag SIGHASH_NOSIG which behaves as follows:
The stack is expected to contain <hash> <flags>, where the hash to be checked is
<hash> and is in the place where you'd normally put a pubkey. The byte <flags>
is the second thing on the stack. This is intended to be an empty "signature"
with the flags byte appended (which must contain SIGHASH_NOSIG to succeed).
There are probably reasons this might not work as a flag that I haven't
discovered yet. Alternatively CTV might be considered to be an alternative type
of CHECKSIG operator and might be renamed to CHECKSIGHASH, appending flag bytes
to the hash to be checked.
The flags discussed above, NOINPUT, NOSIG, INPUTINDEX are all really
sender-policy choices, while SIGHASH flags are redeemer-choice as they usually
occur in the witness. There's really no way currently for an output to specify
that the redeemer must use a particular set of flags. One way to achieve this is
to put the CHECKSIG(HASH) including its flags into the redeemScript -- which is
functionally what CTV does (or a CHECKSIG in a redeemScript using NOINPUT).
This is committed to in outputs and therefore specifies sender policies, however
the redeemScript is specified by the receiver. Perhaps an anti-footgun measure
would be to require that certain SIGHASH flags like these MUST be committed to
in the output, by the sender.
CSV (CHECKSEQUENCEVERIFY) is an example that redemption policies are committed
to in the output by the sender via the sequence_no field, and then checked with
an opcode OP_CSV to enable relative timelocks. It's probably possible to add new
flags to the sequence_no field, and check the new semantics with CSV instead of
an entiely new opcode.
As user policy choices, NOINPUT might be considered "MAY" conditions. A user MAY
use NOINPUT on an output, but let's not require it. Covenants on the other
hand, are a MUST condition. The CTV proposal imposes "MUST" conditions on the
existence of the covenant itself, as well as the number of inputs and outputs,
to prevent txid malleability so that such transactions can be used in offline
protocols. Txid non-malleability can be achieved by enforcing that the output
must be spent using SIGHASH_ALL instead of committing to the number of inputs
separately with a new opcode. The MUST condition also helps with sighash caching
for batch validation.
INPUTINDEX is required in a CTV/CHECKSIGHASH world because of the half-spend
problem. Normally outputs are spent uniquely as long as different addresses are
used on the outputs. A transaction with the same address appearing twice would
also have a half-spend problem. Anyone signing the first output and giving that
PSBT to another person can allow them to spend the second input. Therefore one
might even want INPUTINDEX for non-covenant transactions, though making a tx
with the same address twice seems like a silly idea to me.
Therefore, assuming a CSV-type mechanism can be devised using sequence_no, CTV
is equivalent to a flag in sequence_no that is logically
MUST|ALL|NOSIG|INPUTINDEX and a redeemScript of <hash> <flags>.
Lightning-like use cases might put sequence_no flags that are logically
MAY|ALL|NOINPUT.
The other mechanism for sender policy is scriptPubKey, which is heavily
restricted by isStandard, but might be another place to specify flags like the
above.
Thoughts?
Does this idea address any of the NOINPUT footguns? (which I'm not up on)
Is there a reason this cannot be done with sequence_no and OP_CSV?
Is there a reason that a separate opcode (CTV) is different/better than this
approach?
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and wrong."
-- H. L. Mencken
|
