multiple instances, and read-only blockchain

[payb.tc]

before i attempt this, i'm wondering if anyone else has been crazy enough to try...

let say you're running 2 instances of bitcoind in 2 different folders (different datadir, different ports, etc).

on the 2nd instance, instead of physical files blk00001.dat and blkindex.dat, would it be okay to have symbolic links that point to the first instance's copy of those files?

as long as instance 1 is keeping an up-to-date copy of the blockchain, instance two shouldn't need to have it's own 1gb+ of hdd space for it, but could it get away with having a READ-ONLY copy of the blockchain? (i.e. just the symlinks?).

[ovidiusoft]

Probably not. A symlink doesn't guarantee read-only, it will depend on the target file rights. And if the second process can write to the target file, it will try. And it will probably not end well. You can try to run the second bitcoind process as another user that only has read rights on the target file and see what happens. It will most likely fail...

Remember to backup!

[payb.tc]

Probably not. A symlink doesn't guarantee read-only, it will depend on the target file rights. And if the second process can write to the target file, it will try. And it will probably not end well. You can try to run the second bitcoind process as another user that only has read rights on the target file and see what happens. It will most likely fail...

Remember to backup!

well now i'm thinking that with 100gb+ free on the hdd, i'll just leave this experiment for another day

something to think about anyway... maybe there's a need for such a scenario to be considered when the code is being worked on.

[kokjo]

do you want 2 wallets, but only one block and transaction confirmation engine?

well im working on a more modular client, that it would be relative easy to get to support 2 separate wallets.
its more like a daemon:

network daemon <-> blockchain and transaction verification <-> wallet daemons.

each wallet daemon would send a subscribe command to that blockchain daemon, for every address. and only receive tx, to these addresses. and when a wallet would like to spend something, it sends a signed transaction back to the block daemon.

the daemons could even be on different computers(using some RPC), for extra security.

[payb.tc]

do you want 2 wallets, but only one block and transaction confirmation engine?

well im working on a more modular client, that it would be relative easy to get to support 2 separate wallets.
its more like a daemon:

network daemon <-> blockchain and transaction verification <-> wallet daemons.

each wallet daemon would send a subscribe command to that blockchain daemon, for every address. and only receive tx, to these addresses. and when a wallet would like to spend something, it sends a signed transaction back to the block daemon.

the daemons could even be on different computers(using some RPC), for extra security.

yes please, sounds great... or how about 2048 wallets and only one block and transaction confirmation engine

(i have a habit of investigating scenarios that i'm not even likely to use... just to find out where the limits are)

having the functionality separate as you suggest, sounds like a great idea.

[kokjo]

yes please, sounds great... or how about 2048 wallets and only one block and transaction confirmation engine

it is not working yet. chill! https://github.com/kokjo/pycoin , but i got alot of branches, and uncommited code.

but 2048 wallets would be possible. but it would likely put the engine under alot of load. -> big costy server.
it is likely that is will not be able to scale.

[dree12]

do you want 2 wallets, but only one block and transaction confirmation engine?

well im working on a more modular client, that it would be relative easy to get to support 2 separate wallets.
its more like a daemon:

network daemon <-> blockchain and transaction verification <-> wallet daemons.

each wallet daemon would send a subscribe command to that blockchain daemon, for every address. and only receive tx, to these addresses. and when a wallet would like to spend something, it sends a signed transaction back to the block daemon.

the daemons could even be on different computers(using some RPC), for extra security.

yes please, sounds great... or how about 2048 wallets and only one block and transaction confirmation engine

(i have a habit of investigating scenarios that i'm not even likely to use... just to find out where the limits are)

having the functionality separate as you suggest, sounds like a great idea.

I believe the latest solidcoin client includes multiple wallets, so a merge may be possible without requiring python and some other dependencies like that. Unfortunately the code is not licenced under an acceptable licence for redistribution, however personal use should be acceptable.