Bitcoin Forum
December 04, 2016, 08:11:55 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: How many peers to connect to  (Read 1397 times)
brian_armstrong
Newbie
*
Offline Offline

Activity: 29


View Profile
December 27, 2011, 09:06:20 AM
 #1

From reading this: https://en.bitcoin.it/wiki/Running_Bitcoin?utm_source=lasindias.info/blog

It looks like the official client by default connects to up to 125 peers.  I was surprised by how high this was but maybe I'm not understanding the overheard.

For example, does this mean each transaction received has to be relayed to (potentially) 125 peers?  When doing the initial chain download, does the client ever step on it's own toes, for example by doing onblocks to lots of different peers, and then getting lots of redundant inventory messages?

Just trying to understand all the performance implications for another client I'm working on.  Also, what would change if you only connected to say....8 peers?

Thanks!
1480839115
Hero Member
*
Offline Offline

Posts: 1480839115

View Profile Personal Message (Offline)

Ignore
1480839115
Reply with quote  #2

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

Posts: 1480839115

View Profile Personal Message (Offline)

Ignore
1480839115
Reply with quote  #2

1480839115
Report to moderator
bitlane
Internet detective
Sr. Member
****
Offline Offline

Activity: 462


I heart thebaron


View Profile
December 29, 2011, 08:32:51 PM
 #2

It looks like the official client by default connects to up to 125 peers.
I am by no means a coder and barely understand Bitcoin to begin with, but isn't the 125 limit you are referring to, the RPC connection limit ? ...like, mining & info requests and not necessarily network nodes/peers etc ?

Forgive me for sounding so stupid......but it is something that I looked into and for solo mining with multiple machines pointed at the same local network wallet, I actually increased the connection limit as well as included the RPC timeout value to my bitcoin.conf file.

Perhaps it made no change for performance (for me) but I have generated coins solo mining and do not get the 'Pool 0 not providing work fast enough' message in my miners anymore, so I assumed that whatever I did, HELPED. I just assumed I created myself more available RPC connections as well as a timeout to keep me from running out of sockets on my Windows server that runs Bitcoind for all my local miners, hence the message about not providing work fast enough, now gone.

kokjo
Legendary
*
Offline Offline

Activity: 1050

You are WRONG!


View Profile
December 30, 2011, 04:06:40 PM
 #3

From reading this: https://en.bitcoin.it/wiki/Running_Bitcoin?utm_source=lasindias.info/blog

It looks like the official client by default connects to up to 125 peers.  I was surprised by how high this was but maybe I'm not understanding the overheard.

For example, does this mean each transaction received has to be relayed to (potentially) 125 peers?  When doing the initial chain download, does the client ever step on it's own toes, for example by doing onblocks to lots of different peers, and then getting lots of redundant inventory messages?

Just trying to understand all the performance implications for another client I'm working on.  Also, what would change if you only connected to say....8 peers?

Thanks!

no the client does not step on its own toes, see: https://en.bitcoin.it/wiki/Protocol_specification#inv

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
jimrandomh
Jr. Member
*
Offline Offline

Activity: 43


View Profile
December 30, 2011, 08:30:22 PM
 #4

The reason for connecting to many peers is for security. If you connect to only a few peers, or you design your peer-finding system poorly, an attacker might arrange things so that all of your connections were to computers that he controlled. Then he'd be able to hide published blocks from you, and to send blocks and transactions to you that don't reach the rest of the network. This would allow him to mount something sort of like a 51% attack, but with much less computing power.

In other words, the peer-finding algorithm is security-critical, so you shouldn't mess with it unless you know exactly what you're doing. The transaction and block relaying algorithms are, too, by the way; if a large fraction of the network stopped relaying because they wanted to be lightweight, then 125 connections might not be enough to stay safe anymore.
kokjo
Legendary
*
Offline Offline

Activity: 1050

You are WRONG!


View Profile
December 30, 2011, 08:50:21 PM
 #5

The reason for connecting to many peers is for security. If you connect to only a few peers, or you design your peer-finding system poorly, an attacker might arrange things so that all of your connections were to computers that he controlled. Then he'd be able to hide published blocks from you, and to send blocks and transactions to you that don't reach the rest of the network. This would allow him to mount something sort of like a 51% attack, but with much less computing power.

