<p>Bitcoin Core allows you to bind a separate listening socket with specific white listing properties. It has enhanced transaction relaying for use as a gateway and an immunity to banning for bad behavior. </p>

<pre><code>  -whitebind=&lt;addr&gt;
       Bind to given address and whitelist peers connecting to it. Use
       [host]:port notation for IPv6
</code></pre>

<p>This command can be used in conjunction with <code>whiteconnections</code> to reserve some of the <code>maxconnections</code> limit for connections to the whitelist socket. <code>maxconnections=128</code> and <code>whiteconnections=4</code> will use 8 for outgoing connections, allow a maximum of 116 incoming connections, and reserve 4 additional connections for incoming clients on the whitelisted port.</p>

<p>In this case you would bind the whitelist socket to an internal port, and then point LAN nodes to it. This is also useful for attaching axillary programs like <a href="http://p2pool.in" rel="nofollow">P2Pool</a> or the <a href="http://bitcoinrelaynetwork.org/" rel="nofollow">Bitcoin Relay Network</a>. </p>

CC BY-SA 3.0
2016-03-09T13:08:28.043Z
As of 0.12.0 `whiteconnections` is not required. A non-whitelisted peer will be disconnected if a whitelisted peer attempts to connect and the node is full.
Alistair Buxton
CC BY-SA 3.0
2015-07-11T16:28:25.023Z
2015-07-15T21:31:40.780Z
2015-07-15T21:31:40.780Z
Claris
<p>I run a Bitcoin daemon on my LAN server that is connected to the Internet, and would like to use one or more Bitcoin wallets on local workstations that would connect only to my daemon. This initially works (connect=IP in wallet's bitcoin.conf), but when the daemon reaches the maxconnections, local wallets can't connect until the daemon is restarted so all the existing connections are closed.</p>

<p>Is there a way to permit local clients to connect to the daemon regardless of maxconnections parameter, or to somehow reserve few "slots" to particular local IP addresses?</p>

<p>Thanks!</p>

CC BY-SA 3.0
2015-07-11T14:36:03.823Z
Have you tried the [`-whitelist`](https://en.bitcoin.it/wiki/Running_Bitcoin) option?
morsecoder
<wallet><daemon>
Reserve the connection for local wallets
SBurina
# Reserve the connection for local wallets

(Asked by: username_0 on 2015-07-11)

I run a Bitcoin daemon on my LAN server that is connected to the Internet, and would like to use one or more Bitcoin wallets on local workstations that would connect only to my daemon. This initially works (connect=IP in wallet's bitcoin.conf), but when the daemon reaches the maxconnections, local wallets can't connect until the daemon is restarted so all the existing connections are closed.

Is there a way to permit local clients to connect to the daemon regardless of maxconnections parameter, or to somehow reserve few "slots" to particular local IP addresses?

Thanks!

**Tags:** wallet, daemon

> **Comments:**
> **username_1**: Have you tried the [`-whitelist`](https://en.bitcoin.it/wiki/Running_Bitcoin) option?  

---

## 1 answers

### Answer by username_2 on 2015-07-11. Score: 5 | Accepted answer

Bitcoin Core allows you to bind a separate listening socket with specific white listing properties. It has enhanced transaction relaying for use as a gateway and an immunity to banning for bad behavior.

```
  -whitebind=<addr>
       Bind to given address and whitelist peers connecting to it. Use
       [host]:port notation for IPv6

```

This command can be used in conjunction with `whiteconnections` to reserve some of the `maxconnections` limit for connections to the whitelist socket. `maxconnections=128` and `whiteconnections=4` will use 8 for outgoing connections, allow a maximum of 116 incoming connections, and reserve 4 additional connections for incoming clients on the whitelisted port.

In this case you would bind the whitelist socket to an internal port, and then point LAN nodes to it. This is also useful for attaching axillary programs like [P2Pool](http://p2pool.in) or the [Bitcoin Relay Network](http://bitcoinrelaynetwork.org/).

> **Comments:**
> **username_3**: As of 0.12.0 `whiteconnections` is not required. A non-whitelisted peer will be disconnected if a whitelisted peer attempts to connect and the node is full.  

---

