Connecting full nodes within a LAN to speed up blockchain sync Bitcoin core v0.14.0 seems to be a lot quicker than previous versions, to the point where syncing the full blockchain now seems to be IO-bound rather than CPU-bound: When running top I used to see my CPU running at full capacity (indicating that network IO was not the limiting factor). This is no longer the case it seems, and the speed of network IO seems to be a relevant factor in the time it takes to sync a full blockchain...

Now we always have some new hardware to set up, or some new OS to try out and invariably we find ourselves in the position of building and installing bitcoind followed by a blockchain sync. Now that network speed matters, it would make a lot of sense to try and source the blockchain data from another full node we happen to be running on the same LAN, rather than fetching the data externally from a random peer connection. So my question is:

Assuming I have another full node running on the same LAN, how do I set up the config file of the new node to ensure it connects to this local node so as to benefit from the increased network speed? (This question assuming both nodes are IPv4). How do I change these settings if the running full node is on Tor while the new node is IPv4, or when the running node is IPv4 and the new node is on Tor?

EDIT: following the suggestions from the comment, I have tried to add the line:

addnode=192.168.0.2:8333


in the config file of the new (ipv4) node where 192.168.0.2 is the local ip of the established (tor) node. My tor node config file is as follows:

txindex=1
debug=mempool
daemon=1
#onlynet=onion # commented out to allow local ipv4 connection
onion=127.0.0.1:9050
port=8333
listen=1
bind=127.0.0.1:8333
externalip=&lt;myexternaltoraddress&gt;.onion
seednode=&lt;seed1&gt;.onion
...
banscore=10000
bantime=11


I have also made sure my firewall on the tor node server is properly set up

$ sudo ufw allow 8333


However, my tor node is refusing the connection request as can be seen from the new node debug:

2017-03-31 13:21:50 connect() to 192.168.0.2:8333 failed after select(): Connection refused (111)
Ok got it, it seems you need to remove the line bind=127.0.0.1:8333 from the config file, and (surprisingly) you can keep the setting onlynet=onion (you still can connect via ipv4 on the LAN). So the existing Tor node can be configured as follows:

txindex=1
debug=mempool
daemon=1
onlynet=onion
onion=127.0.0.1:9050
port=8333
listen=1
externalip=&lt;myexternaltoraddress&gt;.onion
seednode=&lt;seed1&gt;.onion
[...]
seednode=&lt;seedk&gt;.onion
banscore=10000
bantime=11


and the new local ipv4 node can be configured as follows:

txindex=1
debug=mempool
daemon=1
connect=192.168.0.xxx:8333


With these settings, the Tor node works as normal with Tor only connections (inbound and outbound) with the exception of the local ipv4 connection from the new node.