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
207
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 45E0688A
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Nov 2018 17:55:37 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o53.zoho.com (sender-of-o53.zoho.com [135.84.80.218])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7C52C2D4
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 21 Nov 2018 17:55:35 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1542822928; cv=none; d=zoho.com; s=zohoarc;
b=nlBq9gfQQvAF5p+2lO7knMEz4yidxdbE/tzpSbUThrbpAtTayA91CzCqArxz02c518iN68RDolrO0cyprOwxOYgXRjSYooFBPnpW9LCXK3upd/6JI9P1LiO83RRKSPYo9fyoxWzIkTuA91EVLMSFiDhHh7l3QGkVdjLympR+p+4=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc; t=1542822928;
h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
bh=XySCUQLTjkJn1NrSqATnmCSwcvwDfvp2f8laC7NdTH4=;
b=aXvgveQri7lMgmjQdjv0kofV5mNDDk0ieo9OMnnyAFlAa2zU/w7ddnY+mHzTlYfbgUCKlpqQ84Iw1JoaDwLwnkqmnBOVqYy3slRtT2hxAVDslupInp531GfpPrzqQXEtBReZ+ddwszjrLZ/2v+zjOdIZrrBnztjsh1d1SltmcMs=
ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass header.i=xbt.hk;
spf=pass smtp.mailfrom=jl2012@xbt.hk;
dmarc=pass header.from=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk>
Received: from [10.8.0.105] (n218103234118.netvigator.com [218.103.234.118])
by mx.zohomail.com with SMTPS id 1542822927669137.6294812894621;
Wed, 21 Nov 2018 09:55:27 -0800 (PST)
Content-Type: text/plain;
charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <20181120202904.gmbg5ebegvsgqfys@erisian.com.au>
Date: Thu, 22 Nov 2018 01:55:22 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <2FCAFF04-2449-42C9-9613-EF0F8272259D@xbt.hk>
References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
<20181120202904.gmbg5ebegvsgqfys@erisian.com.au>
To: Anthony Towns <aj@erisian.com.au>,
bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.3445.100.39)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: Thu, 22 Nov 2018 14:08:02 +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: Wed, 21 Nov 2018 17:55:37 -0000
If we sign the txids of all inputs, we should also explicitly commit to =
their values. Only this could fully eliminate any possible way to lie =
about input value to hardware wallets
> Does it make sense to keep SIGHASH_NONE?
SIGHASH_NONE should be kept. ANYONECANPAY|NONE allows donation of dust =
UTXOs to miners
> I think NONE without NOFEE doesn't make much sense=E2=80=A6=E2=80=A6.
We might refuse to sign weird combinations like =
NOFEE|ALLINPUT|ALLOUTPUT. But to keep the consensus logic simple, we =
should just validate it as usual.
> OP_MASK seems a bit complicated to me. =E2=80=A6...
Yes, it looks complicated to me, and it improves security only in some =
avoidable edge cases in SIGHASH_NOINPUT:
The common case: the exact masked script or address is reused. OP_MASK =
can=E2=80=99t prevent signature replay since the masked script is the =
same.
The avoidable case: the same public key is reused in different script =
templates. OP_MASK may prevent signature replay is the masked script is =
not the same.
The latter case is totally avoidable since one could and should use a =
different public key for different script.
It could be made much simpler as NOINPUT with/without SCRIPT. This again =
is only helpful in the avoidable case above, but it doesn=E2=80=99t =
bring too much complexity.
> I don't have a reason why, but committing to the scriptCode feels to =
me like it reduces the "hackiness" of NOINPUT a lot.
OP_MASK is designed to preserve the hackiness, while provide some sort =
of replay protection (only in avoidable cases). However, I=E2=80=99m not =
sure who would actually need NOINPUT with KNOWNSCRIPT
> On 21 Nov 2018, at 4:29 AM, Anthony Towns via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> On Mon, Nov 19, 2018 at 02:37:57PM -0800, Pieter Wuille via =
bitcoin-dev wrote:
>> Here is a combined proposal:
>> * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE,
>> and SIGHASH_SCRIPTMASK.
>> * A new opcode OP_MASK is added, which acts as a NOP during =
execution.
>> * The sighash is computed like in BIP143, but:
>> * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode
>> the subsequent opcode/push is removed.
>> * The scriptPubKey being spent is added to the sighash, unless
>> SIGHASH_SCRIPTMASK is set.
>> * The transaction fee is added to the sighash, unless SIGHASH_NOFEE =
is set.
>> * hashPrevouts, hashSequence, and outpoint are set to null when
>> SIGHASH_NOINPUT is set (like BIP118, but not for scriptCode).
>=20
> Current flags are {ALL, NONE, SINGLE} and ANYONECANPAY, and the BIP143
> tx digest consists of the hash of:
>=20
> 1 nVersion
> 4 outpoint
> 5 input scriptCode
> 6 input's outpoint value
> 7 input's nSeq
> 9 nLocktime
> 10 sighash
>=20
> 2 hashPrevOuts (commits to 4,5,6; unless ANYONECANPAY)
> 3 hashSequence (commits to 7; only if ALL and not ANYONECANPAY)
> 8 hashOutputs
> - NONE: 0
> - SINGLE: {value,scriptPubKey} for corresponding output
> - otherwise: {value,scriptPubKey} for all outputs
>=20
> The fee is committed to by hashPrevOuts and hashOutputs, which means
> NOFEE is only potentially useful if ANYONECANPAY or NONE or SINGLE is =
set.
>=20
> For NOINPUT, (2),(3),(4) are cleared, and SCRIPTMASK (which munges =
(5))
> is only useful given NOINPUT, since (4) indirectly commits to (5).=20
>=20
> Given this implementation, NOINPUT effectively implies ANYONECANPAY,
> I think. (I think that is also true of BIP 118's NOINPUT spec)
>=20
> Does it make sense to treat this as two classes of options, affecting
> the input and output side:
>=20
> output: (pick one, using bits 0,1)
> * NONE -- don't care where the money goes
> * SINGLE -- want this output
> * ALL -- want exactly this set of outputs
>=20
> input: (pick one, using bits 4,5)
> * PARTIALSCRIPT -- spending from some tx with roughly this script =
(and
> maybe others; SCRIPTMASK|NOINPUT|ANYONECANPAY)
> * KNOWNSCRIPT -- spending from some tx with exactly this script =
(and
> maybe others; NOINPUT|ANYONECANPAY)
> * KNOWNTX -- spending from this tx (and maybe others; ANYONECANPAY)
> * ALL_INPUTS -- spending from exactly these txes
>=20
> combo: (flag, bit 6)
> * NOFEE -- don't commit to the fee
>=20
> I think NONE without NOFEE doesn't make much sense, and
> NOFEE|ALL|ALL_INPUTS would also be pretty weird. Might make sense to
> warn/error on signing when asking for those combinations, and maybe =
even
> to fail on validating them.
>=20
> (Does it make sense to keep SIGHASH_NONE? I guess =
SIGHASH_NONE|ALL_INPUTS
> could be useful if you just use sigs on one of the other inputs to =
commit
> to a useful output)
>=20
> FWIW, OP_MASK seems a bit complicated to me. How would you mask a =
script
> that looks like:
>=20
> OP_MASK IF <p> ENDIF <q> ...
>=20
> or:
>=20
> IF OP_MASK ENDIF <p> ...
>=20
> I guess if you make the rule be "for every OP_MASK in scriptCode the
> *immediately* subsequent opcode/push is removed (if present)" it would
> be fine though -- that would make OP_MASK in both the above not have
> any effect. (Maybe a more explicit name like "MASK_PUSH_FOR_SIGHASH"
> or something might be good?)
>=20
> I don't have a reason why, but committing to the scriptCode feels to =
me
> like it reduces the "hackiness" of NOINPUT a lot.
>=20
> Cheers,
> aj
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
