How many peers to connect to | Bitcointalksearch.org

kokjo

legendary

Activity: 1050

Merit: 1000

You are WRONG!

Quote from: grue on December 31, 2011, 02:51:41 PM

Quote from: kokjo on December 31, 2011, 12:54:30 PM

Quote from: jimrandomh on December 31, 2011, 12:52:28 PM

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.

grue

legendary

Activity: 2058

Merit: 1452

Quote from: kokjo on December 31, 2011, 12:54:30 PM

Quote from: jimrandomh on December 31, 2011, 12:52:28 PM

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

kokjo

legendary

Activity: 1050

Merit: 1000

You are WRONG!

Quote from: jimrandomh on December 31, 2011, 12:52:28 PM

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.

jimrandomh

newbie

Activity: 43

Merit: 0

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

Activity: 1050

Merit: 1000

You are WRONG!

Quote from: jimrandomh on December 30, 2011, 03:30:22 PM

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.

jimrandomh

newbie

Activity: 43

Merit: 0

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

Activity: 1050

Merit: 1000

You are WRONG!

Quote from: brian_armstrong on December 27, 2011, 04:06:20 AM

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

bitlane

sr. member

Activity: 462

Merit: 250

I heart thebaron

Quote from: brian_armstrong on December 27, 2011, 04:06:20 AM

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.

brian_armstrong

newbie

Activity: 29

Merit: 0

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!

Topic: How many peers to connect to (Read 1612 times)