What prevents an attacker from doing DDOS on bitcoin network by sending billions of transaction to himself?

Question

I know that transacion fees on low-priority transactions adds additional cost, but what if an attacker uses a lot of 0.100001 BTC transactions, so he doesn't have to pay the fee, because transactions are greater than 0.01 btc, and wouldn't be considered low-priority. There wouldn't be any loosing of money, because there are no transacion fees to be paid. Only huge investment. What would be the amount of bitcoins needed for that?

Answer 1

This attack wouldn't work very well, no matter how much money the attacker had.

Your question seems to be based on the assumption that transactions larger than BTC 0.01 can always be sent without fees. This is not accurate.

There are two main risks from such an attack:

1. The attacker's transactions might occupy all the available space in blocks, preventing other people from having their transactions confirmed.

2. The nodes on the peer-to-peer network might use a lot of bandwidth relaying the attacker's transactions, and not relay other transactions.

What I will describe here is how this issue is avoided by miners and nodes using the unmodified Bitcoin Core software. The rules implemented by this software are explained in detail here, and what follows is merely a summary. Of course, people are free to use other software, so these rules are not universally followed. Nevertheless, as long as a significant fraction of miners / users do something similar to this, the attack won't cause serious problems.

As for 1, when selecting which transactions to include in a block, transactions with fees are generally preferred to transactions without fees, and higher fees are preferred to lower fees. So your attacker's zero-fee transactions would generally not displace those of users who did pay fees.

As an exception, 50 Kbytes in each block are reserved for high-priority transactions, even if they have no fees. Priority is set not only by the size of the transaction, but by the age of its inputs (the so-called "bitcoin days destroyed" metric). If our attacker wants to make lots of transactions, he will have to send the same coins over and over again, meaning the age of the inputs will be low. Other transactions that go unconfirmed for a while will slowly gain priority and eventually exceed those of our attacker.

So in summary:

• Fee-paying transactions would not be disrupted

• Non fee-paying transactions might be delayed, but would still eventually go through.

As for relaying, a simpler rule is used: there is a flat limit on the number of bytes per minute of non-fee-paying transactions that will be relayed. Fee-paying transactions are not subject to this limit. So:

• Fee-paying transactions would still be relayed as before

• Nodes would not use an excessive amount of bandwidth in relaying the attacker's transactions; most of them would not be relayed

• Non fee-paying transactions might have a harder time being relayed. Users could avoid this by including transaction fees, or by submitting their transactions directly to miners without using the peer-to-peer network.

Answer 2

This was actually tested on the BCH netowrk. Here's the answer: https://www.reddit.com/r/btc/comments/9d94ja/bch_stress_test_failed_to_produce_even_on_maximum/