<p>I wouldn't try to have both <code>bitcoind</code>s attached to the same storage, that sounds like a recipe for disaster, if it'll start at all.</p>

<p>You can either tunnel the 8332 port on your personal computer to the remote server like this:</p>

<pre><code>ssh -L 8332:localhost:8332 &lt;remoteip&gt;
</code></pre>

<p>This'll basically say "whenever I connect on the local port 8332, open a connection on the remote end to <code>localhost:8332</code>, i.e., your server's 8332 port, and tunnel all traffic through it". So this mimicks a local <code>bitcoind</code> but transparently passes everything over to the server. No need to share at all.</p>

<p>The other option is to add the following line to your <code>bitcoin.conf</code> file:</p>

<pre><code>rpcconnect=&lt;remoteip&gt;
</code></pre>

<p>This will make <code>bitcoin-cli</code> connect to the remote <code>bitcoind</code> instead. You also need to make sure you actually allow incoming connections on the server, so this may be a bit less secure than the SSH variant above.</p>

CC BY-SA 3.0
2017-01-18T23:47:36.157Z
Bitcoin Core uses LevelDB which relies on mmap filesystem access - something that is generally available for network storage.
Pieter Wuille
CC BY-SA 3.0
2017-02-16T00:30:51.523Z
I'm yet to solve this as I held off until I got a NAS , so I will want to stick the blockchain on that and I suppose one of the bitcoin clients has to service it while other clients can just look on, haven't tried your suggestions above yet.
user981977
CC BY-SA 3.0
2017-02-16T13:00:41.427Z
If you can run `bitcoind` on the NAS itself (e.g., dockerized on Synology and similar) you should do that and expose the RPC port to the LAN. Otherwise you could mount a volume on any other machine, run `bitcoind` there, possibly with the `-datadir=<volume-mountpoint>` option so that it stores the data on that volume, and have that `bitcoind` expose its RPC port to the LAN.
cdecker
CC BY-SA 3.0
2017-01-18T20:24:15.577Z
2017-01-18T20:24:15.577Z
cdecker
<p>Shared blockchain... I have a server PC that is on all the time and runs a copy of bitcoin core 24/7.
My main personal computer I use separate for everything else including and I use both Bitcoin core and Armory.
Each time I open either of these I have to update the blockchain to my computer, no big deal if it is only a day or two behind but it means I have two copies of the same blockchain, one on each PC. Would be nice to not have that increasing disk space used on my main personal PC.
Rather than doing a copy from the server PC, is it possible to set up somehow, somewhere in the config file of either or both wallets to share the blockchain that will always be up to date on the server PC across my LAN ?</p>

CC BY-SA 3.0
2017-01-16T01:10:44.970Z
I don't know whether it works because I don't use Bitcoin Core, but if you're on a Unix system, just softlinking to the blockchain data via some network protocol (like SFTP where you don't have to set up anything besides installing an SSH server, which you probably already did, on most distros) probably works.
UTF-8
<blockchain><shared>
How to share the blockchain across local network residing on 1 PC, not copy?
user981977
# How to share the blockchain across local network residing on 1 PC, not copy?

(Asked by: username_0 on 2017-01-15)

Shared blockchain... I have a server PC that is on all the time and runs a copy of bitcoin core 24/7.
My main personal computer I use separate for everything else including and I use both Bitcoin core and Armory.
Each time I open either of these I have to update the blockchain to my computer, no big deal if it is only a day or two behind but it means I have two copies of the same blockchain, one on each PC. Would be nice to not have that increasing disk space used on my main personal PC.
Rather than doing a copy from the server PC, is it possible to set up somehow, somewhere in the config file of either or both wallets to share the blockchain that will always be up to date on the server PC across my LAN ?

**Tags:** blockchain, shared

> **Comments:**
> **username_1**: I don't know whether it works because I don't use Bitcoin Core, but if you're on a Unix system, just softlinking to the blockchain data via some network protocol (like SFTP where you don't have to set up anything besides installing an SSH server, which you probably already did, on most distros) probably works.  

---

## 1 answers

### Answer by username_2 on 2017-01-18. Score: 2

I wouldn't try to have both bitcoinds attached to the same storage, that sounds like a recipe for disaster, if it'll start at all.
You can either tunnel the 8332 port on your personal computer to the remote server like this:
ssh -L 8332:localhost:8332 

This'll basically say "whenever I connect on the local port 8332, open a connection on the remote end to localhost:8332, i.e., your server's 8332 port, and tunnel all traffic through it". So this mimicks a local bitcoind but transparently passes everything over to the server. No need to share at all.
The other option is to add the following line to your bitcoin.conf file:
rpcconnect=

This will make bitcoin-cli connect to the remote bitcoind instead. You also need to make sure you actually allow incoming connections on the server, so this may be a bit less secure than the SSH variant above.

> **Comments:**
> **username_3**: Bitcoin Core uses LevelDB which relies on mmap filesystem access - something that is generally available for network storage.  
> **username_0**: I'm yet to solve this as I held off until I got a NAS , so I will want to stick the blockchain on that and I suppose one of the bitcoin clients has to service it while other clients can just look on, haven't tried your suggestions above yet.  
> **username_2**: If you can run `bitcoind` on the NAS itself (e.g., dockerized on Synology and similar) you should do that and expose the RPC port to the LAN. Otherwise you could mount a volume on any other machine, run `bitcoind` there, possibly with the `-datadir=<volume-mountpoint>` option so that it stores the data on that volume, and have that `bitcoind` expose its RPC port to the LAN.  

---