In other words, the peer-finding algorithm is security-critical, so you shouldn't mess with it unless you know exactly what you're doing. The transaction and block relaying algorithms are, too, by the way; if a large fraction of the network stopped relaying because they wanted to be lightweight, then 125 connections might not be enough to stay safe anymore.
an attacker CAN NOT create block, just because you are outside the network, he still needs a high amount of computing power, to create a block every 10 min, or even 1 at all. and without any block, there will be no confirmations. thrust an attacker CAN NOT perfrom a double spend attack on you.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
jimrandomh
Jr. Member
*
Offline Offline

Activity: 43


View Profile
December 31, 2011, 05:52:28 PM
 #6

Yes, creating blocks still takes lots of computing power, but isolating someone from the network means it's no longer a race; if it takes a day to make six block, then after a day, the victim (which may be an automated process) will think they have six confirmations. It does still cost 50BTC of computing power per confirmation on the forked part of the chain, since those blocks won't be built on. This is a good enough deterrent in most cases, but it's not as strong a defense as requiring 51% is. Ordinarily this attack wouldn't work at all, even if you spent hashing power on it, because during that time the target would almost certainly hear about the main chain, which is longer.

Actually, there might already be some mechanisms in place to notice and warn if the observed block generation rate drops precipitously, which this attack would cause. I'm not sure about that; if there aren't, there should be.
kokjo
Legendary
*
Offline Offline

Activity: 1050

You are WRONG!


View Profile
December 31, 2011, 05:54:30 PM
 #7

Yes, creating blocks still takes lots of computing power, but isolating someone from the network means it's no longer a race; if it takes a day to make six block, then after a day, the victim (which may be an automated process) will think they have six confirmations. It does still cost 50BTC of computing power per confirmation on the forked part of the chain, since those blocks won't be built on. This is a good enough deterrent in most cases, but it's not as strong a defense as requiring 51% is. Ordinarily this attack wouldn't work at all, even if you spent hashing power on it, because during that time the target would almost certainly hear about the main chain, which is longer.

Actually, there might already be some mechanisms in place to notice and warn if the observed block generation rate drops precipitously, which this attack would cause. I'm not sure about that; if there aren't, there should be.
don't you think that the user, will notice something is wrong? he got bitcoinmonitor and blockexplore. your attack will not work.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
grue
Global Moderator
Legendary
*
Offline Offline

Activity: 1932



View Profile
December 31, 2011, 07:51:41 PM
 #8

Yes, creating blocks still takes lots of computing power, but isolating someone from the network means it's no longer a race; if it takes a day to make six block, then after a day, the victim (which may be an automated process) will think they have six confirmations. It does still cost 50BTC of computing power per confirmation on the forked part of the chain, since those blocks won't be built on. This is a good enough deterrent in most cases, but it's not as strong a defense as requiring 51% is. Ordinarily this attack wouldn't work at all, even if you spent hashing power on it, because during that time the target would almost certainly hear about the main chain, which is longer.

Actually, there might already be some mechanisms in place to notice and warn if the observed block generation rate drops precipitously, which this attack would cause. I'm not sure about that; if there aren't, there should be.
don't you think that the user, will notice something is wrong? he got bitcoinmonitor and blockexplore. your attack will not work.
yeah, like the average user will stare at blockexplorer constantly

It is pitch black. You are likely to be eaten by a grue.

Tired of annoying signature ads? Ad block for signatures
kokjo
Legendary
*
Offline Offline

Activity: 1050

You are WRONG!


View Profile
December 31, 2011, 07:53:58 PM
 #9

Yes, creating blocks still takes lots of computing power, but isolating someone from the network means it's no longer a race; if it takes a day to make six block, then after a day, the victim (which may be an automated process) will think they have six confirmations. It does still cost 50BTC of computing power per confirmation on the forked part of the chain, since those blocks won't be built on. This is a good enough deterrent in most cases, but it's not as strong a defense as requiring 51% is. Ordinarily this attack wouldn't work at all, even if you spent hashing power on it, because during that time the target would almost certainly hear about the main chain, which is longer.

Actually, there might already be some mechanisms in place to notice and warn if the observed block generation rate drops precipitously, which this attack would cause. I'm not sure about that; if there aren't, there should be.
don't you think that the user, will notice something is wrong? he got bitcoinmonitor and blockexplore. your attack will not work.
yeah, like the average user will stare at blockexplorer constantly
yeah, like the user is waiting ~4hour for just one confirmation.

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
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!