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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gavinandresen@gmail.com>) id 1Rnurt-0003l7-9s
for bitcoin-development@lists.sourceforge.net;
Thu, 19 Jan 2012 16:29:41 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.175 as permitted sender)
client-ip=74.125.82.175; envelope-from=gavinandresen@gmail.com;
helo=mail-we0-f175.google.com;
Received: from mail-we0-f175.google.com ([74.125.82.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Rnurn-0007Dm-Of
for bitcoin-development@lists.sourceforge.net;
Thu, 19 Jan 2012 16:29:41 +0000
Received: by werb12 with SMTP id b12so127360wer.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 19 Jan 2012 08:29:29 -0800 (PST)
MIME-Version: 1.0
Received: by 10.216.131.153 with SMTP id m25mr11588016wei.9.1326990569627;
Thu, 19 Jan 2012 08:29:29 -0800 (PST)
Received: by 10.223.112.199 with HTTP; Thu, 19 Jan 2012 08:29:29 -0800 (PST)
Date: Thu, 19 Jan 2012 11:29:29 -0500
Message-ID: <CABsx9T2Hh-qb6CwMdD-Ov_qT6pg=muqO4uY1=+ccCxhVLUU5Gw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=0016e6de17f985e27b04b6e41132
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gavinandresen[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Rnurn-0007Dm-Of
Subject: [Bitcoin-development] Extending IsStandard() to transaction
scriptSigs
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 19 Jan 2012 16:29:41 -0000
--0016e6de17f985e27b04b6e41132
Content-Type: text/plain; charset=ISO-8859-1
I've been working on a patch to make transaction inputs (scriptSigs) with
extra data non-standard, as part of a general attitude of "try to
anticipate possible problems before they turn into real problems."
Today, any node on the network that is relaying unconfirmed transactions
can add bytes to the transaction's scriptSig's before passing it on, and
that modified version of the transaction will get relayed and might
possibly get mined.
For example, take a standard scriptSig that is: OP_PUSHDATA <signature>
OP_PUSHDATA <public key>
... and change it to: OP_PUSHDATA <Hi Mom!> OP_PUSHDATA <signature>
OP_PUSHDATA <public key>
... and the modified transaction will pass all of the IsStandard(),
IsValid(), and OP_CHECKSIG checks.
That is... unexpected, especially since it changes the transaction id. You
might transmit a transaction with ID 123 but find out it has been mined as
transaction ID 456. Satoshi's code doesn't care (it just looks like an
attempted double-spend of the coins), but I wouldn't be surprised if it
caused problems for other implementations or other transaction-handling
software.
My patch will make transactions with extra stuff in the scriptSig
non-standard, so they won't get relayed or mined by new nodes. Alternative
implementations will still have to deal with all types of double-spends, of
course, and there are other ways of producing two transactions that are
identical except for their scriptSigs (you can generate an arbitrary
number of valid signatures for a transaction if you have the private keys,
for example) so this isn't a panacea for poorly-implemented bitcoin
transaction handling software. But it does remove some "wiggle room," which
is generally a good idea for improving security.
I'm still thinking about how much further to go with this:
+ I think requiring that the <signature> and <public key> be DER-encoded
for the transaction to be IsStandard() is a good idea. DER encoding
defines a canonical way of representing data; Satoshi's code relies on
OpenSSL to decode signatures and public keys, and OpenSSL accepts any, more
general, BER encoding.
+ I'm tempted to require that the "filler item" to workaround the
OP_CHECKMULTISIG pops-one-too-many-items-off-the-stack bug be exactly OP_0.
Discussion welcome; I should be making a pull request for my patch this
afternoon.
--
Gavin Andresen
--0016e6de17f985e27b04b6e41132
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I've been working on a patch to make transaction inputs (scriptSigs) wi=
th extra data non-standard, as part of a general attitude of "try to a=
nticipate possible problems before they turn into real problems."<div>
<br></div><div>Today, any node on the network that is relaying unconfirmed =
transactions can add bytes to the transaction's scriptSig's before =
passing it on, and that modified version of the transaction will get relaye=
d and might possibly get mined.</div>
<div><br></div><div>For example, take a standard scriptSig that is: =A0 OP_=
PUSHDATA <signature> OP_PUSHDATA <public key></div><div>... and=
change it to: =A0 OP_PUSHDATA <Hi Mom!>=A0OP_PUSHDATA <signature&=
gt; OP_PUSHDATA <public key><br clear=3D"all">
<div>... and the modified transaction will pass all of the IsStandard(), Is=
Valid(), and OP_CHECKSIG checks.</div><div><br></div><div>That is... unexpe=
cted, especially since it changes the transaction id. =A0You might transmit=
a transaction with ID 123 but find out it has been mined as transaction ID=
456. =A0Satoshi's code doesn't care (it just looks like an attempt=
ed double-spend of the coins), but I wouldn't be surprised if it caused=
problems for other implementations or other transaction-handling software.=
</div>
<div><br></div><div>My patch will make transactions with extra stuff in the=
scriptSig non-standard, so they won't get relayed or mined by new node=
s. Alternative implementations will still have to deal with all types of do=
uble-spends, of course, and there are other ways of producing two transacti=
ons that are identical except for their scriptSigs =A0(you can generate an =
arbitrary number of valid signatures for a transaction if you have the priv=
ate keys, for example) so this isn't a panacea for poorly-implemented b=
itcoin transaction handling software. But it does remove some "wiggle =
room," which is generally a good idea for improving security.</div>
<div><br></div><div><br></div><div>I'm still thinking about how much fu=
rther to go with this:</div><div><br></div><div>+ I think requiring that th=
e <signature> and <public key> be DER-encoded for the transacti=
on to be IsStandard() is a good idea. =A0DER encoding defines a canonical w=
ay of representing data; Satoshi's code relies on OpenSSL to decode sig=
natures and public keys, and OpenSSL accepts any, more general, BER encodin=
g.</div>
<div><br></div><div>+ I'm tempted to require that the "filler item=
" to workaround the OP_CHECKMULTISIG pops-one-too-many-items-off-the-s=
tack bug be exactly OP_0.</div><div><br></div><div>Discussion welcome; I sh=
ould be making a pull request for my patch this afternoon.</div>
<br>--<br>Gavin Andresen<br><br>
</div>
--0016e6de17f985e27b04b6e41132--
|
