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
|
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 C17851072
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 20:54:09 +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 0CB4F6C5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 20:54:08 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1558644846; cv=none; d=zoho.com; s=zohoarc;
b=Mc/qV5BQsV9M3SkN0jUgZqmwPmWZ+xq10+UuHr3beXzDR/K48uxmY1PdXJJCrMpEwWkmyRsgwDH5JV2fq/GitXXDpGLa5gPdKFBsAXfrUQNpk6RJVD1mLMUQCn8ddZGT+5y6KvOKSRLdXvpdgncuhUneLbZ2rMW25AYjZc3Y8Bg=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
s=zohoarc; t=1558644846;
h=Content-Type:Date:From:MIME-Version:Message-ID:Subject:To:ARC-Authentication-Results;
bh=XC+N5EEtRccW/Dm6nxaZ5Gv4vc2iGCTYJd3QnUb9F8k=;
b=G4kpUx2h68QFb9tjCsuLDslFykqJ+gLpiZYGve6pAFotHx8rqkRf1NcIk/m4NErYwm7BEGuSGVqY5CZrLimwV25ZK6wavFRx/R6eYHJBFad0GHUw9t4S2qPtgGyjrkQnAxkS1z2fNPZdgjGisEw06NmaPViWcDIn3Q+Dklo7NK8=
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 [192.168.1.2] (1-64-133-115.static.netvigator.com
[1.64.133.115]) by mx.zohomail.com
with SMTPS id 1558644844866730.8742251385539;
Thu, 23 May 2019 13:54:04 -0700 (PDT)
From: Johnson Lau <jl2012@xbt.hk>
Content-Type: multipart/alternative;
boundary="Apple-Mail=_10F3B835-1991-4F95-9DF9-1926AF7D6330"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <77218514-9118-4FE2-8F7F-7BB215CF2BB6@xbt.hk>
Date: Fri, 24 May 2019 04:54:01 +0800
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,
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, 24 May 2019 14:39:19 +0000
Subject: [bitcoin-dev] Safety of committing only to transaction outputs
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, 23 May 2019 20:54:09 -0000
--Apple-Mail=_10F3B835-1991-4F95-9DF9-1926AF7D6330
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
This is a meta-discussion for any approach that allows the witness =
committing to only transaction outputs, but not inputs.
We can already do the following things with the existing bitcoin script =
system:
* commit to both inputs and outputs: SIGHASH_ALL or SIGHASH_SINGLE, with =
optional SIGHASH_ANYONECANPAY
* commit to only inputs but not outputs: SIGHASH_NONE with optional =
SIGHASH_ANYONECANPAY
* not commit to any input nor output: not using any sigop; using a =
trivial private key; using the SIGHASH_SINGLE bug in legacy script
The last one is clearly unsafe as any relay/mining node may redirect the =
payment to any output it chooses. The witness/scriptSig is also =
replayable, so any future payment to this script will likely be swept =
immediately
SIGHASH_NONE with ANYONECANPAY also allows redirection of payment, but =
the signature is not replayable
But it=E2=80=99s quite obvious that not committing to outputs are =
inherently insecure
The existing system doesn=E2=80=99t allow committing only to outputs, =
and we now have 3 active proposals for this function:
1. CAT and CHECKSIGFROMSTACK (CSFS): =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016946.ht=
ml =
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016946.h=
tml>
2. ANYPREVOUT (aka NOINPUT): =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016929.ht=
ml =
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016929.h=
tml>
3. CHECKOUTPUTSHASHVERIFY (COHV): =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.ht=
ml =
<https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.h=
tml>
With outputs committed, redirecting payment is not possible. On the =
other hand, not committing to any input means the witness is replayable =
without the consent of address owner. Whether replayability is =
acceptable is subject to controversy, but the ANYPREVOUT proposal fixes =
this by requiring a chaperone signature that commits to input. However, =
if the rationale for chaperone signature stands, it should be applicable =
to all proposals listed above.
A more generic approach is to always require a =E2=80=9Csafe" signature =
that commits to at least one input. However, this interacts poorly with =
the "unknown public key type=E2=80=9D upgrade path described in =
bip-tapscript =
(https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki =
<https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediawiki>), =
since it=E2=80=99d be a hardfork to turn an =E2=80=9Cunknown type sig=E2=80=
=9D into a =E2=80=9Csafe sig=E2=80=9D. But we could still use a new =
=E2=80=9Cleaf version=E2=80=9D every time we introduce new sighash =
types, so we could have a new definition for =E2=80=9Csafe sig=E2=80=9D. =
I expect this would be a rare event and it won=E2=80=99t consume more =
than a couple leaf versions. By the way, customised sighash policies =
could be done with CAT/CSFS.=
--Apple-Mail=_10F3B835-1991-4F95-9DF9-1926AF7D6330
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">This =
is a meta-discussion for any approach that allows the witness committing =
to only transaction outputs, but not inputs.<div class=3D""><br =
class=3D""></div><div class=3D"">We can already do the following things =
with the existing bitcoin script system:</div><div class=3D"">* commit =
to both inputs and outputs: SIGHASH_ALL or SIGHASH_SINGLE, with optional =
SIGHASH_ANYONECANPAY</div><div class=3D"">* commit to only inputs but =
not outputs: SIGHASH_NONE with optional SIGHASH_ANYONECANPAY</div><div =
class=3D"">* not commit to any input nor output: not using any sigop; =
using a trivial private key; using the SIGHASH_SINGLE bug in legacy =
script</div><div class=3D""><br class=3D""></div><div class=3D"">The =
last one is clearly unsafe as any relay/mining node may redirect the =
payment to any output it chooses. The witness/scriptSig is also =
replayable, so any future payment to this script will likely be swept =
immediately</div><div class=3D""><br class=3D""></div><div =
class=3D"">SIGHASH_NONE with ANYONECANPAY also allows redirection of =
payment, but the signature is not replayable</div><div class=3D""><br =
class=3D""></div><div class=3D"">But it=E2=80=99s quite obvious that not =
committing to outputs are inherently insecure</div><div class=3D""><br =
class=3D""></div><div class=3D"">The existing system doesn=E2=80=99t =
allow committing only to outputs, and we now have 3 active proposals for =
this function:</div><div class=3D""><br class=3D""></div><div =
class=3D"">1. CAT and CHECKSIGFROMSTACK (CSFS): <a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/0=
16946.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Ma=
y/016946.html</a></div><div class=3D"">2. ANYPREVOUT (aka =
NOINPUT): <a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/0=
16929.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Ma=
y/016929.html</a></div><div class=3D"">3. CHECKOUTPUTSHASHVERIFY =
(COHV): <a =
href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/0=
16934.html" =
class=3D"">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-Ma=
y/016934.html</a></div><div class=3D""><br class=3D""></div><div =
class=3D"">With outputs committed, redirecting payment is not possible. =
On the other hand, not committing to any input means the witness is =
replayable without the consent of address owner. Whether replayability =
is acceptable is subject to controversy, but the ANYPREVOUT proposal =
fixes this by requiring a chaperone signature that commits to input. =
However, if the rationale for chaperone signature stands, it should be =
applicable to all proposals listed above.</div><div class=3D""><br =
class=3D""></div><div class=3D"">A more generic approach is to always =
require a =E2=80=9Csafe" signature that commits to at least one input. =
However, this interacts poorly with the "unknown public key type=E2=80=9D =
upgrade path described in bip-tapscript (<a =
href=3D"https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.mediaw=
iki" =
class=3D"">https://github.com/sipa/bips/blob/bip-schnorr/bip-tapscript.med=
iawiki</a>), since it=E2=80=99d be a hardfork to turn an =E2=80=9Cunknown =
type sig=E2=80=9D into a =E2=80=9Csafe sig=E2=80=9D. But we could still =
use a new =E2=80=9Cleaf version=E2=80=9D every time we introduce new =
sighash types, so we could have a new definition for =E2=80=9Csafe =
sig=E2=80=9D. I expect this would be a rare event and it won=E2=80=99t =
consume more than a couple leaf versions. By the way, customised sighash =
policies could be done with CAT/CSFS.</div></body></html>=
--Apple-Mail=_10F3B835-1991-4F95-9DF9-1926AF7D6330--
|
