<p>It seems like one of the basic assumptions you are making is that all transactions (&quot;fake&quot; or not) are added to the blockchain. But that is not the case. Only <strong>valid</strong> transactions can be included in a block and thus added to the blockchain. So even if some bad actor spams invalid transactions, these won't get added to the blockchain and force new nodes to sync them.</p>
<p>Furthermore, nodes will only relay blocks and transactions that are valid. If they are invalid, then they will not be forwarded on to the node's peers. Additionally, nodes have local Denial of Service protections. If a particular node is sending multiple invalid transactions and blocks, then the node will disconnect them and even refuse to accept a connection from/to that node (aka the malicious node is banned by the local node).</p>
<p>So a bad actor could make nodes that connect to many other nodes and try to spam them, but they will find themselves quickly peerless as everyone disconnects and bans them. Of course the way around this would be to change their IP address, but this means they constantly have to do that, just in order to get disconnected and banned. It would be essentially impossible to maintain a sustained attack on the network in this manner.</p>
<p>Lastly, the bad actor would only be able to do this to nodes that accept incoming connections. Nodes that only make outgoing connections would be unlikely to connect to the bad actors nodes, at least after they have changed their IP address once. This is because nodes that only make outbound connections only connect to nodes that are considered &quot;good&quot;, which includes things like long uptime. So the bad actor would have to maintain a node for a while (so it has a long uptime) in order to get incoming connections from outbound only nodes. But once they start spamming, they get disconnected and banned as they would for nodes that accept incoming connections. From that point on, nodes will not make outbound connections to it because it has misbehaved or because it has changed IP addresses and the new IP address does not have a long uptime.</p>

CC BY-SA 4.0
2021-05-24T17:09:48.520Z
I see. This is in line with @RedGrittyBrick's comment. I guess what I was looking for was for the network to have a reliable way to turn down such an attack which is the quick denial of service so that an attack cannot be sustained. Thanks a lot! I'm accepting your answer.
nikfilippas
CC BY-SA 4.0
2021-05-24T16:42:31.263Z
2021-05-24T16:42:31.263Z
Ava Chow
<p>We are in 2050. People show an ever-growing distrust in the global banking system and start transitioning to only using Bitcoin: most companies accept it as a form of payment, and people settle their bills with Bitcoin. Even the kid with the lemonade stand down the road accepts Bitcoin as her payment.</p>
<p>Banks are worried because they are losing customers and revenue. Legislation has not managed to protect banks and the smaller ones have already started to shut down or provide alternative services.</p>
<p>Then, the CEOs of Atlantis Bank and River Banks, who are the only healthy banks remaining come up with a plan:</p>
<p><em>A transaction's hash can easily be checked. Why not attack the Bitcoin network with an insurmountable number of fake transactions! We will produce so much noise, and the network nodes will be occupied with checking our fake transactions instead of the real ones, so much so, that a considerable fraction of the total network computing power will be devoted to checking fake hashes. Real transaction verification will come to a halt, and people won't be able to do any everyday trade. They will only be left with one option: return back to us.</em></p>
<p>Here is my thinking:</p>
<ul>
<li>Bitcoin's blockchain is increasing in size.</li>
<li>More nodes are added to the Bitcoin network.</li>
<li>Nodes are getting faster.</li>
</ul>
<p>I expect this to have an overall quadratic effect (in the best-case scenario) in this attack: it will be cheaper for the attacker to generate and submit fake transactions, but it will also be cheaper for the network to reject the fake transactions. <strong>BUT</strong> the blockchain is increasing in size so at some point the network will be at disadvantage.</p>
<p>Here are some back-of-the-envelope calculations I made, assuming a <em>constant</em> blockchain size of 15 GB:</p>
<ul>
<li>SHA256 efficiency with today's processors: 45 cycles/byte;</li>
<li>So a chain of size 350 GB, requires 1.6e+13 cycles to be rejected as fake.</li>
<li>With 1 core syncing at 3.5 GHz, this will take 4500 s (1.25 hr).</li>
</ul>
<p>Are my premises wrong? Won't there be a turning point, when the cost of the largest banks losing customers will be greater than the cost of them launching such an attack (in full secrecy)? How can the network defend itself against these attacks? Sure, one can always add more nodes to the network increasing the fee, but won't that also turn customers back to the banks (i.e. rendering the attack successful)?</p>

