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

<p>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 <code>addnode</code> <a href="https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list#Full_list" rel="nofollow">option</a>. 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.</p>

CC BY-SA 3.0
2014-04-30T07:43:43.770Z
I think the star topology model is a very good way to approach this problem.
Besir Kurtulmus
CC BY-SA 3.0
2014-04-30T07:37:06.457Z
2014-04-30T07:37:06.457Z
knaperek
<p>Bitcoind will never make more than 8 outgoing connections. By default, it will allow up to 128 connections (see <code>-maxconnections</code>), but that includes incoming ones.</p>

<p>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.</p>

CC BY-SA 3.0
2014-04-27T14:28:57.837Z
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
CC BY-SA 3.0
2014-04-27T14:57:30.367Z
@knapo: Well, you have the source code, a text editor, and a compiler...
Nate Eldredge
CC BY-SA 3.0
2014-04-27T18:25:32.547Z
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
CC BY-SA 3.0
2014-04-27T18:37:52.513Z
@NateEldredge: I know, I was asking for another way (see my question).
knaperek
CC BY-SA 3.0
2014-04-27T18:46:41.627Z
@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
CC BY-SA 3.0
2014-04-27T21:21:26.650Z
There is no point in wanting more than 8 outgoing connections, and how many others connect to you depends on them.
Pieter Wuille
CC BY-SA 3.0
2014-04-28T09:04:52.727Z
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
CC BY-SA 3.0
2014-04-28T11:42:23.993Z
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
CC BY-SA 3.0
2014-04-28T12:25:25.013Z
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
CC BY-SA 3.0
2014-04-27T12:23:27.000Z
2014-04-27T12:23:27.000Z
Pieter Wuille
<p>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).</p>

<p>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?</p>

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

<bitcoind><nodes><peers><connection>
How to make bitcoind connect to more nodes?
knaperek
# How to make bitcoind connect to more nodes?

(Asked by: username_0 on 2014-04-27)

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.

**Tags:** bitcoind, nodes, peers, connection


---

## 2 answers

### Answer by username_0 on 2014-04-30. Score: 1 | Accepted answer

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](https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list#Full_list). 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.

> **Comments:**
> **username_1**: I think the star topology model is a very good way to approach this problem.  

---

### Answer by username_2 on 2014-04-27. Score: 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.

> **Comments:**
> **username_0**: 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)...  
> **username_3**: @knapo: Well, you have the source code, a text editor, and a compiler...  
> **username_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.  
> **username_0**: @username_3: I know, I was asking for another way (see my question).  
> **username_0**: @username_2: 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.  
> **username_2**: There is no point in wanting more than 8 outgoing connections, and how many others connect to you depends on them.  
> **username_0**: 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.  
> **username_2**: 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.  
> **username_0**: 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.  

---

