Hide behind full node.

[tiffy]

I have been running a Bitcoin Core full node as a Tor hidden service for some time now. The node runs on a virtual linux server at a large provider.

Now I want to set up (watch-only) wallets with a local bitcoind on my laptop using this full node. The aim is to to be able to generate unsigned transactions with the help of the wallets and to feed previously signed transactions into the network.

Above all, I want to prevent my real IP address from being leaked to the Bitcoin network. I will also use VPN software on my laptop. But I don't want to rely on that alone.

Below is the configuration I came up with:

Code:

daemon=1
connect=<address of my full node>
discover=0
dns=0
dnsseed=0
listen=0
listenonion=0

Would this setup suitable for my target to hide my real IP from the Bitcoin network (even without VPN) and using my wallets locally?

Is there perhaps a fundamentally better way to achieve what I want to achieve?

[odolvlobo]

Perhaps a better idea might be to run an electrum server next to bitcoind, and then run electrum on your laptop.

[nc50lc]

Code:

connect=<address of my full node>

Would this setup suitable for my target to hide my real IP from the Bitcoin network (even without VPN) and using my wallets locally?

Although you're exclusively connected to your full node in the virtual Linux server and prevents inbound connections,
that node may still advertise your IP through addr message or when it receive getaddr message from its peers.
But I'm not sure if any of your config makes a difference on how the remote node create the addr message though.

Ref: developer.bitcoin.org/reference/p2p_networking.html#addr

[ABCbits]

You might as well as configure Bitcoin Core (on your laptop) only using Tor. That way, you can avoid trusting VPN provider you use.

Perhaps a better idea might be to run an electrum server next to bitcoind, and then run electrum on your laptop.

That way, OP also can avoid rescan blockchain if you add address or wallet which already has balance.

[tiffy]

Although you're exclusively connected to your full node in the virtual Linux server and prevents inbound connections,
that node may still advertise your IP through addr message or when it receive getaddr message from its peers.
But I'm not sure if any of your config makes a difference on how the remote node create the addr message though.

I see.

I have placed the full node behind the Tor network. My bitcoin.conf on my full node now:

Code:

bind=127.0.0.1
discover=0
externalip=************************.onion
listen=1
proxy=127.0.0.1:9050

I have set up Tor on my server accordingly. The bitcoind now only listens locally. It just works. 

I would therefore use SSH port forwarding on my laptop for the connect. Something like this

Code:

connect=localhost:28333

Whereby 28333 is forwarded to 8333 on my full node. That should work, right?

I just wonder if my real IP@home can be leaked via DNS or some other detail. That's why I don't dare to start bitcoind at home yet.

I think I'll use a VPN with kill switch to be on the safe side. 

[ranochigo]

Looks good, but you should still connect to your node through TOR.

If you want to prevent your IPs from being leaked or your activities from being tracked by ISPs or any adversary, you should use Bitcoin Core with Tor on watch-only computer. Using VPNs, proxies or SSH tunneling may not provide sufficient privacy or safeguards against traffic analysis assuming that you want complete privacy. Using it over clearnet also guarantees that your ISP will be able to monitor your every move; connections are not encrypted between Bitcoin nodes.

When using TOR and running on onion network, there is virtually no privacy benefit on connecting to the node on your server besides complicating the whole process. The setup guide for running your node over TOR is here: https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md.

[NotATether]

Why not -addnode instead of -connect, if I may ask? You will most likely want to add other nodes to connect to, like Tor onion nodes and such, in the event that your server node becomes inaccessible or goes down for some reason. But you will at least be able to control which nodes you will get inbound and outbound connections to, instead of showing your IP address to the entire network.

PS. dns=0 and dnsseed=0 completely shuts down the DNS system in Core, so your IP won't be leaked though that way.

[ABCbits]

I just wonder if my real IP@home can be leaked via DNS or some other detail. That's why I don't dare to start bitcoind at home yet.

I think I'll use a VPN with kill switch to be on the safe side. 

Since you concerned about that, bad VPN provider or configuration can lead to either IPv4, IPv6 and DNS leaks.

[NotATether]

I just wonder if my real IP@home can be leaked via DNS or some other detail. That's why I don't dare to start bitcoind at home yet.

I think I'll use a VPN with kill switch to be on the safe side. 

Since you concerned about that, bad VPN provider or configuration can lead to either IPv4, IPv6 and DNS leaks.

Yeah, stay away from VPNs. Unless you are running your own home-made VPN using OpenVPN or Wireguard, with some of your own servers, which seems overkill to me, you can't really trust any providers to not store and ultimately leak the logs to somebody, whether it be intentionally or through a hack. Especially just using it for Bitcoin Core is overkill, and VPNs and Tor used together comes with a few privacy risks.

[tiffy]

Why not -addnode instead of -connect, if I may ask? You will most likely want to add other nodes to connect to, like Tor onion nodes and such, in the event that your server node becomes inaccessible or goes down for some reason. But you will at least be able to control which nodes you will get inbound and outbound connections to, instead of showing your IP address to the entire network.

I have now started like this for testing. I might switch later.

PS. dns=0 and dnsseed=0 completely shuts down the DNS system in Core, so your IP won't be leaked though that way.

Thanks for the tip!

[ranochigo]

Why not -addnode instead of -connect, if I may ask? You will most likely want to add other nodes to connect to, like Tor onion nodes and such, in the event that your server node becomes inaccessible or goes down for some reason. But you will at least be able to control which nodes you will get inbound and outbound connections to, instead of showing your IP address to the entire network.

Using connect makes sure Bitcoin Core only uses the nodes that you've specified while addnode would preferably try those nodes but will connect to others if they fail. If I'm not mistaken, both would propagate your IP address to others through addr messages. However, addnode would likely not enhance your privacy at all, as compared to not running addnode at all.

[tiffy]

Thanks again for your comments.

I have now successfully implemented this. The VPN was very helpful because I was temporarily connected directly to the Bitcoin network due to a configuration error.

However, you don't need a VPN for the finished (very simple) setup.

C L I E N T  S I D E

Configuration of the Bitcoin Daemon on my local system:

Code:

daemon=1
connect=127.0.0.1:28333
discover=0
dns=0
dnsseed=0
listen=0
listenonion=0 

SSH Config on my local system (replace strings in capital letters with your own values):

Code:

Host NAME
     Hostname        SERVER_IP
     User            USER
     LocalForward    28333  127.0.0.1:8333 

The connection is then simply made with

Code:

ssh NAME

S E R V E R  S I D E

Configuration of the Bitcoin Daemon on my server (replace ONION_ADDR with your own value):

Code:

bind=127.0.0.1
discover=0
externalip=ONION_ADDR
listen=1
proxy=127.0.0.1:9050

/etc/tor/torrc on my server

Code:

HiddenServiceDir /var/lib/tor/bitcoin-service/
HiddenServicePort 8333 127.0.0.1:8333

/etc/tor/torsocks.conf on my server

Code:

TorAddress 127.0.0.1
TorPort 9050
OnionAddrRange 127.42.42.0/24

After you have restarted TOR, you will find your ONION_ADDR under

Code:

/var/lib/tor/bitcoin-service/hostname