CC BY-SA 4.0
2021-05-24T15:42:20.077Z
Does this answer your question? [How does the Bitcoin network deal with bad actors?](https://bitcoin.stackexchange.com/questions/64200/how-does-the-bitcoin-network-deal-with-bad-actors)
RedGrittyBrick
CC BY-SA 4.0
2021-05-24T16:29:50.443Z
It does not, in my scenario, the attacker doesn't spend *any* time calculating the hash of the block; they just produce random blocks and hashes. This will take an extremely small amount of time while checking the hash will take some time (small but significant).
nikfilippas
CC BY-SA 4.0
2021-05-24T16:34:27.017Z
I was thinking of the answer which points out *"The corrupt miner will ... find itself quickly blacklisted and ignored"* - that blacklisting would apply.
RedGrittyBrick
CC BY-SA 4.0
2021-05-24T17:24:31.023Z
This fact I didn't know of also kind of answers my question. Thanks for helping out!
nikfilippas
CC BY-SA 4.0
2021-05-24T19:46:47.887Z
Does this answer your question? [Why is there no such thing as a redirected, forged, or fake transaction?](https://bitcoin.stackexchange.com/q/95564/5406)
Murch
<transaction-fees><security><unconfirmed-transactions><attack><banks>
Can an attacker flood the Bitcoin network with fake transactions?
nikfilippas
# Can an attacker flood the Bitcoin network with fake transactions?

(Asked by: username_0 on 2021-05-24)

We are in 2050. People show an ever-growing distrust in the global banking system and start transitioning to only using Bitcoin: most companies accept it as a form of payment, and people settle their bills with Bitcoin. Even the kid with the lemonade stand down the road accepts Bitcoin as her payment.

Banks are worried because they are losing customers and revenue. Legislation has not managed to protect banks and the smaller ones have already started to shut down or provide alternative services.

Then, the CEOs of Atlantis Bank and River Banks, who are the only healthy banks remaining come up with a plan:

*A transaction's hash can easily be checked. Why not attack the Bitcoin network with an insurmountable number of fake transactions! We will produce so much noise, and the network nodes will be occupied with checking our fake transactions instead of the real ones, so much so, that a considerable fraction of the total network computing power will be devoted to checking fake hashes. Real transaction verification will come to a halt, and people won't be able to do any everyday trade. They will only be left with one option: return back to us.*

Here is my thinking:

* Bitcoin's blockchain is increasing in size.
* More nodes are added to the Bitcoin network.
* Nodes are getting faster.

I expect this to have an overall quadratic effect (in the best-case scenario) in this attack: it will be cheaper for the attacker to generate and submit fake transactions, but it will also be cheaper for the network to reject the fake transactions. **BUT** the blockchain is increasing in size so at some point the network will be at disadvantage.

Here are some back-of-the-envelope calculations I made, assuming a *constant* blockchain size of 15 GB:

* SHA256 efficiency with today's processors: 45 cycles/byte;
* So a chain of size 350 GB, requires 1.6e+13 cycles to be rejected as fake.
* With 1 core syncing at 3.5 GHz, this will take 4500 s (1.25 hr).

Are my premises wrong? Won't there be a turning point, when the cost of the largest banks losing customers will be greater than the cost of them launching such an attack (in full secrecy)? How can the network defend itself against these attacks? Sure, one can always add more nodes to the network increasing the fee, but won't that also turn customers back to the banks (i.e. rendering the attack successful)?

**Tags:** transaction-fees, security, unconfirmed-transactions, attack, banks

> **Comments:**
> **username_1**: Does this answer your question? [How does the Bitcoin network deal with bad actors?](https://bitcoin.stackexchange.com/questions/64200/how-does-the-bitcoin-network-deal-with-bad-actors)  
> **username_0**: It does not, in my scenario, the attacker doesn't spend *any* time calculating the hash of the block; they just produce random blocks and hashes. This will take an extremely small amount of time while checking the hash will take some time (small but significant).  
> **username_1**: I was thinking of the answer which points out *"The corrupt miner will ... find itself quickly blacklisted and ignored"* - that blacklisting would apply.  
> **username_0**: This fact I didn't know of also kind of answers my question. Thanks for helping out!  
> **username_2**: Does this answer your question? [Why is there no such thing as a redirected, forged, or fake transaction?](https://bitcoin.stackexchange.com/q/95564/5406)  

---

## 1 answers

### Answer by username_3 on 2021-05-24. Score: 2 | Accepted answer

It seems like one of the basic assumptions you are making is that all transactions ("fake" or not) are added to the blockchain. But that is not the case. Only **valid** transactions can be included in a block and thus added to the blockchain. So even if some bad actor spams invalid transactions, these won't get added to the blockchain and force new nodes to sync them.

Furthermore, nodes will only relay blocks and transactions that are valid. If they are invalid, then they will not be forwarded on to the node's peers. Additionally, nodes have local Denial of Service protections. If a particular node is sending multiple invalid transactions and blocks, then the node will disconnect them and even refuse to accept a connection from/to that node (aka the malicious node is banned by the local node).

So a bad actor could make nodes that connect to many other nodes and try to spam them, but they will find themselves quickly peerless as everyone disconnects and bans them. Of course the way around this would be to change their IP address, but this means they constantly have to do that, just in order to get disconnected and banned. It would be essentially impossible to maintain a sustained attack on the network in this manner.

Lastly, the bad actor would only be able to do this to nodes that accept incoming connections. Nodes that only make outgoing connections would be unlikely to connect to the bad actors nodes, at least after they have changed their IP address once. This is because nodes that only make outbound connections only connect to nodes that are considered "good", which includes things like long uptime. So the bad actor would have to maintain a node for a while (so it has a long uptime) in order to get incoming connections from outbound only nodes. But once they start spamming, they get disconnected and banned as they would for nodes that accept incoming connections. From that point on, nodes will not make outbound connections to it because it has misbehaved or because it has changed IP addresses and the new IP address does not have a long uptime.

> **Comments:**
> **username_0**: I see. This is in line with @username_1's comment. I guess what I was looking for was for the network to have a reliable way to turn down such an attack which is the quick denial of service so that an attack cannot be sustained. Thanks a lot! I'm accepting your answer.  

---

