public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT
Date: Thu, 6 Nov 2014 06:04:03 -0500	[thread overview]
Message-ID: <20141106110403.GA20461@savin.petertodd.org> (raw)
In-Reply-To: <CAPg+sBgBhemhPid0LcB9NAHckSmwPuQRRp-6CBVOe5CcOUH8NA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2831 bytes --]

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)
> 
> 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, true))
    {
        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.
> 
> 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.

-- 
'peter'[:-1]@petertodd.org
000000000000000019b3c625f667bd0b93011c0a37950545a6a8fccf0b08ae73

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

      parent reply	other threads:[~2014-11-06 11:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-06 10:38 [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT Peter Todd
2014-11-06 10:45 ` Peter Todd
2014-11-06 12:39   ` Marius Hanne
2014-11-06 10:47 ` Pieter Wuille
2014-11-06 10:51   ` Pieter Wuille
2014-11-06 11:04   ` Peter Todd [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141106110403.GA20461@savin.petertodd.org \
    --to=pete@petertodd.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=pieter.wuille@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox