Quote from: ScripterRon on September 20, 2017, 03:18:55 PM

Quote from: Kogs on September 20, 2017, 06:56:24 AM

I also think the easiest way not get any conflict with the data directories you should create two different users.
Run bitcoin core with user 1 and bitcoin abc with user 2.

If you build the bitcoind yourself from source, you should NOT execute the "make install" command. This would copy the bitcoind to /usr/local/bin. If you would do this for both versions, you will only have one bitcoind installed correctly, as for both clients the executable is named 'bitcoind'

Instead you should execute the bitcoind from the build directory of your source (usually found in bitcoin/src/bitcoind).

If you use precompiled clients from tar balls, you can also execute the bitcoind executable directly from the directory you extracted it.

To speed up syncing I would start only the bitcoin core (version 0.15 - bit faster than 0.14) first to get the complete blockchain.
After finished syncing, copy the complete datadir from core to the abc datadir and then start the bitcoin abc.

I'm just not sure if copying the datadir will work correctly with the blocks mined after the fork.
I've done this before the fork, so both blockchains were the same at that time. Now as they forked, maybe copying the datadir does produce errors with bitcoin abc.

Maybe someone can tell if this is an issue or not?

Quote from: ScripterRon on September 19, 2017, 02:51:59 PM

I ran both Bitcoin Core and BitcoinABC on Ubuntu. However, I installed both from tar files. You need to specify different data directories and ports. You can save space by using symlinks in the BitcoinABC 'blocks' directory for blocks before the split.

You also need to remember to specify the data directory when using the bitcoin-cli command. To prevent mistakes, I used simple shell scripts with different names to invoke the appropriate bitcoin-cli command.

Isn't using symlinks dangerious? Even only for the blocks directory? Both clients would write into the same directory and also same files. Before the fork they were identically, but after the fork they look different. So I'm not sure if this would mess up the data files?

I used file symlinks only for blocks before the split. Blocks processed after the split are unique to each directory. I used a simple shell script to create the symlinks. This really isn't necessary unless you are tight for space (I use a VPS where I pay for each GB of data).

If you are doing this after the split, don't copy blocks created after mid-July. And don't copy the blocks/index or chainstate directories. Don't copy peers.dat since BitcoinABC will have a different peer set. Instead, start BitcoinABC the first time with the -reindex parameter. This will recreate the blocks/index and chainstate directories. This is necessary since you didn't copy all of the existing blocks, thus invalidating the index and chain state.

I didn't want to take a chance on corrupting my Bitcoin wallet. So I sent all of my pre-split bitcoins to new addresses before installing BitcoinABC. When I cloned BitcoinABC, I did not copy wallet.dat. Instead, I imported the pre-split private keys into a new wallet and let it rescan the block chain to pick up the transactions.

Whether you use separate directories or separate userids is a personal choice. I prefer to manage all of the servers running on my VPS using a single account. Since I use accounts with no login passwords, this avoids having to manage multiple sets of login credentials on my workstation.

Ok, understood. You use symlinks directly to the files, not to the whole directory. Makes sense, I haven't thought about this.

And thanks for describing the way to split the chain after the fork.
Just in the case someone download a complete new version of the blockchain, it might get tricky to find the correct last common data file as all files would have more or less the same time stamp (+/- 1 or 2 days, depends on download and validation speed).