Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.179 as permitted sender)
	client-ip=209.85.213.179; envelope-from=pieter.wuille@gmail.com;
	helo=mail-ig0-f179.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAPg+sBgBhemhPid0LcB9NAHckSmwPuQRRp-6CBVOe5CcOUH8NA@mail.gmail.com>
References: <20141106103820.GA17096@savin.petertodd.org>
	<CAPg+sBgBhemhPid0LcB9NAHckSmwPuQRRp-6CBVOe5CcOUH8NA@mail.gmail.com>
Date: Thu, 6 Nov 2014 02:51:14 -0800
Message-ID: <CAPg+sBhJrbV5+5M5q_E5hs18YVBG8wP=tTZEzVfn0u+UdrK1cw@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT
Precedence: list

On Thu, Nov 6, 2014 at 2:47 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
>> 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.
>
> Sounds good to me, I disliked those semantics too.

Of course: do we apply this rule to all pubkeys passed to
CHECKMULTISIG (my preference...), or just the ones that are otherwise
checked?

This will likely make existing outputs hard to spend as well (I don't
have numbers), are we okay with that? We probably can't make this a
consensus rule, as it may make existing P2SH outputs/addresses
unspendable.

-- 
Pieter