## How do I configure Bitcoin Core to connect always to a particular node?

9

2

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

Depends on what software you are using for Y. – Nate Eldredge – 2015-11-18T02:43:43.577

same, bitcoin-core, I'll edit the question – knocte – 2015-11-18T02:47:15.320

1Bitcoin 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 – 2015-11-18T03:11:32.653

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 – 2015-11-18T05:53:17.750

2

@knocte No, 'full node' means something else: https://en.bitcoin.it/wiki/Full_node

– Nick ODell – 2015-11-18T07:20:59.287

12

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:

1. -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.)
2. -whitebind=<addr> Bind to given address and whitelist peers connecting to it. Use [host]:port notation for IPv6
3. -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
4. 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.

Yes, it must be dowload all blk and create a db information when you run bitcoind – vincenzopalazzo – 2019-08-08T10:57:12.660

Does this method implies that the private node has to download the whole blockchain? – k76u4vkweek547v7 – 2018-03-31T16:13:21.373