<p>Your private node would still be a fully validating node (i.e. full node). That's a good thing.</p>

<p>As for having the private node connect to your public node, you have two choices:</p>

<ol>
<li><code>-addnode=&lt;ip&gt;</code> Add a node to connect to and attempt to keep the connection open</li>
<li><code>-connect=&lt;ip&gt;</code> Connect only to the specified node(s)</li>
</ol>

<p>What you were asking for is nr 2, but you might want to consider nr 1 instead because that gives your private node a bit more redundancy in case there's a problem with your public node (hardware problem, disk full, router misconfiguration...). But it will make a few outgoing connections to random internet nodes (slight security problem if you don't trust the bitcoin p2p protocol and it will cause a bit more bandwidth usage).</p>

<p>You might also consider these options:</p>

<ol start="3">
<li><code>-listen=0</code>  Don't accept connections from outside (implied by -connect). (although if you don't port forward in your firewall, it doesn't matter.)</li>
<li><code>-whitebind=&lt;addr&gt;</code>
   Bind to given address and whitelist peers connecting to it. Use
   [host]:port notation for IPv6</li>
<li><code>-whitelist=&lt;netmask&gt;</code>
   Whitelist peers connecting from the given netmask or IP address. Can be
   specified multiple times. Whitelisted peers cannot be DoS banned and
   their transactions are always relayed, even if they are already in the
   mempool, useful e.g. for a gateway</li>
<li><code>upnp=0</code> to disable UPnP. If you're capable of doing your own firewall configuration, you don't want this increased attack surface. (This has/will become the default in recent versions.)</li>
</ol>

<p>The whitelisting (4 and 5) will prevent your private node from accidentally banning your public node if something weird happens.</p>

<p><strong>Public node configuration</strong></p>

<p>You probably also want to have e.g. <code>-whitelist=192.168.1.0/24</code> on your public node as well to never ban your private node.</p>

<p>If it's not running a wallet, use the option <code>-disablewallet</code> [Do not load the wallet and disable wallet RPC calls]. Saves some resources and lowers the attack surface.</p>

CC BY-SA 3.0
2018-03-31T16:13:21.373Z
Does this method implies that the private node has to download the whole blockchain?
k76u4vkweek547v7
CC BY-SA 4.0
2019-08-08T10:57:12.660Z
Yes, it must be dowload all blk and create a db information when you run bitcoind
vincenzopalazzo
CC BY-SA 3.0
2015-11-18T09:41:23.323Z
2015-11-18T10:02:07.510Z
2015-11-18T10:02:07.510Z
Jannes
<p>By reading <a href="https://bitcoin.org/en/full-node" rel="noreferrer">https://bitcoin.org/en/full-node</a> I've decided that I want to run a FULL node (let's call it 'X'), to contribute to the P2P network.</p>

<p>So, I'll leave its ports open, or have a DMZ zone with a public IP address in it.</p>

<p>But this comes with security risks, so I will not have any funds in this instance of the Bitcoin Core QT client.</p>

<p>Then, I will keep my BTC funds in a different computer (let's call it 'Y') that will not be a full node (but still use bitcoin-core QT main client).</p>

<p>However, how can I configure 'Y' to always connect (in order to broadcast my transactions) to my server 'X' and not a different one?</p>

<p>Thanks</p>

CC BY-SA 3.0
2015-11-18T02:43:43.577Z
Depends on what software you are using for Y.
Nate Eldredge
CC BY-SA 3.0
2015-11-18T02:47:15.320Z
same, bitcoin-core, I'll edit the question
knocte
CC BY-SA 3.0
2015-11-18T03:11:32.653Z
Bitcoin Core is always a full node in the sense that it has to download and verify the entire block chain. But if you only want it to talk to the one other node, see the --connect option.
Nate Eldredge
CC BY-SA 3.0
2015-11-18T05:53:17.750Z
Well, if you place it in a private IP it is not a full node. Thanks for the hint about --connect, I'll test it.
knocte
CC BY-SA 3.0
2015-11-18T07:20:59.287Z
@knocte No, 'full node' means something else: https://en.bitcoin.it/wiki/Full_node
Nick ODell
<bitcoin-core><nodes><port>
How do I configure Bitcoin Core to connect always to a particular node?
knocte
# How do I configure Bitcoin Core to connect always to a particular node?

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

By reading <https://bitcoin.org/en/full-node> I've decided that I want to run a FULL node (let's call it 'X'), to contribute to the P2P network.

So, I'll leave its ports open, or have a DMZ zone with a public IP address in it.

But this comes with security risks, so I will not have any funds in this instance of the Bitcoin Core QT client.

Then, I will keep my BTC funds in a different computer (let's call it 'Y') that will not be a full node (but still use bitcoin-core QT main client).

However, how can I configure 'Y' to always connect (in order to broadcast my transactions) to my server 'X' and not a different one?

Thanks

**Tags:** bitcoin-core, nodes, port

> **Comments:**
> **username_1**: Depends on what software you are using for Y.  
> **username_0**: same, bitcoin-core, I'll edit the question  
> **username_1**: Bitcoin Core is always a full node in the sense that it has to download and verify the entire block chain. But if you only want it to talk to the one other node, see the --connect option.  
> **username_0**: Well, if you place it in a private IP it is not a full node. Thanks for the hint about --connect, I'll test it.  
> **username_2**: @username_0 No, 'full node' means something else: https://en.bitcoin.it/wiki/Full_node  

---

## 1 answers

### Answer by username_3 on 2015-11-18. Score: 15 | Accepted answer

Your private node would still be a fully validating node (i.e. full node). That's a good thing.

As for having the private node connect to your public node, you have two choices:

1. `-addnode=<ip>` Add a node to connect to and attempt to keep the connection open
2. `-connect=<ip>` Connect only to the specified node(s)

What you were asking for is nr 2, but you might want to consider nr 1 instead because that gives your private node a bit more redundancy in case there's a problem with your public node (hardware problem, disk full, router misconfiguration...). But it will make a few outgoing connections to random internet nodes (slight security problem if you don't trust the bitcoin p2p protocol and it will cause a bit more bandwidth usage).

You might also consider these options:

3. `-listen=0` Don't accept connections from outside (implied by -connect). (although if you don't port forward in your firewall, it doesn't matter.)
4. `-whitebind=<addr>`
   Bind to given address and whitelist peers connecting to it. Use
   [host]:port notation for IPv6
5. `-whitelist=<netmask>`
   Whitelist peers connecting from the given netmask or IP address. Can be
   specified multiple times. Whitelisted peers cannot be DoS banned and
   their transactions are always relayed, even if they are already in the
   mempool, useful e.g. for a gateway
6. `upnp=0` to disable UPnP. If you're capable of doing your own firewall configuration, you don't want this increased attack surface. (This has/will become the default in recent versions.)

The whitelisting (4 and 5) will prevent your private node from accidentally banning your public node if something weird happens.

**Public node configuration**

You probably also want to have e.g. `-whitelist=192.168.1.0/24` on your public node as well to never ban your private node.

If it's not running a wallet, use the option `-disablewallet` [Do not load the wallet and disable wallet RPC calls]. Saves some resources and lowers the attack surface.

> **Comments:**
> **username_4**: Does this method implies that the private node has to download the whole blockchain?  
> **username_5**: Yes, it must be dowload all blk and create a db information when you run bitcoind  

---

