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; 
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)
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT
Precedence: list


--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--