|
Title: Handling Bad Peers and Net Neutrality Post by: Keyur @ Camp BX on May 25, 2011, 08:01:19 AM Bad Peers: I ran a few searches across the forum but could not find an answer to this: How does the Bitcoin client handle bad peers (Other than rejecting bad TX and Blocks)? If this functionality is not already built into the client, I would like to suggest this simple approach that frees up connections with bad peers: If PEER_IP sends more than REJECT_THRESHOLD malicious transactions or blocks within past 24 hours, Ban(PEER_IP) for 24 hours. Net Neutrality: Many countries around the world have poor record on net neutrality, with selective blocking and government-run snooping programs. Recent case in point: Egypt. I wholeheartedly throw my newbie support behind Madhatter's recommendations to:
Thank you! Title: Re: Handling Bad Peers and Net Neutrality Post by: MacRohard on May 25, 2011, 01:26:23 PM Bad Peers: I ran a few searches across the forum but could not find an answer to this: How does the Bitcoin client handle bad peers (Other than rejecting bad TX and Blocks)? If this functionality is not already built into the client, I would like to suggest this simple approach that frees up connections with bad peers: If PEER_IP sends more than REJECT_THRESHOLD malicious transactions or blocks within past 24 hours, Ban(PEER_IP) for 24 hours. Net Neutrality: Many countries around the world have poor record on net neutrality, with selective blocking and government-run snooping programs. Recent case in point: Egypt. I wholeheartedly throw my newbie support behind Madhatter's recommendations to:
Thank you! SSL probably isn't useful here since it relies on a trusted certificate (if you include a cert/key with the client it can be extracted, if you don't there's nothing to trust). Obfuscating the bitcoin protocol so that it can't be easily identified might not be a bad idea... then again, it works over tor.. that might be good enough. Title: Re: Handling Bad Peers and Net Neutrality Post by: Gavin Andresen on May 25, 2011, 08:28:10 PM Bad peer code that drops the connection and refuses reconnection seems like a good denial-of-service prevention measure.
My only hesitation is accidentally causing a network (and, therefore, block-chain) split if "bad" turns out to be "my peer is running a newer version of the protocol and is accidentally sending me messages I don't understand." RE: net neutrality: if you have to worry about your bitcoin traffic being shut down, I think that problem is better solved with TOR or another network proxy solution. Title: Re: Handling Bad Peers and Net Neutrality Post by: Mike Hearn on May 25, 2011, 08:42:21 PM Yeah, temporary dos blocking would be a nice enhancement though there isn't much need for it today.
Probably you'd want to block an IP address (for say 24 hours) if more than 25% of transactions/blocks it sent failed to verify (cpu abuse attack). There might be other things that'd be worth blocking a peer for, but that seems to be the most important. An RPC to automatically reject connections from particular IPs is a good start. Title: Re: Handling Bad Peers and Net Neutrality Post by: Keyur @ Camp BX on May 25, 2011, 11:19:27 PM Bad peer code that drops the connection and refuses reconnection seems like a good denial-of-service prevention measure. My only hesitation is accidentally causing a network (and, therefore, block-chain) split if "bad" turns out to be "my peer is running a newer version of the protocol and is accidentally sending me messages I don't understand." RE: net neutrality: if you have to worry about your bitcoin traffic being shut down, I think that problem is better solved with TOR or another network proxy solution. Thank you Gavin - you know a whole lot more about the internals than I do at this point, so I am sure you and team will think of a couple of ideas for bad-peer blocking. I just wanted to plant the seed for this, because one wasted connection out of 8 can reduce a node's network visibility by up to 12.5% for the worst case scenario. |