<p>So I guess the answer is "Yes, nodes accept Bloom filters because filtering does not make existing DoS attacks any worse nor do they introduce any new DoS attacks."</p>

CC BY-SA 3.0
2016-07-27T23:54:48.457Z
2016-07-27T23:54:48.457Z
Alin Tomescu
<p>Could someone explain why so many Bitcoin nodes allow Bloom filtering given that DoS attacks exist <a href="https://github.com/bitcoin/bitcoin/issues/6578" rel="nofollow">[1]</a>, <a href="https://github.com/petertodd/bloom-io-attack" rel="nofollow">[2]</a> for such nodes?</p>

<p>According to <a href="https://bitnodes.21.co/nodes/1468872008/?q=node_bloom" rel="nofollow">bitnodes.21.co</a>, right now 3879 nodes out of the total of 5515 Bitcoin nodes have Bloom filtering enabled.</p>

<p>Is it that these DoS attacks are not made any worse by Bloom filtering, as documented <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010624.html" rel="nofollow">here</a> by Mike Hearn? I quote:</p>

<blockquote>
  <p>Thus you can easily trigger exactly the same DoS attack by just using
  regular getdata requests on large blocks over and over. You don't need
  Bloom filtering. If you don't want to actually download the blocks
  just don't TCP ACK the packets and then FIN after a few seconds ....
  the data will all have been loaded and be sitting in the send buffers.</p>
  
  <p>So even if I refine the attack and find a way to actually deny service
  to someone, the fix would have to apply to regular non-filtered block
  fetches too, which cannot be disabled.</p>
</blockquote>

CC BY-SA 3.0
2016-07-19T04:51:53.520Z
Yeah looks like after reading Hearn's comments that the underlying issue is the fact that a client is able to request a bitcoin node to do some serious work by sending getdata requests. So the DoS vector isn't really in the bloom filter code as much as it is in the fact that bitcoin nodes allow anonymous connections to cause them to generate large work loads repeatedly. I have no idea if anyone's fixed this underlying problem.
Brandon
CC BY-SA 3.0
2016-07-19T04:58:08.080Z
Thanks! I don't think it's fixable: New nodes who join need to send `getdata` requests to old nodes to download the blockchain.
Alin Tomescu
CC BY-SA 3.0
2016-07-19T05:06:05.660Z
No problem. Thank you for asking the question as it informed me about a potential problem I was unaware. It seems to me this could be fixed by simply rate limiting the speed at which getdata requests are handled, but perhaps there are complexities I do not understand. Hearn says you send getdata requests over and over, so I would think the node should have some defensive logic here.
Brandon
<attack><bip37-bloom-filter>
70% of nodes accept Bloom filters, despite DoS attack vector?
Alin Tomescu
# 70% of nodes accept Bloom filters, despite DoS attack vector?

(Asked by: username_0 on 2016-07-18)

Could someone explain why so many Bitcoin nodes allow Bloom filtering given that DoS attacks exist [[1]](https://github.com/bitcoin/bitcoin/issues/6578), [[2]](https://github.com/petertodd/bloom-io-attack) for such nodes?

According to [bitnodes.21.co](https://bitnodes.21.co/nodes/1468872008/?q=node_bloom), right now 3879 nodes out of the total of 5515 Bitcoin nodes have Bloom filtering enabled.

Is it that these DoS attacks are not made any worse by Bloom filtering, as documented [here](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010624.html) by Mike Hearn? I quote:

> Thus you can easily trigger exactly the same DoS attack by just using
> regular getdata requests on large blocks over and over. You don't need
> Bloom filtering. If you don't want to actually download the blocks
> just don't TCP ACK the packets and then FIN after a few seconds ....
> the data will all have been loaded and be sitting in the send buffers.
>
> So even if I refine the attack and find a way to actually deny service
> to someone, the fix would have to apply to regular non-filtered block
> fetches too, which cannot be disabled.

**Tags:** attack, bip37-bloom-filter

> **Comments:**
> **username_1**: Yeah looks like after reading Hearn's comments that the underlying issue is the fact that a client is able to request a bitcoin node to do some serious work by sending getdata requests. So the DoS vector isn't really in the bloom filter code as much as it is in the fact that bitcoin nodes allow anonymous connections to cause them to generate large work loads repeatedly. I have no idea if anyone's fixed this underlying problem.  
> **username_0**: Thanks! I don't think it's fixable: New nodes who join need to send `getdata` requests to old nodes to download the blockchain.  
> **username_1**: No problem. Thank you for asking the question as it informed me about a potential problem I was unaware. It seems to me this could be fixed by simply rate limiting the speed at which getdata requests are handled, but perhaps there are complexities I do not understand. Hearn says you send getdata requests over and over, so I would think the node should have some defensive logic here.  

---

## 1 answers

### Answer by username_0 on 2016-07-27. Score: 1 | Accepted answer

So I guess the answer is "Yes, nodes accept Bloom filters because filtering does not make existing DoS attacks any worse nor do they introduce any new DoS attacks."


---

