From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1R41CO-00035D-0T for bitcoin-development@lists.sourceforge.net; Thu, 15 Sep 2011 01:57:08 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.161.47 as permitted sender) client-ip=209.85.161.47; envelope-from=gavinandresen@gmail.com; helo=mail-fx0-f47.google.com; Received: from mail-fx0-f47.google.com ([209.85.161.47]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1R41CM-0008Lx-OC for bitcoin-development@lists.sourceforge.net; Thu, 15 Sep 2011 01:57:07 +0000 Received: by fxi1 with SMTP id 1so270997fxi.34 for ; Wed, 14 Sep 2011 18:57:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.5.76 with SMTP id 12mr809198fau.103.1316051820256; Wed, 14 Sep 2011 18:57:00 -0700 (PDT) Received: by 10.152.25.105 with HTTP; Wed, 14 Sep 2011 18:57:00 -0700 (PDT) Date: Wed, 14 Sep 2011 21:57:00 -0400 Message-ID: From: Gavin Andresen To: Bitcoin Dev Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1R41CM-0008Lx-OC Subject: [Bitcoin-development] Request review: drop misbehaving peers 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: Thu, 15 Sep 2011 01:57:08 -0000 I'm looking for review of this pull request: https://github.com/bitcoin/bitcoin/pull/517 The big idea: if a peer is sending you obviously wrong information, punish it by maybe dropping your connection to it, and ban it's IP address so it cannot immediately re-connect. The probability of dropping the connection, and the length of the ban, depend on how how potentially wasteful/damaging the peer is behaving. So sending an extra 'version' message is a minor transgression that is usually tolerated, sending a more-than MAX_BLOCK_SIZE block is a major transgression that gets the peer disconnected immediately. Detailed how-it-works, using "I got a version message I wasn't expecting" as the specific example: Getting an unexpected version message from a peer increases that peer's 'misbehaving' score by 10, and (assuming that is the peer's first bad behavior) gives it a 10% chance of being disconnected. If it is disconnected, then that peer's IP address is banned from connecting for a couple of hours. If it is not disconnected, then nothing happens unless the peer misbehaves again; if it does, then its chances of being disconnected go up, and the length of time it will be banned increases. Misbehavior/ban information is stored only in memory, and information about misbehaving peers is never broadcast. Also, peers that are disconnected/banned are just dropped, there is no warning or reason sent. I think this will eliminate a lot of potential denial-of-service attacks, and could be a good framework for responding to other potential attacks. "We" should still look through the code and limit the potential size of any data structures that an attacker might target (transaction pool, orphan block pool); the DoSprevention changes are meant to make it harder for an attacker to stay connected long enough to pull off an attack. The danger is that I got something wrong; what if an attacker can leverage the DoSprevention code to split or shatter the network? Here's my thinking on that, please help check my work: + I'm relying on TCP to prevent IP address spoofing (otherwise an attacker could force you to disconnect from your peers by pretending to be them and sending you a bad block). + Peers are only penalized for sending messages that won't, and shouldn't, get relayed. So an attacker shouldn't be able to poison the network with a bad message that is propogated and then causes everybody to disconnect from everybody else. + I specifically do not punish peers for relaying what look like double-spend transactions. If I did, then an attacker could try to segment the network into two pieces by broadcasting a series of double-spends from two halves of the network, and waiting until the nodes "in the middle" disconnected/banned across the 'seam'. So: please let me know if or how I'm being an idiot. -- -- Gavin Andresen