Add new command line option '-maxoutbound' #4687
Conversation
|
I'm OK with allowing this to be configured, but it should at least be limited to 8. It should not be possible to specify more outbound connections than that. |
|
I agree, I added checks for upper (8) and lower (0) limits for the number of outbound connections. |
|
While you're at it, can you add a big fat comment around the max test that says something to the effect of "This is often changed in the hopes of creating a "hub" node (or similar terminology), for various reasons. However, these reasons are usually misguided and, more often than not, increasing this value has negative effects that were not originally considered. Simply put, if you really think you need to increase this value, please come to #bitcoin-dev on freenode so someone can explain why you're wrong" |
|
Does this work with N=0? that would be useful functionality for some tests. As we're just discussing on IRC there is no way at the moment to not have outbound connections at all (except for -connect with a wrong ip/port, but that's ugly and it will keep trying to connect). |
|
@TheBlueMatt : the proposed option is intended to reduce the number of outgoing connection and as mentioned above this parameter is between 0 and 8 (default is 8). The reason is not to create a "hub" node, but to protect a user from a deanonymisation attack. |
|
@ivanpustogarov I'm sure @TheBlueMatt understands that. He just asks to put a comment about it, so that others reading the code know it. |
|
(and mostly so that others who are going about modifying the code are at least faced with a "thick about what you're doing" note before they do) On August 13, 2014 5:10:16 AM PDT, Pieter Wuille [email protected] wrote:
|
|
I agree, a comment is needed |
|
I added the comment |
|
I don't see a comment describing why setting it to more than 8 is very bad idea? The comment you added is more user documentation than developer. On August 13, 2014 8:04:11 AM PDT, ivanpustogarov [email protected] wrote:
|
|
Ok, I did not understand you correctly |
|
I don't understand why the privacy concern is not more completely addressed by using the existing maxconnections: Both inbound and outbound peers see the transactions we transmit, once connected the protocol is symmetric— and worse, inbound peers are self-selecting. Longer term we'd want to have some better logic about this at relay time instead of changing our connectivity. Having a command to separately reduce outbound connections is perfectly reasonable to me, however. |
|
True, -maxconnections will work. The motivation of the pull request should be changed. |
|
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/p4687_59360b7bfd9ca622aece09755c8f358b96f02312/ for binaries and test log. |
|
I don't see how reducing outbound connections will have any impact on privacy - surely it's the inbound connections that reduce privacy more than the outbound connections. |
There was a problem hiding this comment.
Ok, so why not increase this from 125 to 250?
There was a problem hiding this comment.
That's entirely out of scope here. But 125 is a sensible default
- Lots of consumer routers croak at many TCP connections
- It's easy to run out of file descriptors on some OSes
- There is quite some memory usage per CNode (send buffers, internal administration)
- There's nothing preventing you from already passing
-maxconnections=250, if the above problems don't apply (as much) to you
|
Should the GUI signal bar also get updated to match the different max outbound (ie keep the logic of "if not accepting outbound, you get up to the last bar, but not the last one") |
There was a problem hiding this comment.
All the 8s should be replaced with DEFAULT_OUTBOUND then.
There was a problem hiding this comment.
@Diapolo No. 8 is the absolute maximum for outbound, not just the default!
|
Rebase please? |
ivanpustogarov
force-pushed
the
options-maxoutboundconnections
branch
from
59360b7 to
86c61e9
Compare
While there is a command line option to limit the total number of
connections ('-maxconnections'), the number of outbound connections is
controlled by a hard-coded constant 'MAX_OUTBOUND_CONNECTIONS=8'.
This number (8) of connections has a bad impact on user's privacy. Let's
keep the default number of outbound connections (of 8) but allow a user
to have more privacy by reducing this number (to 3 or 4) using
'-maxoutbound'.
Explanation: transactions that are first relayed by these 8 entry nodes
most probably belong to the same user. In fact, even a subset of these 8
entry nodes can uniquely identify a user. There is a cheap way for an
attacker to learn this set of entry nodes and the user's public IP and
use it to deanonymize the user (note that users by default advertise
their public IP addresses even when behind NAT). If the user has 3-4
outbound connection the success rate of the attack becomes quite low.
ivanpustogarov
force-pushed
the
options-maxoutboundconnections
branch
from
86c61e9 to
54abb7b
Compare
|
This feature would fit in rather nicely with the -whiteconnections option I added: #5288 Is this pull request still being worked on now? If not, would like to take it over, since it seems rather useful to have (and would help me better throttle Bitcoin to cope with my slow connection). |
|
It's not. Sure. |
|
@Krellan Feel free to take it over. Closing this one (inactivity). |
ghost
mentioned this pull request
9 participants
While there is a command line option to limit the total number of
connections ('-maxconnections'), the number of outbound connections is
controlled by a hard-coded constant 'MAX_OUTBOUND_CONNECTIONS=8'.
This number (8) of connections has a bad impact on user's privacy. Let's
keep the default number of outbound connections (of 8) but allow a user
to have more privacy by reducing this number (to 3 or 4) using
'-maxoutbound'.
Explanation: transactions that are first relayed by these 8 entry nodes
most probably belong to the same user. In fact, even a subset of these 8
entry nodes can uniquely identify a user. There is a cheap way for an
attacker to learn this set of entry nodes and the user's public IP and
use it to deanonymize the user (note that users by default advertise
their public IP addresses even when behind NAT). If the user has 3-4
outbound connection the success rate of the attack becomes quite low.
Some details are here: https://www.cryptolux.org/index.php/Bitcoin