Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Make whitebind/whitelist permissions more flexible #16248
In 0.19, bloom filter will be disabled by default. I tried to make a PR to enable bloom filter for whitelisted peers regardless of
Bloom filter have non existent privacy and server can omit filter's matches. However, both problems are completely irrelevant when you connect to your own node. If you connect to your own node, bloom filters are the most bandwidth efficient way to synchronize your light client without the need of some middleware like Electrum.
It is also a superior alternative to BIP157 as it does not require to maintain an additional index and it would work well on pruned nodes.
When I attempted to allow bloom filters for whitelisted peer, my proposal has been NACKed in favor of a more flexible approach which should allow node operator to set fine grained permissions instead of a global
Doing so will also make follow up idea very easy to implement in a backward compatible way.
The PR propose a new format for
The following permissions exists:
If no permissions are specified,
When we receive an inbound connection, we calculate the effective permissions for this peer by fetching the permissions granted from
To keep backward compatibility, if no permissions are specified in
Follow up idea
Based on this PR, other changes become quite easy to code in a trivially review-able, backward compatible way:
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.
26 times, most recently
Jun 20, 2019
Concept ACK. Maybe tag with 0.19 given #16152?
I think the simple
I suggest that we keep the
The parser looks simple enough to me (and I don't write parsers for a living).
I'm not a fan of an extra config file, partially because JSON is tedious to write. If you have to use some tool to produce config files, then you might as well use the RPC.
Getting a bunch of compiler warnings on macOS for the tests:
In QT too:
I get a
Almost, still get this one:
The first commit is rather large. Consider introducing
There are a bunch of existing functional tests that use
@Sjors if you look the C++ tests I am testing it very strongly with all kind of edge cases. It does not make sense to test the parse flag in isolation as it is not used in the code that way.
I should have fixed the warnings now. I am unsure though because I am developing on windows and msvc says it is good.