3

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=<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)
3
  • The 'connect' cli arg (alternative to addnode) seems possible for this situation? described in dot-conf here en.bitcoin.it/wiki/…
    – 杜興怡
    Commented Mar 30, 2017 at 0:25
  • @sven If you have found an acceptable answer yourself, you should post it as an answer, not edit it into your question. At this point, it is unclear what you're still asking for. Commented Apr 8, 2017 at 4:34
  • @pieter thank you have amended accordingly. Commented Apr 8, 2017 at 16:52

1 Answer 1

0

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=<myexternaltoraddress>.onion
seednode=<seed1>.onion
[...]
seednode=<seedk>.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.

2
  • 1
    bind= controls incoming connections. If you bind to localhost, you can only accept incoming connections. onlynet= controls selection for outgoing connections. Commented Apr 8, 2017 at 17:32
  • @pieter thank you will experiment again in the light of comment Commented Apr 8, 2017 at 18:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.