From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1R8J7J-0008QD-TY for bitcoin-development@lists.sourceforge.net; Mon, 26 Sep 2011 21:53:37 +0000 X-ACL-Warn: Received: from zinan.dashjr.org ([173.242.112.54]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1R8J7J-00069g-15 for bitcoin-development@lists.sourceforge.net; Mon, 26 Sep 2011 21:53:37 +0000 Received: from ishibashi.localnet (fl-184-4-160-40.dhcp.embarqhsd.net [184.4.160.40]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id A56A4204039; Mon, 26 Sep 2011 21:53:31 +0000 (UTC) From: "Luke-Jr" To: Gavin Andresen 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> In-Reply-To: X-PGP-Key-Fingerprint: CE5A D56A 36CC 69FA E7D2 3558 665F C11D D53E 9583 X-PGP-Key-ID: 665FC11DD53E9583 X-PGP-Keyserver: x-hkp://subkeys.pgp.net MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201109261753.25549.luke@dashjr.org> X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.5 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-Headers-End: 1R8J7J-00069g-15 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Newly introduced DoS X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 21:53:38 -0000 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.