Bitcoin Forum
December 09, 2016, 05:51:43 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Handling Bad Peers and Net Neutrality  (Read 966 times)
Keyur @ Camp BX
Sr. Member
****
Offline Offline

Activity: 300



View Profile WWW
May 25, 2011, 08:01:19 AM
 #1


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!



Please stay tuned to our news and announcements feeds at:
Twitter: https://twitter.com/CampBX
Facebook: https://facebook.com/CampBX
1481305903
Hero Member
*
Offline Offline

Posts: 1481305903

View Profile Personal Message (Offline)

Ignore
1481305903
Reply with quote  #2

1481305903
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481305903
Hero Member
*
Offline Offline

Posts: 1481305903

View Profile Personal Message (Offline)

Ignore
1481305903
Reply with quote  #2

1481305903
Report to moderator
1481305903
Hero Member
*
Offline Offline

Posts: 1481305903

View Profile Personal Message (Offline)

Ignore
1481305903
Reply with quote  #2

1481305903
Report to moderator
1481305903
Hero Member
*
Offline Offline

Posts: 1481305903

View Profile Personal Message (Offline)

Ignore
1481305903
Reply with quote  #2

1481305903
Report to moderator
MacRohard
Member
**
Offline Offline

Activity: 103


View Profile
May 25, 2011, 01:26:23 PM
 #2


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.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
May 25, 2011, 08:28:10 PM
 #3

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.

How often do you get the chance to work on a potentially world-changing project?
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
May 25, 2011, 08:42:21 PM
 #4

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.
Keyur @ Camp BX
Sr. Member
****
Offline Offline

Activity: 300



View Profile WWW
May 25, 2011, 11:19:27 PM
 #5

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.




Please stay tuned to our news and announcements feeds at:
Twitter: https://twitter.com/CampBX
Facebook: https://facebook.com/CampBX
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!