Bitcoin core and Bitcoin ABC on the same Linux machine

[zoltanb]

How would one run both Bitcoin Core (BTC) and Bitcoin ABC (BCH) on the same linux server?
When you download Bitcoin ABC it will overwrite Bitcoin Core. What is the best way to handle both on the same server?

[1714009268]

1714009268

[1714009268]

1714009268

[1714009268]

1714009268

[1714009268]

1714009268

[1714009268]

1714009268

[HCP]

Does it not give you the option to select where to install it on Linux? On Windows you can select the install directory during the install process... so that it does not overwrite the application.

Also, it allows you to select a "data directory" on first setup... or you can specify it on the commandline (or in bitcoin.conf)... so that the blockchain is not overwritten.

[zoltanb]

Does it not give you the option to select where to install it on Linux? On Windows you can select the install directory during the install process... so that it does not overwrite the application.

Also, it allows you to select a "data directory" on first setup... or you can specify it on the commandline (or in bitcoin.conf)... so that the blockchain is not overwritten.

On a CentOS, I can not select a data directory on install.
Also, I assume I still need to change ports as well, wrong?

[ScripterRon]

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.

[zoltanb]

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.

Can you post a simple step by step guide on how to install Bitcoin ABC from the tar file if Bitcoin Core is already installed? Thanks in advance.

[2112]

Guys, Linux is a multiuser system.

Just create additional user accounts, one each for each coin. They won't step on each other files. The only thing you will have to worry is to set each of the Bitcoin forks to run on a separate network ports, because each of them will try to claim ports 8332 and 8333 for themselves.

If you are thoughtful about setting up user permissions you will be safe even if you accidentally install trojaned software, because they will have no access to each other wallets.

No need to play with tar files or other non-default installation methods.

Same thing is true for Windows and macOS.

[Kogs]

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?

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?

[zoltanb]

Thank you. What is the correct config line in bitcoin.conf to set a different port than 8333? Can't seem to find it.
Later edit: found it, it is port=12345...

[ScripterRon]

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?

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.

[Kogs]

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?

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).

[pereira4]

Call me paranoid, but I got my laptop to sync the damn thing (Bitcoin ABC) because there's no way im going to compromise my main machine with dodgy software, specially coming from the hands of Dr Craig Wright himself and the rest of scammers.

Im going to leave that laptop (which contains no relevant information or anything of value) to install all the failed hardfork attempt clients in order to sync the chain and dump the coins for free BTC.

[ScripterRon]

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).

That's true.  I think stopping at blk00925.dat and rev00925.dat would be safe.  They were last updated on 7/6/2017 on my system.  There will be some variation in the .dat files depending on the number of orphan blocks encountered, but that should be early enough that all blocks would be before the split.

[suppersz]

Call me paranoid, but I got my laptop to sync the damn thing (Bitcoin ABC) because there's no way im going to compromise my main machine with dodgy software, specially coming from the hands of Dr Craig Wright himself and the rest of scammers.

Im going to leave that laptop (which contains no relevant information or anything of value) to install all the failed hardfork attempt clients in order to sync the chain and dump the coins for free BTC.

yeah I agree, no way I am installing Bitcoin ABC anywhere near anything sensitive. At least use a vm or something

[Kogs]

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).

That's true.  I think stopping at blk00925.dat and rev00925.dat would be safe.  They were last updated on 7/6/2017 on my system.  There will be some variation in the .dat files depending on the number of orphan blocks encountered, but that should be early enough that all blocks would be before the split.

Can confirm, blk0925.dat has also been last updated on 7/6/2017 on my system.

[2112]

Thank you. What is the correct config line in bitcoin.conf to set a different port than 8333? Can't seem to find it.
Later edit: found it, it is port=12345...

Also, don't forget about "rpcport"!

[zoltanb]

Thank you. What is the correct config line in bitcoin.conf to set a different port than 8333? Can't seem to find it.
Later edit: found it, it is port=12345...

Also, don't forget about "rpcport"!

Thanks. However, rpcport is only used if you need JSON-RPC, I do not need it.

[Lyddite]

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).

That's true.  I think stopping at blk00925.dat and rev00925.dat would be safe.  They were last updated on 7/6/2017 on my system.  There will be some variation in the .dat files depending on the number of orphan blocks encountered, but that should be early enough that all blocks would be before the split.

Can confirm, blk0925.dat has also been last updated on 7/6/2017 on my system.

Some helpful info here. Thanks!

Wish I thought about using symlinks earlier. :-) I ended up setting up btrfs and using

Code:

cp --reflink=always /home/bitcoind/.bitcoin/blocks/blk* /home/bitcoinabc/.bitcoin/blocks/

Getting more experience with copy on write filesystems doesn't hurt.

[zoltanb]

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).

That's true.  I think stopping at blk00925.dat and rev00925.dat would be safe.  They were last updated on 7/6/2017 on my system.  There will be some variation in the .dat files depending on the number of orphan blocks encountered, but that should be early enough that all blocks would be before the split.

Can confirm, blk0925.dat has also been last updated on 7/6/2017 on my system.

Some helpful info here. Thanks!

Wish I thought about using symlinks earlier. :-) I ended up setting up btrfs and using

Code:

cp --reflink=always /home/bitcoind/.bitcoin/blocks/blk* /home/bitcoinabc/.bitcoin/blocks/

Getting more experience with copy on write filesystems doesn't hurt.

I am not sure exactly what do you do with the above command?

[Lyddite]

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).

That's true.  I think stopping at blk00925.dat and rev00925.dat would be safe.  They were last updated on 7/6/2017 on my system.  There will be some variation in the .dat files depending on the number of orphan blocks encountered, but that should be early enough that all blocks would be before the split.

Can confirm, blk0925.dat has also been last updated on 7/6/2017 on my system.

Some helpful info here. Thanks!

Wish I thought about using symlinks earlier. :-) I ended up setting up btrfs and using

Code:

cp --reflink=always /home/bitcoind/.bitcoin/blocks/blk* /home/bitcoinabc/.bitcoin/blocks/

Getting more experience with copy on write filesystems doesn't hurt.

I am not sure exactly what do you do with the above command?

Basically, if using a filesystem that supports copy-on-write... the file system uses the same file for the files in both places (like a symlink, without using more space except for metadata) until one of the files is changed. When one of the files is changed a new copy could be made or the difference between the files could be stored depending on the filesystem or settings.