Bitcoin Forum
March 28, 2024, 06:44:07 PM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How many peers to connect to  (Read 1585 times)
brian_armstrong (OP)
Newbie
*
Offline Offline

Activity: 29
Merit: 0


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

Posts: 1711651447

View Profile Personal Message (Offline)

Ignore
1711651447
Reply with quote  #2

1711651447
Report to moderator
TalkImg was created especially for hosting images on bitcointalk.org: try it next time you want to post an image
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1711651447
Hero Member
*
Offline Offline

Posts: 1711651447

View Profile Personal Message (Offline)

Ignore
1711651447
Reply with quote  #2

1711651447
Report to moderator
1711651447
Hero Member
*
Offline Offline

Posts: 1711651447

View Profile Personal Message (Offline)

Ignore
1711651447
Reply with quote  #2

1711651447
Report to moderator
1711651447
Hero Member
*
Offline Offline

Posts: 1711651447

View Profile Personal Message (Offline)

Ignore
1711651447
Reply with quote  #2

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

Activity: 462
Merit: 250


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

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
Newbie
*
Offline Offline

Activity: 43
Merit: 0


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

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
Newbie
*
Offline Offline

Activity: 43
Merit: 0


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

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
Legendary
*
Offline Offline

Activity: 2058
Merit: 1431



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.

Adblock for annoying signature ads | Enhanced Merit UI
kokjo
Legendary
*
Offline Offline

Activity: 1050
Merit: 1000

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:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!