9

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

| improve this question | |
  • Depends on what software you are using for Y. – Nate Eldredge Nov 18 '15 at 2:43
  • same, bitcoin-core, I'll edit the question – knocte Nov 18 '15 at 2:47
  • 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. – Nate Eldredge Nov 18 '15 at 3:11
  • 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 Nov 18 '15 at 5:53
  • 2
    @knocte No, 'full node' means something else: en.bitcoin.it/wiki/Full_node – Nick ODell Nov 18 '15 at 7:20
11

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.

| improve this answer | |
  • Does this method implies that the private node has to download the whole blockchain? – k76u4vkweek547v7 Mar 31 '18 at 16:13
  • Yes, it must be dowload all blk and create a db information when you run bitcoind – vincenzopalazzo Aug 8 '19 at 10:57

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.