Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1R8IDl-0004gI-01 for bitcoin-development@lists.sourceforge.net; Mon, 26 Sep 2011 20:56:13 +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 1R8IDk-0004aj-0N for bitcoin-development@lists.sourceforge.net; Mon, 26 Sep 2011 20:56:12 +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 7DE03204039; Mon, 26 Sep 2011 20:56:06 +0000 (UTC) From: "Luke-Jr" To: Gavin Andresen Date: Mon, 26 Sep 2011 16:55:57 -0400 User-Agent: KMail/1.13.7 (Linux/2.6.39-gentoo; KDE/4.6.5; x86_64; ; ) References: <201109261517.11245.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: <201109261655.59768.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: 1R8IDk-0004aj-0N 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 20:56:13 -0000 On Monday, September 26, 2011 4:47:06 PM Gavin Andresen wrote: > On Mon, Sep 26, 2011 at 3:17 PM, Luke-Jr wrote: > > + return DoS(10, error("AcceptToMemoryPool() : transaction with > > out-of- bounds SigOpCount")); > > + return DoS(10, error("ConnectInputs() : tried to > > spend coinbase at depth %d", pindexBlock->nHeight - pindex->nHeight)); > > These shouldn't be "DoS"'d, or else you open a new DoS when nodes > > legitimately relay such transactions/blocks. > > Huh? > > So in the future lets suppose we schedule a change to the acceptable > block rules that allows more SigOps in a block, or allows generation > transaction to be spent before 100 confirmations. At that same time, > the DoS rules will be changed. > > You cannot "legitimately" relay those blocks without a scheduled > block-chain-split. If a block-chain-split IS scheduled and the rules > change, then denying service to nodes running old, obsolete versions > of bitcoin is the right thing to do-- it is better to "fail hard" and > find it difficult or impossible to connect to the network rather than > continue with an obsolete client and a non-majority block chain. > > (and the third DoS in AcceptBlock(): prev block not found is a > "should be impossible" case, because AcceptBlock is only called when > extending the best-block chain). 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. In the second case, that transaction is not tied to a specific block. 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.