Bitcoin Forum
June 24, 2018, 04:05:08 AM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Handling Bad Peers and Net Neutrality  (Read 1068 times)
Keyur @ Camp BX
Sr. Member
****
Offline Offline

Activity: 300
Merit: 250



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
1529813108
Hero Member
*
Offline Offline

Posts: 1529813108

View Profile Personal Message (Offline)

Ignore
1529813108
Reply with quote  #2

1529813108
Report to moderator
Automated Bitcoin Fork Extraction Tool WE DO TOUGH WALLETS: BCH | BTG | BCD | SBTC | UBTC | B2X | BCX | BTF Electrum 2FA, Trezor, Ledger, SegWit, Bech32
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1529813108
Hero Member
*
Offline Offline

Posts: 1529813108

View Profile Personal Message (Offline)

Ignore
1529813108
Reply with quote  #2

1529813108
Report to moderator
1529813108
Hero Member
*
Offline Offline

Posts: 1529813108

View Profile Personal Message (Offline)

Ignore
1529813108
Reply with quote  #2

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

Activity: 222
Merit: 100



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
Merit: 1013


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
Merit: 1005


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
Merit: 250



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!