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
|
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E607F907
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Nov 2016 15:54:40 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com
[209.85.220.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2C0B1E3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Nov 2016 15:54:40 +0000 (UTC)
Received: by mail-qk0-f169.google.com with SMTP id n204so356633450qke.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Nov 2016 07:54:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-io.20150623.gappssmtp.com; s=20150623;
h=mime-version:from:date:message-id:subject:to;
bh=CcaV437KcYJVJel8itiCWRKRi1aYcB8do4zpPdfSsWc=;
b=F3Haw6WQetdRO0NpydJRpAf7VS+gPUQ+9eoPRJfAm4bQpyTMrYOfvMe4k8cta4G7eE
YFdmIVaURuI1xjvdql6YS4ZpPesh5Vud3Yn9HFeEbJ5U4/W0ELbJlCqLIns4OS/ZbFHw
mCtbnYQM1bPthAhxUt8Jx7zI53DY/nVd+HrJGrbRQyfA0WUPBnK+nj7p1Ovg1dZ1CFup
0FbhW5npTyxFkgL4xH1DyIg0yCdb3NEODifK/jVT2hBCvEtReyZRZCVn87SMft4TfDWF
7jWlBl6nlAQkKDv0EV5pOLy+y8+BJdxS9SPcR2+gic21tDECtHufsR6DjqnY5HkTrzU9
dETg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=CcaV437KcYJVJel8itiCWRKRi1aYcB8do4zpPdfSsWc=;
b=UtP2Ss9TMfQZiwcMUFjxt7aGdHF31QAgI4svkf0VAogPF7KKaKMfBlspEwJjJbvjcN
AP14dtWaCX95aWc6xeIQ50/ONNHeoWL9OC7YsriC1zQLrGkTgqDBDH0smffrNmfwSRAQ
X8/ywULnB9kl9CiOiLNeWn/9MS0sL80ffHxclX3h21FR5BNeTH6ueCcHMo8l6VItvYYu
6wcutXlmbRLhJ6wbcL0QL0oQ39jYbwDtfV2s4feMufMEL40aVcoN85rg6WwyL85PEEOo
GIgg2xh/dbC3XUvZ8rfWWum2NJBAbWLOKDB0Gv0SlUxdEgPtd9gNmO7Q9TnakYqxgqoX
hsJQ==
X-Gm-Message-State: AKaTC00DJpJsgdUOaEQgJPSPClr77YyIapGVbqu1lIsmGKDJ6aJZnFr+/HCxic1rPCww4qDOZvtnisJtr5988DRN
X-Received: by 10.55.162.79 with SMTP id l76mr15863074qke.17.1479743679309;
Mon, 21 Nov 2016 07:54:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.134.2 with HTTP; Mon, 21 Nov 2016 07:54:19 -0800 (PST)
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Mon, 21 Nov 2016 10:54:19 -0500
Message-ID: <CAMZUoKm3RXs_HAzGT3gz60kiB6FQnjpGRhfu6biwZ5a_TcPeaA@mail.gmail.com>
To: Tom <tomz@freedommail.ch>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c0880e65d41970541d1ac07
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Flexible Transactions.
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: Mon, 21 Nov 2016 15:54:41 -0000
--94eb2c0880e65d41970541d1ac07
Content-Type: text/plain; charset=UTF-8
Hi Tom,
On Tue, Sep 20, 2016 at 1:15 PM, Tom via bitcoin-dev <bitcoin-dev@lists.
linuxfoundation.org> wrote:
>
> The OP_CHECKSIG is the most well known and, as its name implies, it
> validates a signature.
> In the new version of 'script' (version 2) the data that is signed is
> changed to be equivalent to the transaction-id. This is a massive
> simplification and also the only change between version 1 and version 2 of
> script.
>
I'm a fan of simplicity too; Unfortunately, your proposal above to change
the semantics of OP_CHECKSIG is too naive.
The SIGHASH data used in both the original Bitcoin script and in Segwit
script contains data indicating which input is being signed. In Bitcoin
script, the input is being signed is indicated by the input that has a
non-empty scriptSig field. In the Segwit script, the outpoint
corresponding to the input being signed is explicitly included in the
signature data. By signing only the transaction id, your proposed signature
does not include the data that tells which input of the transaction is
being signed. Thus if different inputs share the same public key due to
key reuse, then the signatures on those different inputs will be
identical. Your Flexible Transactions proposal opens up a new line of
attack against Bitcoin that doesn't currently exist.
Consider the following simple example, suppose you and I are jointly
preparing a transaction to mix our coins, or perhaps we are jointly funding
some purchase. We jointly prepare a transaction with one input from you
and another input from me. We each sign the transaction and hand the
signature data over to each other so we can produce a completed
transaction. But oh no! I lied to you. I didn't use my own input to the
transaction. "My input" was actually the outpoint from one of *your*
transactions; one that has the same public key as the input you have
chosen. Now I copy your signature you have provided in your input to cover
"my input", which is really your coins. Surprise, it turns out you are
funding both inputs to our "jointly" funded purchase. Other protocols are
likely similarly broken by your Flexible Transactions proposal.
I personally rate this flaw as about the same caliber as the transaction
malleability you are trying to fix. Sure, with enough vigilance, perhaps
you can detect and avoid this trap. However, it requires a bunch of
unexpected work. You must always examine every other input to a
transaction you are about to sign to make sure that it isn't one of your
inputs, which means you probably need a copy of the UXTO set to lookup
outpoints, which is a huge burden, especially if you are a hardware
wallet. If you are not vigilante, your funds may end up stolen. Surely it
is better not to open this line of attack.
For the most part, the SIGHASH works the way it does in Bitcoin for a
reason. You cannot simply throw away the parts you don't understand or
appreciate. You should take the time to learn why things are the way they
are, and then, only once you are certain that some aspects are not, or no
longer, needed then can you propose removing them.
--94eb2c0880e65d41970541d1ac07
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Tom,<br><div><br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">On Tue, Sep 20, 2016 at 1:15 PM, Tom via bitcoin-dev <span=
dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" t=
arget=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>></span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><br>
The OP_CHECKSIG is the most well known and, as its name implies, it<br>
validates a signature.<br>
In the new version of 'script' (version 2) the data that is signed =
is<br>
changed to be equivalent to the transaction-id. This is a massive<br>
simplification and also the only change between version 1 and version 2 of<=
br>
script.<br></blockquote><div><br></div><div>I'm a fan of simplicity too=
; Unfortunately, your proposal above to change the semantics of OP_CHECKSIG=
is too naive.<br><br>The SIGHASH data used in both the original Bitcoin sc=
ript and in Segwit script contains data indicating which input is being sig=
ned.=C2=A0 In Bitcoin script, the input is being signed is indicated by the=
input that has a non-empty scriptSig field.=C2=A0 In the Segwit script, th=
e outpoint corresponding to the input being signed is explicitly included i=
n the signature data. By signing only the transaction id, your proposed sig=
nature does not include the data that tells which input of the transaction =
is being signed.=C2=A0 Thus if different inputs share the same public key d=
ue to key reuse, then the signatures on those different inputs will be iden=
tical.=C2=A0 Your Flexible Transactions proposal opens up a new line of att=
ack against Bitcoin that doesn't currently exist.<br><br></div><div>Con=
sider the following simple example, suppose you and I are jointly preparing=
a transaction to mix our coins, or perhaps we are jointly funding some pur=
chase.=C2=A0 We jointly prepare a transaction with one input from you and a=
nother input from me.=C2=A0 We each sign the transaction and hand the signa=
ture data over to each other so we can produce a completed transaction.=C2=
=A0 But oh no! I lied to you. I didn't use my own input to the transact=
ion.=C2=A0 "My input" was actually the outpoint from one of *your=
* transactions; one that has the same public key as the input you have chos=
en.=C2=A0 Now I copy your signature you have provided in your input to cove=
r "my input", which is really your coins.=C2=A0 Surprise, it turn=
s out you are funding both inputs to our "jointly" funded purchas=
e.=C2=A0 Other protocols are likely similarly broken by your Flexible Trans=
actions proposal.<br><br></div><div>I personally rate this flaw as about th=
e same caliber as the transaction malleability you are trying to fix.=C2=A0=
Sure, with enough vigilance, perhaps you can detect and avoid this trap.=
=C2=A0 However, it requires a bunch of unexpected work.=C2=A0 You must alwa=
ys examine every other input to a transaction you are about to sign to make=
sure that it isn't one of your inputs, which means you probably need a=
copy of the UXTO set to lookup outpoints, which is a huge burden, especial=
ly if you are a hardware wallet.=C2=A0 If you are not vigilante, your funds=
may end up stolen. Surely it is better not to open this line of attack.<br=
><br>For the most part, the SIGHASH works the way it does in Bitcoin for a =
reason. You cannot simply throw away the parts you don't understand or =
appreciate.=C2=A0 You should take the time to learn why things are the way =
they are, and then, only once you are certain that some aspects are not, or=
no longer, needed then can you propose removing them.<br></div></div></div=
></div></div>
--94eb2c0880e65d41970541d1ac07--
|
