Multiple bitcoind instances sharing one blockchain.

[stonehedge]

Hi,

Is it possible for somebody to run several bitcoin instances sharing the same local blockchain?

If it is possible, how is it done and what are the risks?

If it isn't possible, what prevents it from happening?

I am keen to understand whether there are any full node operators out there who are skimping on the storage costs that come with running multiple full nodes.

Many thanks.

[ranochigo]

It's probably not possible IIRC.

Bitcoin Core creates a lock file that is only deleted once the program exits. If Bitcoin Core detects such a file, the instance will not run. Accessing Blockchain from two different places would result in a corruption (same scenario as how Blockchain gets corrupted if anti viruses attempts to scan it).

[stonehedge]

It's probably not possible IIRC.

Bitcoin Core creates a lock file that is only deleted once the program exits. If Bitcoin Core detects such a file, the instance will not run. Accessing Blockchain from two different places would result in a corruption (same scenario as how Blockchain gets corrupted if anti viruses attempts to scan it).

Thank you. 

For clarity, does this mean that it is possible but is ill advised or that it is simply impossible due to the lock file mechanism?

[ranochigo]

It's probably not possible IIRC.

Bitcoin Core creates a lock file that is only deleted once the program exits. If Bitcoin Core detects such a file, the instance will not run. Accessing Blockchain from two different places would result in a corruption (same scenario as how Blockchain gets corrupted if anti viruses attempts to scan it).

Thank you.  

For clarity, does this mean that it is possible but is ill advised or that it is simply impossible due to the lock file mechanism?

It is possible to bypass it by removing the lock file after opening up an instance. Another instance would then be able to be opened up without the check for running Bitcoind warning.

However, the client will not be able to read the blocks and it would get corrupted. You will need an reindex after that. (IIRC)

[mocacinno]

Why would you do this?

Most reasons should be easily solvable by using an RPC call instead of a second deamon, isn't it?

[stonehedge]

Why would you do this?

Most reasons should be easily solvable by using an RPC call instead of a second deamon, isn't it?

I am trying to understand, for example, whether somebody could run 10 bitcoin full nodes only using one single copy of the blockchain thus saving on storage costs.

More specifically, I want to understand whether it is possible to prevent this behavior if it is already possible.

[shorena]

Why would you do this?

Most reasons should be easily solvable by using an RPC call instead of a second deamon, isn't it?

I am trying to understand, for example, whether somebody could run 10 bitcoin full nodes only using one single copy of the blockchain thus saving on storage costs.

More specifically, I want to understand whether it is possible to prevent this behavior if it is already possible.

Now you are asking the correct question. The answer is, yes its possible to fake e.g. 10 full nodes while only providing the resources (or only slightly more) of a single node. The 9 fake nodes would run custom software (not core!) that would forward the requests to the single full node. In theory this full node can be any other on the network that is available, so you could do this without running a single node.

The idea to proof that you run a full node and thus get rewarded for doing so has been brought up several times. I have not seen a good solution yet. I would applaud a solution as the number of nodes decreases and the costs of running one increase.

[coins101]

This is also an issue for bittorent.

People fake their seeding ratio in order to push up their download speeds.

One of the best forms of defence against Sybil attacks is putting up a money barrier. It's a shame nodes are not used for mining as they were intended. Perhaps nodes now need their own PoW to validate storage.

Edit

Nodes could perform PoW on a random set of blocks and generate a hash of the results. The calculations to be performed and the PoW to be used could then propagate and nodes would have to provide the same hash but signed with a public key. You could set an upper limit for correct verification based on response times and this coukd possibly filter out fakes - then send micropayments to those that seem to pass the test n-times.