As mentioned here, I believe that there should be no reason to not support bloom filter for whitelisted peers.
There is no protocol more efficient than this, working as well in pruned mode to sync a light client from your own full node without the need of some middleware like Electrum.
Even BIP157 comes short for this usecase as it needlessly waste bandwidth. (and I think BIP157, as implemented now does not work in pruned mode -might be wrong here-)
This was attempted previously in #8587
I think this comment: #8587 (comment) still stands. We should try to reduce the overloading of -whitelist rather than increase it.
--peerbloomfilters=whitelisted-only ?
I think this comment: #8587 (comment) still stands. We should try to reduce the overloading of -whitelist rather than increase it.
I tend to agree.
Do you have a specific use-case for this @NicolasDorier ? If so, I guess it makes sense to be able to whitelist nodes for this functionality. There has been discussion in the past of specific whitelist flags instead of a blanket ‘whitelist’ with ever changing meaning.
@laanwj yes I have. BTCPay Server is exposing a the full node via a whitebound connection behind a Torv3 hidden service, so the whitebind interface can’t be discovered.
I want to make a simple light wallet connecting to this hosted full node (or just slightly modifying Breadwallet to support Tor).
BIP157/full blocks are bad because it consumes lot’s of bandwidth. However, I don’t want to expose NODE_BLOOM services to node which are not whitelisted because of DDoS concerns.
BIP37 is a fine protocol, just terrible privacy wise and as a DDoS vector. But for connecting to your light wallet to your trusted node, this is the best thing in town.
-whitelistbloomfilter=168.0.0.3? Everything else seems to have drawbacks.
We could duplicate both whitebind/whitelist but I think this is not really useful.
I think adding a [flags] per whitelist range (both per bind and per IP range) would be more general, and less cluttering than duplicating the option. It’s also much more flexible than changing the meaning of whitelist throughout the entire daemon.
I do think there is a usecase to offer a peer bloom filter, but not re-relay their consensus invalid transactions.
I agree.
So basically you would Concept ACK for a --whitebindbloomfilter, --whitelistbloomfilter?
I think it makes sense to have it, but at the same time if my peer is in --whitebind --whitelist, I would expect it to be able to use BloomFilter, but not to relay invalid transactions.
Said in another way, is there a scenario where you would like to whitelist a peer, but not let him get bloom filters?
So basically you would Concept ACK for a –whitebindbloomfilter, –whitelistbloomfilter?
I think @laanwj suggested to use -white{bind,list}=bloomfilter${SEPARATOR}${ADDR_PORT}, so that the options are not duplicated in the command line help.
I think @laanwj suggested to use -white{bind,list}=bloomfilter${SEPARATOR}${ADDR_PORT}, so that the options are not duplicated in the command line help.
Yes, ideally I’d like a extensible, flexible mechanism for whitelisting (a set of) peers for special things, instead of a single amorphous “whitelist”.
Adding, say, “bloomfilter” into the option name causes a blowup in number of options in the help if more things get added. So I prefer a syntax that moves the kind of whitelisting to the value instead, like that.
Currently this is based on IP range (-whitelist) or incoming port (-whitebind). Say, in the future when authentication is added these flags could be set based on authenticated identity (maybe the wallet on your phone etc…). Each of these should be able to have a set of flags attached instead of the default.
@laanwj I think this is a good idea.
But still, “the amorphous whitelist” is very useful, please do not remove it, its consequence are very clear: Consider what is whitelisted as friendly (ie, does not want to deanonymise us, or DDoS us)
The fine grained options should be reserved for more specific use case.
If we keep amorphous whitelist/whitebind, then it makes sense to allow Bloom filters for them: What good reason there would be to no allow bloom filter to a friend?
For transaction relay, there is clear good reason: This friend likely does not validate himself the transaction, so we need to validate for him. But for bloom filter?
-whitebind=bloom,forcerelay@127.0.0.1:9999 or similar to say “whitelist anyone who connects to blah for bloom filters and forced relaying” seems plausible to me.
@ajtowns I like your format whitebind=bloom,forcerelay@127.0.0.1:9999. If people seems OK with it, I will work on that.
Syntax being: white{bind,list}=({bloom,forcerelay},@)*IP(:Port)?. This would have the nice benefit of not breaking existing stuff.
Labels
P2P