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:
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=<myexternaltoraddress>.onion seednode=<seed1>.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)