Bitcoin Forum

I've been running core for years on mainchain and testnet.

I just upgraded from 18 to 0.19.1. I noticed my inbound connections were far lower than normal. Usually was in the hundreds and was just in the 10-20 range after 15 minutes back up, and I noticed an inordinate number of peers connecting and going immediately away.
So I read NODE_BLOOM is off by default now in 0.19+ versions which is why my connection counts are down.

I never really minded it before,  I did had to set my firewall's bandwidth manager to make that traffic low priority because it would use alot of my upload bandwidth and cause other things I really need to be slow, which worked just fine for years, that's what the bandwidth manger feature in my firewall is for, let it use it when nothing else wants to, when something important comes along, choke off the bitcoin node traffic. Worked fine for years.

 I'm fairly technical generally but not really up on the technical details of bitcoin clients and code. From reading the release notes the developers kinda make out NODE_BLOOM as evil. Apparently this was accounting for a large percentage of my node's traffic, so are these evil? Are these just other peers taking more than their giving? Are clients wanting to use NODE_BLOOM doing things incorrectly and shouldn't be doing it?  Should I turn it back on? I turned it back on for testnet.

What's the general consensus on nodes who allow or don't allow NODE_BLOOM?

Bloom filter is a feature introduced in BIP37 which focuses on allowing SPV clients or lightclients to be able to obtain the transactions relating to their addresses without a lot of bandwidth usage. It is not an evil implementation at all but it's just that at that point in time, it was the most suitable way for lightweight clients to obtain their information.

When the reference client obtains a set of bloom filters, it would try to scour through the blockchain to find transactions relating to the address and/or UTXO and send it back to the light client. While this is not exactly resource intensive, it would be a potential attack vector for DOS attacks. To help to phase out BIP37 to pave the way for better implementations, the developers has made it an option for users to disable it to reduce their resource usage and they predict the current SPV clients can still function with the current number of nodes with bloom filter.

Peers connecting to you for bloom filters are not necessarily bad but they do not contribute to the network as any other full node would. You would still be helping SPV clients if you choose to allow peers to submit bloom filters.

To complete the first answer, here a PoC; https://github.com/petertodd/bloom-io-attack.

Up to you, really. I personally run the client on my laptop with `-peerbloomfilters` for some reasons, but that's the only one.

For some definition of "easy". edit: see https://bitcointalk.org/index.php?topic=5240259.msg54225326#msg54225326
But still the reason for their deprecation is the risk of DOS, not advising against their use because of the privacy tradeoffs.

Absolutely! The only non-centralised alternative is the very bandwidth-costly BIP157 (aka neutrino) used by Lightning Lab's mobile wallet and Wasabi.
The most used one is surely "Android Bitcoin Wallet".

Apparently there are, because if I turn them on my "inbound" connections go from 20-50 to 120-200 . And over a typical days time I would serve out 30-40GB where in the last 24hrs on 0.19.1 with them off i've served 8gb.

After reading some of the responses and their material and other info about it, I think I now kinda get it. While the bip allows the client to be lite, it's heavy on the node's it's attaching to because it asks for more than it needs in an attempt to obfuscate which stuff it really wants to know about. So, taking more than it gives...to the community, in a sense. And the whole reason it asks for more is rather moot because if a node wanted to, it can figure out what ithe client is really after anyway.

Correct me if I'm wrong, but after reading some material on it, the privacy risk seems to be the clients and not mine, the risk is if I was running a node with intent to do something with that info the SPV clients expose to me.

I've just read certain things and opinions, like:
 - your not a full node unless your offering bloom filters.
 - CUtting it off is playing government it's an allowed bip and not offering it is attempting to encourage others behavior, aka, trying to tell them what to do
 - your node will be overrun with DOS attacks

stuff like that. Surely, it's up to me. Was just trying to edumacate myself to the best of my ability to decide. I appreciate the education and responses!

I believe you must have bloom on your node if you use Bisq

That sounds like a DOS attack, to be honest.  I usually see weeks pass without a single connection from an actual SPV client,  though there are bunch of shitty spy things that pretend to be them.  It absolutely shouldn't be making remotely that kind of difference.


uh, also, 125 is the maximum connections.

The only issue it exposes you to are DOS attacks and any bugs in that functionality... though bugs seem fairly unlikely at that point.  The DOS attack issues have been exploited in the wild, so for a rarely used and not very useful functionality.

I had upped the max with  -maxconnections=500 a while back. All I can say is I have the upload bandwidth to deal with it and it was managed via myfirewall as low priority so any other traffic would supersede it and choke it off. So I guess I never noticed how much it was using on a constant basis, only every time I looked it was 120+ connections inbound and serving 10's of gb/day.

I cut off mainchain with the bloom, it's now at 61 inbound after 1.5days in that mode and has served 24GB in that time Mabey all those SPV or possible DoS people were blocking out real nodes?
DoS attacks suck. But does seem like it's rather pointless in this context. I dunno, I leave it off for now. Sounds like SPV clients are on the way out anyway in favor of other lite methods, might as well show them the door. It's not Gov't, it's just my vote with my node.  :) Plus if I can use the bandwidth to serve other nodes thats serve the community, that's a better use of the bandwidth IMHO.

if that's true then SPV clients are on a dark path. using methods such as what Electrum protocol provides is cool and convenient but it has a very big flaw: it lacks privacy. and that's something bloom filters could improve.
i feel like this is another feature that was (partially) removed from core just because it has flaws, instead of being improved.


i believe Breadwallet, mSIGNA and BISQ and a couple of others are relying on bloom filters.

IIRC, there were some noise about how deprecation of bloom filter could be detrimental to the SPV wallets. I concur with their statement that given the current node distribution, there should still be sufficient nodes available for SPV client for now. I believe that bloom filter have some fundamental privacy issues that can't exactly be solved. Efforts has been made to introduce new standards such as BIP157 and 158. I think it's still a good direction in forcing SPV wallets to be receptive in changing out bloom filter for something better.

BIP37 has zero privacy.  https://en.bitcoin.it/wiki/BIP37_privacy_problems   Electrum also has extremely poor privacy but at least its upfront about that and actually works well, the BIP37 approach is pretty much the worst of all worlds-- it takes forever to scan the chain plus it identifies and links your addresses and it makes nodes DOS attack vulnerable in the process.

I think no, that would mean that enabling the NODE_BLOOM service bit on a given node would subject that node to the BIP 37 DOS risk even if the operator only wished to serve BIP 157 filters to SPV clients (and BIP 157 filters are not bloom filters anyway)