6

Let's say I have a dedicated server just for my bitcoind and for better reliability and some security reasons I want it to be connected to a much bigger number of nodes than it is willing to do by default (about 40-50).

Providing that I have enough resources, how can I set my bitcoind to keep a specific number of connections to other nodes? Is this possible without recompiling it?

Note: there's a maxconnections option which sets the upper bound, but it doesn't seem bitcoind strives to reach it. Need to kick it off somehow.

knaperek
  • 1,414
  • 9
  • 22

2 Answers2

3

Bitcoind will never make more than 8 outgoing connections. By default, it will allow up to 128 connections (see -maxconnections), but that includes incoming ones.

Available connection slots of fully synchronized nodes are a limited resource on the network, so they shouldn't be wasted. As long as you have enough connections to be sure that at least one is not trying to attack you, you should have enough.

Pieter Wuille
  • 98,249
  • 9
  • 183
  • 287
  • 1
    I'm actually willing to **provide** this scarce resource (fully synced node with available connections) for the public good, but need to instruct my bitcoind to "start the talking" if not enough nodes are taking the initiative. I need to get any new incoming transaction ASAP and look if there's no double spend for my system to accept the payment in a few seconds. Currently I have 90% of my slots unused, if only I could double the number of actively seeking connections (8)... – knaperek Apr 27 '14 at 14:28
  • @knapo: Well, you have the source code, a text editor, and a compiler... – Nate Eldredge Apr 27 '14 at 14:57
  • 2
    TCP connections have one side starting the connection, and another accepting it. If you want more incomig connections, you'll somehow have to convince the network to connect more to you - it's not something you can do directly by initiating it. If you are well reachable for a long time, crawlers will notice you and seed nodes will serve your IP more frequently to others. – Pieter Wuille Apr 27 '14 at 18:25
  • 1
    @NateEldredge: I know, I was asking for another way (see my question). – knaperek Apr 27 '14 at 18:37
  • 1
    @PieterWuille: I thought the same, but the number of connections did not go up after a week of continuous running. I only thought such a "magic" constant (8) could be configurable in a similar way as `maxconnections`, for example. Once I branch off the mainline in order to override this, I'll have to keep it synced with upstream which is a bit inconvenient. That's why I was looking for another way to do this. – knaperek Apr 27 '14 at 18:46
  • There is no point in wanting more than 8 outgoing connections, and how many others connect to you depends on them. – Pieter Wuille Apr 27 '14 at 21:21
  • It's clear to me that I can't force others to connect to me, but instead I need to be active - that's exactly why I asked this question in the first place. I'd argue about the point of having more than 8 outgoing connections though. I get it that it could potentially be misused by an attacker (wasting network resources), but skipping it from settings will not prevent this. If I can do the fork to solve this problem, attackers surely can as well. – knaperek Apr 28 '14 at 09:04
  • I'm not trying to stop attackers. Those will always exist, and I'm sure we can deal with them. I'm trying to prevent people from thinking that more connections is beneficial to them. – Pieter Wuille Apr 28 '14 at 11:42
  • 2
    Well, I suppose the defaults are suitable for average-grade machine. If I have a dedicated machine with 1Gbps unlimited bandwidth, powerful CPU and SSD drive, I want to make the best out of it. So tweaking some settings sounds only logical. And it's a win-win situation - both for me and for the Network. If I can get the info about trx even a second sooner, then it's worth it. – knaperek Apr 28 '14 at 12:25
1

According to the discussion above I came to understanding that this is not possible without patching bitcoind.

I have found a workaround for my use case though: instead of using a single instance of bitcoind I'll run many of them (perhaps even on separate machines in separate locations) and make them talk to each other via addnode option. It is likely that different instances will talk to different nodes on the Network and thus enlarging the total set of nodes I receive updates from. I'll basically have a star topology of my nodes, using the central one for RPC. With more leaf nodes the maximum delay in receiving a transaction notification should lower.

knaperek
  • 1,414
  • 9
  • 22