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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UyUWW-0000Ni-BU for bitcoin-development@lists.sourceforge.net; Sun, 14 Jul 2013 22:12:08 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of googlemail.com designates 74.125.83.54 as permitted sender) client-ip=74.125.83.54; envelope-from=john.dillon892@googlemail.com; helo=mail-ee0-f54.google.com; Received: from mail-ee0-f54.google.com ([74.125.83.54]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UyUWU-0005gf-Iv for bitcoin-development@lists.sourceforge.net; Sun, 14 Jul 2013 22:12:08 +0000 Received: by mail-ee0-f54.google.com with SMTP id t10so7280051eei.13 for ; Sun, 14 Jul 2013 15:12:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.14.122.201 with SMTP id t49mr56579601eeh.26.1373839920266; Sun, 14 Jul 2013 15:12:00 -0700 (PDT) Received: by 10.223.12.131 with HTTP; Sun, 14 Jul 2013 15:12:00 -0700 (PDT) Date: Sun, 14 Jul 2013 22:12:00 +0000 Message-ID: From: John Dillon To: Bitcoin Dev Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.4 (-) 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 (john.dillon892[at]googlemail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (john.dillon892[at]googlemail.com) -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 X-Headers-End: 1UyUWU-0005gf-Iv Subject: [Bitcoin-development] Protecting Bitcoin against network-wide DoS attack 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: Sun, 14 Jul 2013 22:12:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 It's been pointed out recently how a fairly cheap attack on the Bitcoin network would be to take advantage of the fact that we limit the number of incoming connections, but don't require anything of those connections. This means an attacker can simply repeatedly query the the DNS seeds for new addresses and make enough incoming connections that those nodes can not accept further clients. nMaxConnections defaults to 125, and beyond that there is the limit on file descriptors, as well as possible limits by stateful firewalls. (how much memory/cpu does an incoming connection require?) The DNS seeds themselves crawl the network on your behalf, and let you direct the attack starting at the nodes new SPV clients are most likely to connect too. The cost to the attacker is minimal, 1 INV message per transaction and block, and some gossiped peer addresses. Currently that should be on the order of 30 bytes a second. The attacker can do even better by pretending to be an SPV client, thus reducing their incoming bandwidth consumption to nearly nothing, yet increasing resource usage on the node. Peter estimated you would need just 200 or so well distributed IP addresses to make it impossible to use an SPV client. In fact as far as I can tell for incoming connections we don't force incoming connections to be well distributed, so the attack could be done by simply one server with enough amount of bandwidth. Estimates of the total number of nodes out there on mainnet are in the tens of thousands, let's say 25,000 for arguments sake. 125 connections to every one of those nodes would only cost the attacker 94MB/s of incoming bandwidth, easily attainable by a few cheap EC2 nodes, and on EC2 incoming bandwidth is free. The SPV version of the attack would let the attacker spend as little as they wished. Obviously if we want to make it possible for SPV nodes to reliably connect to the network we need to give them a way to prove they have sacrificed some limited resource to allow nodes to distinguish legit users from attackers. Failing that, we need to make attacks sufficiently expensive to discourage bored script-kiddies, much the same way flooding the network with transactions is sufficiently expensive due to fees that such attacks are impractical. Now something to keep in mind is whatever we ask SPV nodes to sacrifice must not be reusable. For instance proof-of-stake *doesn't* work without consensus because an attacker can reuse the proof for multiple connections. Similarly IP addresses don't work, requring incoming connections to be "well distributed" in IP space isn't a bad idea, but it doesn't buy much DoS resistance. Fees paid by confirmed transactions do work, but only if something links the transaction to the specific connection. We also want whatever the nodes to sacrifice to be something not much more costly to the client than to the attacker. Bandwidth isn't reusable, but an attacker with EC2 or a botnet has vastly lower costs for bandwidth than a user with an Android wallet on a phone. For a non-SPV-mode client we can easily do anti-DoS by requiring the peer to do "useful work". As the incoming connections slots get used up, simply kick off the incoming peers who have relayed the least fee-paying transactions and valid blocks, keeping the peers who have relayed the most. We can continue to use the usual, randomized, logic for outgoing peers to attempt to preserve the randomized structure of the bitcoin network. Without an ongoing attack nodes making new connections are unaffected, and during an attack new connections are made somewhat easier by the increased numbers of incoming slots made available as the attackers connections timeout. Yes an attacker can simply relay some high-fee transactions to keep their nodes from being kicked off, but in that case are they really an attacker? I reject the argument that we are letting them de-randomize the structure of the network because as I've shown they can already do that with little expenditure. For SPV nodes again in the absense of an attack such anti-DoS code has no effect. When an attack is launched the SPV client can simply create some high-fee transactions with their own coins to get connection priority. SPV nodes already have serious privacy issues, so I don't see the creation of transactions as a big deal. Re-use is an issue, but nodes can take into account how long it takes for another nodes to advertise the transactions when dealing with SPV peers. Better systems can be implemented later, such as micropayment channels and coinbase probabalistic payments, that don't result in blockchain transactions just for the sake of anti-DoS. A demo of the attack against would be useful. Pieter Wuille's bitcoin-seeder code could probably be re-used as it already has the required functionality of making large numbers of connections. In fact, simply running multiple instances of it could do the trick. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR4yHgAAoJEEWCsU4mNhiPRvkH/3fl5brCe+1cBUoFtAnVHV+0 dezNeXo+nAbDg8XCkF6cmFkDBSgTj8l2iy0N1pfCq1XDXmqfM5p+CtxIBuIwwURc KnpwNnRwoQ0JKYFonmaM0rQgOcXnRvyNq2DVL/b/fA6X3I5nignWNFDtzpvFhM+J IjhEVbu5S25c+O8LFlJV0ujjBgnR/8gJ0xV2fvdsaisAVHly1n9QWa1FEnMz7hp9 wfXPBh8tnehKnsspyeAEq5Yc/Yyow97CdwOqPVknI0rhes0OWR8ORcJ2NkBZm/Pn rUFFMwAme/K1f3PqW1+EpM4gG/pJvg+xU5E5KdqgnjsQLoEGWtMcxEdAeCoBuNI= =jzfg -----END PGP SIGNATURE-----