Protecting Bitcoin against network-wide DoS attack [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2013-07-15T07:32:24+00:00


Summary:

In a discussion about anti-denial of service (DoS) measures in Bitcoin, John Dillon suggests implementing measures for non-SPV-mode clients where incoming peers are required to do "useful work". This involves kicking off peers who have relayed the least fee-paying transactions and valid blocks as incoming connection slots get used up. The system aims to keep the peers who have relayed the most. Outgoing peers follow randomized logic to maintain the network's randomized structure. Peter Todd proposes adding per-node accounting once nodes have unique identifiers, which can later be used for permanent node identifiers with SSL and message signing.The Bitcoin network is vulnerable to a cheap attack due to the fact that incoming connections are limited and not subject to any criteria. An attacker can exploit this vulnerability by repeatedly querying DNS seeds for new addresses, creating enough incoming connections to overwhelm nodes and prevent them from accepting further clients. With nMaxConnections defaulting to 125 and a limit on file descriptors, stateful firewalls could also impose additional limits. The cost to the attacker is minimal, requiring only an INV message per transaction and block and some gossiped peer addresses, averaging at about 30 bytes per second. Peter estimates that an attack could be launched with just 200 well-distributed IP addresses.For SPV (Simplified Payment Verification) client attacks, attackers can pretend to be an SPV client, reducing their incoming bandwidth consumption while increasing resource usage on the node. Since bandwidth is not reusable, attackers with access to EC2 or a botnet have lower costs for bandwidth compared to users with an Android wallet on a phone. To counter this, SPV nodes need to provide a way to prove that they have sacrificed limited resources, allowing legitimate users to be distinguished from attackers. If this fails, attacks must become expensive enough to discourage script-kiddies. For non-SPV-mode clients, anti-DoS measures can be implemented by requiring peers to do "useful work". As incoming connection slots get used up, the system kicks off incoming peers who have relayed the least fee-paying transactions and valid blocks, while keeping those who have relayed the most. SPV nodes can prioritize their connection by creating high-fee transactions with their own coins during an attack. When dealing with SPV peers, nodes can consider how long it takes for another node to advertise the transactions. Future improvements can be made, such as implementing micropayment channels and coinbase probabilistic payments, which would not require blockchain transactions solely for anti-DoS purposes.To understand the impact of the attack, a demonstration would be useful. Pieter Wuille's bitcoin-seeder code could potentially be reused as it already has the required functionality to create a large number of connections. Simply running multiple instances of the code could achieve the desired effect.


Updated on: 2023-08-01T05:17:48.736138+00:00