From: "Luke-Jr" <luke@dashjr.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Date: Mon, 26 Sep 2011 17:53:23 -0400
User-Agent: KMail/1.13.7 (Linux/2.6.39-gentoo; KDE/4.6.5; x86_64; ; )
References: <201109261517.11245.luke@dashjr.org>
	<201109261655.59768.luke@dashjr.org>
	<CABsx9T0TN+Nzzjod7xNJk4PNHnWPMWZUVsTHP3Yxq0C_-EgBLQ@mail.gmail.com>
In-Reply-To: <CABsx9T0TN+Nzzjod7xNJk4PNHnWPMWZUVsTHP3Yxq0C_-EgBLQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201109261753.25549.luke@dashjr.org>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Newly introduced DoS
Precedence: list

On Monday, September 26, 2011 5:38:41 PM Gavin Andresen wrote:
> > The first one I was referring to is a *transaction* with "non-standard"
> > sig op count, which is AFAIK allowed in blocks, just not accepted by the
> > mainline rules.
> 
> I sit corrected. The context is:
>     // Checking ECDSA signatures is a CPU bottleneck, so to avoid
> denial-of-service
>     // attacks disallow transactions with more than one SigOp per 34
> bytes.
>     // 34 bytes because a TxOut is:
>     //   20-byte address + 8 byte bitcoin amount + 5 bytes of ops + 1
> byte script length
>     if (GetSigOpCount() > nSize / 34 || nSize < 100)
> 	return DoS(10, error("AcceptToMemoryPool() : transaction with
> out-of-bounds SigOpCount"));
> 
> I'm having trouble imagining some future world where valid,
> new-versions-agree-to-relay-transactions have more than one SigOp per
> 34 bytes; can you give an example?

It's not future. It's presently allowed in blocks. Which means it's perfectly 
valid to relay (and also perfectly value to NOT relay or accept). Ergo, 
shouldn't be punished.

> > Maybe the person spending it sees it matured beyond 100 confirmations,
> > and you only see 99. An attacker could use these things to get nodes to
> > ban each other.
> 
> That would imply you're on a blockchain fork of more than 99 blocks
> with respect to the person spending the transaction, in which case I'd
> argue you have much bigger problems and it is a good idea for the DoS
> code to kick in and kick either you or them off the network...

Um, no? It implies you have 99 blocks since the coinbase, and he has 100 and 
wants to spend. In this scenario, it's proper to reject his transaction *until 
you have the next block*, but it doesn't make sense to punish for it.