Quote from: redphlegm on April 14, 2014, 09:06:38 PM

First of all, my apologies if I'm going the wrong route for this type of question. I realize the development team has a very full plate with development and responding to threads such as this. If proper protocol is to plug this into an issue / suggesting tracking system, I would be happy to do so - I just didn't see one in my looking around.

I also didn't see the answer to this question anywhere else. I saw some mention of it from a year ago where it was a single line change in the python code but this question reaches beyond that, I think. Let me describe my scenario:

Let's say I am dealing with many machines (for the sake of conversation, let's say 2 desktops, 2 laptops, and an offline machine I use for Armory cold storage - all with various OS's). I would like to be able to have a master machine that is responsible for downloading the blockchain and maintaining it for the rest of the machines (especially the laptops since they have limited storage on SSDs). Is there a way to accomplish this? Ideally I would set up Desktop A as the main client that is on all the time and downloads the blockchain. The rest of the machines would use that copy of the blockchain, ideally. I don't necessarily care if the Armory DB is locally stored (for instance having it on a NAS or something on the same network). It would still be a lot less storage overhead than I'm currently dealing with.

Thanks in advance.

Yes, it's been asked before, but it's not implemented yet.

The closest you can get to that is to either

- have one machine with a regular "online" Bitcoin node, connected to the internet
- have all other local clients connect to that "online" node only, with two full blockchains on every node still

- use a different, light client, like electrum for example. You could even set up your own electrum server on one computer, as I understand it

The general problem, I believe, is that several computers accessing and writing to the same (blockchain-)database will immediately corrupt it, if no precautions are made. So this feature would need a lot of changes under the hood. And probably has a somewhat low demand, for that much effort, compared to other features..

I'm in your boat here. And I run a local "always on" node, where all other nodes connect to when they run, from time to time.

Ente