Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.96 as permitted sender)
	client-ip=62.13.148.96; envelope-from=pete@petertodd.org;
	helo=outmail148096.authsmtp.net; 
Date: Thu, 6 Nov 2014 05:38:20 -0500
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Message-ID: <20141106103820.GA17096@savin.petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="k1lZvvs/B4yU6o8G"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT
Precedence: list


--k1lZvvs/B4yU6o8G
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

So right now git head will accept the following invalid transaction into
the mempool:

0100000001140de229e08fda25cbc16ded2618cdacce49fcb18c0b6ccdace00040909adae40=
00000009000493046022100f7828d81c849c5448ba5ba4ef55df6b4d0ba3ae3f1a59cff3291=
880c2c8e524f022100d2f5bc9dc2f0674eded31023cb47e61a596e10f8f1ddd44cf92d290c9=
db577c70144410778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab3=
5c71a1518063243acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455ac91fff=
fffff01102700000000000017a914e661a2229cc824329c9409f49d99cb5ac350c928870000=
0000

which spends the redeemScript:

0778d430274f8c5ec1321338151e9f27f4c676a008bdf8638d07c0b6be9ab35c71a15180632=
43acd4dfe96b66e3f2ec8013c8e072cd09b3834a19f81f659cc3455
CHECKSIG NOT

That pubkey is valid and accepted by OpenSSL as it's obscure "hybrid"
format. The transaction is invalid because the signature is correct,
causing CHECKSIG to return 1, which is inverted to 0 by the NOT.

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)

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.

Thoughts?

--=20
'peter'[:-1]@petertodd.org
0000000000000000152dc55f27338b58325f0432d2dc6edb90c8d449d9959583

--k1lZvvs/B4yU6o8G
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJUW0+XXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxNTJkYzU1ZjI3MzM4YjU4MzI1ZjA0MzJkMmRjNmVkYjkw
YzhkNDQ5ZDk5NTk1ODMvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfu4qwf9G3Al42HvzWeAcHmHxfFPGakB
zK2t4oW4Lu4jsqNrEcmvdJ1ITVLzwWcGOqjsOlliFF5sS7w8ODHZWzLe7tczlrWP
Ke2aqp741ccuiw/eSbajD9UsZrvfOvnqgkAq6GqfqA6GX2twnILE7TfwtHOltNE1
9mp5m8YC/R+UQPIaejN/zZxAVVInmxJMfY/8xGumaPip7iUOWpyZEFenUshuKz/d
ReN6Q8u8IGSzZx8uTG6JZTbBgMCLJE8OOyM+3KxebrQm/DWQAUaQNoO0FcBfGToL
6VLnVFeWIA/4v4nC0yJqtahYmsKSRcbR2QgXO7FAo2F6rj1WvjXcqrHWb7rvVg==
=6m0W
-----END PGP SIGNATURE-----

--k1lZvvs/B4yU6o8G--