<p>Ok got it, it seems you need to remove the line <code>bind=127.0.0.1:8333</code> from the config file, and (surprisingly) you can keep the setting <code>onlynet=onion</code> (you still can connect via ipv4 on the LAN). So the existing Tor node can be configured as follows:</p>

<pre><code>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
</code></pre>

<p>and the new local ipv4 node can be configured as follows:</p>

<pre><code>txindex=1
debug=mempool
daemon=1
connect=192.168.0.xxx:8333
</code></pre>

<p>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.</p>

CC BY-SA 3.0
2017-04-08T17:32:19.963Z
bind= controls incoming connections. If you bind to localhost, you can only accept incoming connections. onlynet= controls selection for outgoing connections.
Pieter Wuille
CC BY-SA 3.0
2017-04-08T18:17:51.177Z
@pieter thank you will experiment again in the light of comment
Sven Williamson
CC BY-SA 3.0
2017-04-08T16:50:44.563Z
2017-04-08T16:50:44.563Z
Sven Williamson
<p>Bitcoin core <code>v0.14.0</code> 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 <code>top</code> 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...</p>

<p>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 <code>bitcoind</code> 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:</p>

<p>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?</p>

<p><strong>EDIT:</strong> following the suggestions from the comment, I have tried to add the line:</p>

<pre><code>addnode=192.168.0.2:8333
</code></pre>

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

<pre><code>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
</code></pre>

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

<pre><code>$ sudo ufw allow 8333
</code></pre>

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

<pre><code>2017-03-31 13:21:50 connect() to 192.168.0.2:8333 failed after select(): Connection refused (111)
</code></pre>

CC BY-SA 3.0
2017-03-30T00:25:56.743Z
The 'connect' cli arg (alternative to addnode) seems possible for this situation?  described in dot-conf here https://en.bitcoin.it/wiki/Running_Bitcoin#Bitcoin.conf_Configuration_File
杜興怡
CC BY-SA 3.0
2017-04-08T04:34:13.170Z
@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.
Pieter Wuille
CC BY-SA 3.0
2017-04-08T16:52:35.907Z
@pieter thank you have amended accordingly.
Sven Williamson
<bitcoind><network><synchronization><full-node><tor>
Connecting full nodes within a LAN to speed up blockchain sync
Sven Williamson
# Connecting full nodes within a LAN to speed up blockchain sync

(Asked by: username_0 on 2017-03-29)

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)

```

**Tags:** bitcoind, network, synchronization, full-node, tor

> **Comments:**
> **username_1**: The 'connect' cli arg (alternative to addnode) seems possible for this situation?  described in dot-conf here https://en.bitcoin.it/wiki/Running_Bitcoin#Bitcoin.conf_Configuration_File  
> **username_2**: @username_0 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.  
> **username_0**: @username_2 thank you have amended accordingly.  

---

## 1 answers

### Answer by username_0 on 2017-04-08. Score: 0 | Accepted answer

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.

> **Comments:**
> **username_2**: bind= controls incoming connections. If you bind to localhost, you can only accept incoming connections. onlynet= controls selection for outgoing connections.  
> **username_0**: @username_2 thank you will experiment again in the light of comment  

---

