Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: syn on May 18, 2011, 04:01:33 PM



Title: restricting access to nodes bitcoind talks to
Post by: syn on May 18, 2011, 04:01:33 PM
Is there a way to change a config parameter in bitcoind to give it a limited (trusted) set of hosts it should communicate with?  I've looked around and didn't ind anything obvious.


Title: Re: restricting access to nodes bitcoind talks to
Post by: Matt Corallo on May 18, 2011, 05:59:42 PM
Is there a way to change a config parameter in bitcoind to give it a limited (trusted) set of hosts it should communicate with?  I've looked around and didn't ind anything obvious.
The -connect parameter limits bitcoin to connect only to the node you specify, you can add several -connect's to connect to several nodes.


Title: Re: restricting access to nodes bitcoind talks to
Post by: MoonShadow on May 18, 2011, 06:21:48 PM
Search the forum for the "shy" client.  Someone has already modified the vanilla client to only accept approved connections and never announce it's own IP address.


Title: Re: restricting access to nodes bitcoind talks to
Post by: Matt Corallo on May 18, 2011, 06:25:24 PM
Search the forum for the "shy" client.  Someone has already modified the vanilla client to only accept approved connections and never announce it's own IP address.
That is not at all what the "shy" patch does.  The shy patch only sends its version number to clients it connects to after they send it theirs.  It still connects to IRC, still attempts to make the same 8 outgoing connections to random nodes as every other client, and still listens for incoming connections.  The only goal here is to make bitcoin nodes slightly less DDoS-able.  Also, shy is in git, and I believe also in 0.3.21.


Title: Re: restricting access to nodes bitcoind talks to
Post by: MoonShadow on May 18, 2011, 06:28:33 PM
Search the forum for the "shy" client.  Someone has already modified the vanilla client to only accept approved connections and never announce it's own IP address.
That is not at all what the "shy" patch does.  The shy patch only sends its version number to clients it connects to after they send it theirs.  It still connects to IRC, still attempts to make the same 8 outgoing connections to random nodes as every other client, and still listens for incoming connections.  The only goal here is to make bitcoin nodes slightly less DDoS-able.  Also, shy is in git, and I believe also in 0.3.21.

Thanks for the correction.  Then a "stealth" client is needed, that functions as a dark node unless specificly commanded to connect to a particular peer, or accept a particular peer's requests.  In fact, I want this client, portable on a thumbdrive. 


Title: Re: restricting access to nodes bitcoind talks to
Post by: Gavin Andresen on May 18, 2011, 06:37:14 PM
Then a "stealth" client is needed, that functions as a dark node unless specificly commanded to connect to a particular peer, or accept a particular peer's requests.  In fact, I want this client, portable on a thumbdrive. 

That is exactly what -connect does (if I recall correctly; you might need -connect and -nolisten together).


Title: Re: restricting access to nodes bitcoind talks to
Post by: xf2_org on May 18, 2011, 07:16:14 PM
Then a "stealth" client is needed, that functions as a dark node unless specificly commanded to connect to a particular peer, or accept a particular peer's requests.  In fact, I want this client, portable on a thumbdrive. 

That is exactly what -connect does (if I recall correctly; you might need -connect and -nolisten together).

Correct.  -nolisten disables incoming, and -connect restricts outgoing to -connect-provided whitelist.


Title: Re: restricting access to nodes bitcoind talks to
Post by: MoonShadow on May 18, 2011, 07:42:08 PM
Then a "stealth" client is needed, that functions as a dark node unless specificly commanded to connect to a particular peer, or accept a particular peer's requests.  In fact, I want this client, portable on a thumbdrive. 

That is exactly what -connect does (if I recall correctly; you might need -connect and -nolisten together).

Correct.  -nolisten disables incoming, and -connect restricts outgoing to -connect-provided whitelist.


Perfect.  Thanks guys!