Bitcoin Forum
November 18, 2017, 05:07:43 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Handling Bad Peers and Net Neutrality  (Read 1065 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
1510981663
Hero Member
*
Offline Offline

Posts: 1510981663

View Profile Personal Message (Offline)

Ignore
1510981663
Reply with quote  #2

1510981663
Report to moderator
Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1510981663
Hero Member
*
Offline Offline

Posts: 1510981663

View Profile Personal Message (Offline)

Ignore
1510981663
Reply with quote  #2

1510981663
Report to moderator
1510981663
Hero Member
*
Offline Offline

Posts: 1510981663

View Profile Personal Message (Offline)

Ignore
1510981663
Reply with quote  #2

1510981663
Report to moderator
1510981663
Hero Member
*
Offline Offline

Posts: 1510981663

View Profile Personal Message (Offline)

Ignore
1510981663
Reply with quote  #2

1510981663
Report to moderator
MacRohard
Full Member
***
Offline Offline

Activity: 120


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.

[ CENTRA ] Multi-Blockchain Worldwide Debit Card & Insured Wallet
▞▬▬▬▞▬▬▬▞▬▬▬▞▬▬▬▞▬▬▬▞▬▬▬▚▬▬▬▚▬▬▬▚▬▬▬▚▬▬▬▚▬▬▬▚
FacebookSlackTwitterGithubMediumANN Thread
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!