Implement NODE_BLOOM, ability for nodes to disable serving BIP37 SPV clients. #6578

1. 
   evGUzQIEQaL4 commented at 11:30 pm on August 20, 2015: none

   High reliability nodes running mining pools and merchants have no need to serve BIP37 bloom filters. Implementing the unnamed NODE_BLOOM BIP will allow nodes to display their willingness (or not) to serve SPV clients in this manor, allowing BIP37 functions to be disabled protects from major denial of service problems. Not all nodes today support BIP37 and it is a hindrance that there is no signaling possible for it.

   http://sourceforge.net/p/bitcoin/mailman/message/31298904/

   The service identifier would need to be altered from the original specification by @petertodd as the specified bit has since been used by NODE_GETUTXOS in another client.

2. evGUzQIEQaL4 renamed this:
   Implement NODE_BLOOM, ability for nodes to disable serving SPV clients.
   Implement NODE_BLOOM, ability for nodes to disable serving BIP37 SPV clients.
   on Aug 20, 2015
3. 
   petertodd commented at 0:31 am on August 21, 2015: contributor

   Note that since the last time NODE_BLOOM was proposed, the landcape for (lite-)SPV clients has changed significantly in a few key ways:

   1. @mikehearn’s Cartographer seed protocol has been created and deployed in production to allow (lite-)SPV clients to find nodes supporting arbitrary service bits, notable NODE_GETUTXOs.

   2. Bloom filter usage has declined significantly, as lite-SPV clients are moving towards using centralized, trusted, servers run by the wallet authors. For instance Mycelium, GreenBits, AirBitz, and Electrum all fall in this category.

   3. Bloom filters have been found to have severe privacy issues, offering essentially no privacy at all. Under many threat models a small number of trusted servers pose less privacy security risk than connecting to random, sybil-attackable, peers using unencrypted connections and giving those peers very accurate wallet contents information.

   4. Finally, Bloom filters still have unsolved DoS attack issues, that will get significantly worse under upcoming blocksize increase proposals.

   Re: service bit identifier, I’d just pick 1«3

4. 
   dcousens commented at 0:38 am on August 21, 2015: contributor

   So can we make serving them optional?
5. 
   petertodd commented at 0:41 am on August 21, 2015: contributor

   @dcousens That’s exactly the idea, which in turn gives a clean upgrade path as better solutions are found in the future.
6. 
   dcousens commented at 0:45 am on August 21, 2015: contributor

   Also, what is the contents of http://sourceforge.net/p/bitcoin/mailman/message/31298904/ for those of us that have sourceforge.net blocked? (Is there a link to it anywhere else)
7. 
   petertodd commented at 0:47 am on August 21, 2015: contributor

   @dcousens Here you go: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-August/003158.html
8. 
   petertodd commented at 0:49 am on August 21, 2015: contributor

   Incidentally, in case @evGUzQIEQaL4 is actually Mike and intends to troll this issue on reddit, I’ll let someone else actually make a pull-req implementing this, because one of Mike’s favorite schticks is “OMG THE CORE DEVS HATE SPV!!!” - never mind that I spent about 50% of the past year’s billable hours working on figuring out how to add SPV to colored coin tech…
9. 
   evGUzQIEQaL4 commented at 1:00 am on August 21, 2015: none

   @petertodd Hate SPV is probably too strong, dislike not having an option in the core client for an incredibly intensive and DoS prone feature is a better description. A number of nodes on the network (all pseudonode and bitcoin-ruby instances for example) already flat out ignore filterload commands, which happens to denial of service attack BIP37 wallets because they just don’t expect that. NODE_BLOOM just allows nodes to inform BIP37 clients that their response to certain P2P commands just isn’t going to arrive. BitcoinJ already has a hardcoded HTTP seed which only gives out peers responding to NODE_GETUTXOS, I don’t imagine there will be any problem adding a check there for another bit.
10. 
    petertodd commented at 1:08 am on August 21, 2015: contributor

    @evGUzQIEQaL4 Well, like I say, Mike frequently lies about this in public.

    Oh, is that HTTP seed - the Cartographer protocol right? - implemented by default in BitcoinJ right now? That certainly negates most objections - lots of GETUTXOs nodes to go around these days, and I believe Gavin has said a few times that he supports separating the various functionalities of different types of nodes.

11. 
    evGUzQIEQaL4 commented at 1:11 am on August 21, 2015: none

    @petertodd Yes, it’s in BitcoinJ (and has been for half a year), even preferred over DNS seeds in some circumstances. I don’t imagine there would be any reason for complaint about advertising what nodes already do by setting that bit. There’s room for adding a message on startup about how the node is by default graciously serving BIP37 at their cost to prompt users who wish to disable it to do so.

    https://github.com/bitcoinj/bitcoinj/blob/6f03669fbd6c368961a25dfd772751d1ca2a1b5b/core/src/main/java/org/bitcoinj/params/MainNetParams.java#L80-L88

12. 
    petertodd commented at 1:22 am on August 21, 2015: contributor

    @evGUzQIEQaL4 Looks good. Interesting that there is no similar seed for testnet3: https://github.com/bitcoinj/bitcoinj/blob/6f03669fbd6c368961a25dfd772751d1ca2a1b5b/core/src/main/java/org/bitcoinj/params/TestNet3Params.java @mikehearn How do people do GETUTXO testing on testnet?

    Not a big issue; I’m quite happy to add appropriate code to my DNS seed to ensure only NODE_GETUTXO nodes are returned.

13. 
    evGUzQIEQaL4 commented at 3:17 am on August 21, 2015: none

    Protocol version will also need to deviate slightly from the BIP proposal, 70002 or 70003 would collide with the XT attempted fork which sets version 70010. Perhaps where protocol > 70037 NODE_BLOOM would be set for nodes which allow BIP37 requests, with any filteradd, filterload or filterclear message to a node without NODE_BLOOM set resulting in a DoS score increment?
14. 
    TheBlueMatt commented at 4:20 am on August 21, 2015: member

    See branch at https://github.com/TheBlueMatt/bitcoin/tree/bloom. Will create a pull request after posting a BIP.
15. 
    evGUzQIEQaL4 commented at 4:57 am on August 21, 2015: none

    Closing, discussion should move to implementation at #6579.
16. evGUzQIEQaL4 closed this on Aug 21, 2015

    ---

17. MarcoFalke locked this on Sep 8, 2021

Contributors
evGUzQIEQaL4 petertodd dcousens TheBlueMatt