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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1XmKrS-0003ps-N0
for bitcoin-development@lists.sourceforge.net;
Thu, 06 Nov 2014 11:04:18 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.110 as permitted sender)
client-ip=62.13.148.110; envelope-from=pete@petertodd.org;
helo=outmail148110.authsmtp.com;
Received: from outmail148110.authsmtp.com ([62.13.148.110])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1XmKrR-0001Mm-BN for bitcoin-development@lists.sourceforge.net;
Thu, 06 Nov 2014 11:04:18 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id sA6B46HE070898;
Thu, 6 Nov 2014 11:04:06 GMT
Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com
[75.119.251.161]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sA6B42Ca071585
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Thu, 6 Nov 2014 11:04:05 GMT
Date: Thu, 6 Nov 2014 06:04:03 -0500
From: Peter Todd <pete@petertodd.org>
To: Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <20141106110403.GA20461@savin.petertodd.org>
References: <20141106103820.GA17096@savin.petertodd.org>
<CAPg+sBgBhemhPid0LcB9NAHckSmwPuQRRp-6CBVOe5CcOUH8NA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd"
Content-Disposition: inline
In-Reply-To: <CAPg+sBgBhemhPid0LcB9NAHckSmwPuQRRp-6CBVOe5CcOUH8NA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 9fa3ed54-65a4-11e4-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgQUFloCAgsB AmIbWlVeUFl7WWY7 bA9PbARUfEhLXhtr
VklWR1pVCwQmQm0H dBocIUhycARDcHs+ ZEVhX3cVVRIrdhMp
R0pJE2hXYXphaTUb TUkOcAdJcANIexZF O1F8UScOLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDJRUG Zig+KgsCJ2wrdhII
EyYHAWIxOm1ZO0M+ eXABdHk7CD49Qit5 IykA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 75.119.251.161/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
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 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1XmKrR-0001Mm-BN
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT
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, 06 Nov 2014 11:04:18 -0000
--vkogqOf2sHV7VnPd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Nov 06, 2014 at 02:47:29AM -0800, Pieter Wuille wrote:
> On Thu, Nov 6, 2014 at 2:38 AM, Peter Todd <pete@petertodd.org> wrote:
> > However the implementation of the STRICTENC flag simply makes pubkey
> > formats it doesn't recognize act as through the signature was invalid,
> > rather than failing the transaction. Similar to the invalid due to too
> > many sigops DoS attack I found before, this lets you fill up the mempool
> > with garbage transactions that will never be mined. OTOH I don't see any
> > way to exploit this in a v0.9.x IsStandard() transaction, so we haven't
> > shipped code that actually has this vulnerability. (dunno about
> > alt-implementations)
>=20
> Yeah, there's even a comment in script/interpreter.h currently about
> how STRICTENC is not softfork safe.
Indeed.
I actually was thinking about SCRIPT_VERIFY_MINIMALDATA, CScript(), and
FindAndDelete() Specifically that if you were to change CScript() to
convert single-character PUSHDATA's to OP_<number> you'd be making a
consensus-critical change due to how FindAndDelete() is called with a a
CScript() signature. You didn't make that mistake, and I couldn't find a
way to exploit it anyway, but it reminded me of this STRICTENC stuff.
> I didn't realize that this would
> lead to the mempool accepting invalid transactions (I thought there
> was a second validity check with the actual consensus rules; if not,
> maybe we need to add that).
It should be enough to just duplicate the CheckInputs() call in
the AcceptToMemoryPool() function:
if (!CheckInputs(tx, state, view, true, STANDARD_SCRIPT_VERIFY_FLAGS, t=
rue))
{
return error("AcceptToMemoryPool: : ConnectInputs failed %s", hash.=
ToString());
}
if (!CheckInputs(tx, state, view, true, MANDATORY_SCRIPT_VERIFY_FLAGS, =
true))
{
return error("AcceptToMemoryPool: : BUG FOUND Standard verify flags=
passed yet mandatory flags failed. %s", hash.ToString());
}
> > I suggest we either change STRICTENC to simply fail unrecognized pubkeys
> > immediately - similar to how non-standard signatures are treated - or
> > fail the script if the pubkey is non-standard and signature verification
> > succeeds.
>=20
> Sounds good to me, I disliked those semantics too.
Ok, then given we have to support hybrid encoding for awhile longer
anyway - I noticed your secp256k1 library supports it - lets do the
latter as a "least invasive" measure. I can't think of any case where
that'd be triggered other than delibrately. Doing that should make
STRICTENC a soft-fork-safe change, and we can decide at a later date if
we want to get rid of hybrid-encoded pubkeys in a further tightening of
the rules.
--=20
'peter'[:-1]@petertodd.org
000000000000000019b3c625f667bd0b93011c0a37950545a6a8fccf0b08ae73
--vkogqOf2sHV7VnPd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJUW1WfXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxOWIzYzYyNWY2NjdiZDBiOTMwMTFjMGEzNzk1MDU0NWE2
YThmY2NmMGIwOGFlNzMvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftclAf+LcU4JZFKf13cgUCggR6lWTwy
eLyyUf0i4AFh87wX6uyXh1wGwbcCu3ecPw1fZJbvCGmExCNC+Pru2jRvHHwRoZ+O
7xriQz2iAVgykDJC6d4RJAUM+iIa2QBRSXcmovhm8TWIyXIuAHKMotf6wJebIOKh
EoCJc5k2XplPZEjGJ0C/L7a8gNtX2QbVJxqQuopKYBdj7+KVL2q5u2UQo9AvGb2G
TYmL00PueNvtdi9hh0qwlBaji4NDn5IPJiIkakCOKeil7kA7hDOREMrUCQu0tWNz
xH5/wVsUHpt2dcsBr9ebgtjn2+ptGK0XqQ8aP7Nh7oquuRVBY5JaZ5bETWWXzw==
=WG4x
-----END PGP SIGNATURE-----
--vkogqOf2sHV7VnPd--
|
