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.


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.

  • 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
  • 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
  • 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

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.

  • I think the star topology model is a very good way to approach this problem. – Besir Kurtulmus Apr 30 '14 at 7:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.