Handling Bad Peers and Net Neutrality

Keyur @ Camp BX

sr. member

Activity: 299

Merit: 250

Quote from: Gavin Andresen on May 25, 2011, 03: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.

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.

Mike Hearn

legendary

Activity: 1526

Merit: 1134

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.

Gavin Andresen

legendary

Activity: 1652

Merit: 2301

Chief Scientist

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.

MacRohard

full member

Activity: 212

Merit: 100

Quote from: Keyur @ Camp BX on May 25, 2011, 03: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:

Use SSL connections
Randomizing ports at start-up
Populating SSL connect descriptors as "Apache" and "Firefox / Internet Explorer"

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.

Keyur @ Camp BX

sr. member

Activity: 299

Merit: 250

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:

Use SSL connections
Randomizing ports at start-up
Populating SSL connect descriptors as "Apache" and "Firefox / Internet Explorer"

Thank you!

Topic: Handling Bad Peers and Net Neutrality (Read 1223 times)