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
|
Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9A9AAB78
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 29 Nov 2018 17:00:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com
[209.85.208.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 489FC27B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 29 Nov 2018 17:00:17 +0000 (UTC)
Received: by mail-ed1-f47.google.com with SMTP id r27so2522134eda.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 29 Nov 2018 09:00:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:to:subject:in-reply-to:references:date:message-id:mime-version;
bh=BqvLiD+SnPeNXvwpHhAWOyJaL/bmNzLhIAToNwrhJLQ=;
b=a6gjDJ1dnKq7AyRQe9i3Ej9PxwxPw63psK02RCqG7dWGEgkaBppk4WtyQdRWCtGVou
ZB3mQ+/FR72huBa51vcAnXRZgrJlEhYypVQ2UDh93T5ZSYISSnJlkTRp+P3f4uFgS3HL
HQaizL8q2OSWntW4v2iYUIODA9dQnWByz2OkFPM1hZ4CHdm3Tg2Zd0d4eXh4w1sElxKc
rJs8rNvAnq57OoVVKEkI5D7a+/p14G6XccW0Hgd1c1/nfBmK+sUVrP8gLnhiRCjKmxjM
EsO0LOakR4xjucod/T1BGkeO5vu6mO7OQ4dUmNLDIaLFzSIAfgVxJQdLRH9Y/6sv5Ovp
bDdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:to:subject:in-reply-to:references:date
:message-id:mime-version;
bh=BqvLiD+SnPeNXvwpHhAWOyJaL/bmNzLhIAToNwrhJLQ=;
b=p2JJiOTdtdsoCyk9lLCDR+yXHypavD1200W6z/r2jWmYLFBs5TCJvrXpAKEEnM8w6A
4yZ4/wow1MNftZnElCcYf0Zt22rWl7CYkIVra2Tu/75zl1V55QB13SzfwKpIXHsPfvzb
NPmNR1vi85fO2JVV1EOOI3shWQFCTdLSiWH0NYbEwL8+8/LUgpVuw53aBG9zuMniuwmE
nmIJyh9hxa2JnEIGffNT7tl92kR8QPsd0do5VNMPDlJvjvdKECZmJ7uC+6Wfot1T2Uqy
qPfYlZ6ydLTfBes0e9hkG+qAN2Kw3iTnt6ZJrw+AAmtd9/BRnUO7CkO9RdGmYmB+mdbl
Utjw==
X-Gm-Message-State: AA+aEWYo84xX5aeCUYgQklupNK11Fg2xTuEgj0A8V7dkOPWsM67TBHJ6
w5fMZevsS9VP+BXCIQThXwk=
X-Google-Smtp-Source: AFSGD/WPskAd9iN+xcQnyGhzsHtCPYt5qtL10Ho9pw8HDcoJI2qrGi686+vmb6iaQe/7H+loBtEMXg==
X-Received: by 2002:a50:b667:: with SMTP id c36mr2433337ede.190.1543510815730;
Thu, 29 Nov 2018 09:00:15 -0800 (PST)
Received: from localhost ([2a02:aa16:1102:5480:b8c8:56f0:43e2:f1fe])
by smtp.gmail.com with ESMTPSA id
p21-v6sm425005ejz.45.2018.11.29.09.00.14
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Thu, 29 Nov 2018 09:00:14 -0800 (PST)
From: Christian Decker <decker.christian@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAPg+sBiu0BjZEtz-t7m3M+TnAEDG_k1GKtxwkOKh6qrSezUO7g@mail.gmail.com>
References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
<CAPg+sBiu0BjZEtz-t7m3M+TnAEDG_k1GKtxwkOKh6qrSezUO7g@mail.gmail.com>
Date: Thu, 29 Nov 2018 18:00:09 +0100
Message-ID: <87d0qnrf8m.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 30 Nov 2018 14:47:14 +0000
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Thu, 29 Nov 2018 17:00:18 -0000
Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
writes:
> On Mon, 19 Nov 2018 at 14:37, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> * It's probably better to sign the amounts of all inputs, as suggested
> by Johnson Lau. As that would cause default sighashes to sign all
> input and output amounts, is there still a need to sign the tx fee
> explicitly? Or in other words, are there situations where changing the
> set of inputs or outputs after signing is desired, but the net
> difference between them cannot change? If not, that would remove the
> need for NOFEE.
So the final proposal would be to append a new `hashValues` field to the
hashed representation, with `hashValues` just being the double SHA256 of
all values? In that case SINGLE needs to blank that hash, otherwise we'd
be committing to all inputs again.
Once we have that detail, we can start thinking about what it means to
commit to the fee vs. committing to the values. Since the fee is given
by the output values and the input values we only need to consider the
cases in which they can be modified.
- NOINPUT (as in BIP118) commits to the value (and I can't think of a
usecase where we'd want to change that), and that transparently
extends to all other inputs.
- For ANYONECANPAY can't really commit to a fee anyway so ANYONECANPAY
would likely imply NOFEE.
- With NONE all bets are off anyway, so no need to consider that :-)
- SINGLE is a bit special, and for value commitments it reduces to the
current commitment to its own value, for fee commitment it's hard to
see a use of that commitment at all afaik (I think the combination
SINGLE|NOFEE would always be used).
> * Do we need to keep the rule that sequence values of other inputs are
> only signed with default sighash? It feels cleaner to always sign the
> sequence values of all inputs that are included in the sighash anyway
> (so all of them, unless ANYONECANPAY or NOINPUT, which would make it
> sign only the current input's sequence value). If NOINPUT also blanks
> the sequence values (as currently specified by BIP118), and all input
> amounts are signed, that would make amounts/sequence values always be
> treated identically.
Single cannot commit to other the sequence of other inputs, otherwise
we're breaking SINGLE completely. As mentioned before NOINPUT doesn't
need to blank `hashSequence`, but I'm happy to make it match if that
makes implementations handle fewer cases.
> * If MASK implies NOINPUT, and NOINPUT implies ANYONECANPAY, the 3 of
> them can be encoded in just 2 bits using the
> PARTIALSCRIPT/KNOWNSCRIPT/KNOWNTX/ALL_INPUTS encoding Anthony Towns
> suggested.
So we'd end up enumerating the combinations rather than having
independent bits for each of them? This might save us storage bits, but
it'd also result in uglier code imho, not a strong feeling but might
come back to haunt us if we ever come up with something new :-)
> So a combined proposal:
> * All existing sighash flags, plus NOINPUT and MASK
> (ANYONECANPAY/NOINPUT/MASK are encoded in 2 bits).
> * A new opcode called OP_MASKEDPUSH, whose only runtime behaviour is
> failing if not immediately followed by a push, or when appearing as
> last opcode in the script.
> * Signatures are 64 plus an optional sighash byte. A missing sighash
> byte implies ALL, and ALL cannot be specified explicitly.
> * The sighash is computed from the following:
> * A 64-byte constant tag
> * Data about the spending transaction:
> * The transaction version number
> * The hash of txins' prevouts+amounts+sequences (or nothing if ANYONECANPAY)
This needs to be partially blanked for SINGLE as well, otherwise we
break SINGLE.
> * The hash of all txouts (or just the corresponding txout if
> SINGLE; nothing if NONE)
> * The transaction locktime
> * Data about the output being spent:
> * The prevout (or nothing if NOINPUT)
> * The amount
> * The sequence number
I assume the sequence number here refers to the input being signed, not
the sequence number of the transaction output being spent :-) Might be
easier if we consider 3 parts: the spending transaction, the input being
signed, and the output (or TX) being spent.
Cheers,
Christian
|
