Bitcoin Forum
October 19, 2018, 02:37:31 PM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Bitcoin core and Bitcoin ABC on the same Linux machine  (Read 1105 times)
zoltanb
Member
**
Offline Offline

Activity: 119
Merit: 12


View Profile WWW
September 18, 2017, 11:48:59 AM
 #1

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?

Cointessa.com - https://www.cointessa.com/ - easy bitcoin buying via SEPA and national bank transfers
Coinvertit.com - https://www.coinvertit.com/
Buy and Sell Digital Currency Safe and Easy via SEPA bank transfers in Europe or national bank transfers in Romania
1539959851
Hero Member
*
Offline Offline

Posts: 1539959851

View Profile Personal Message (Offline)

Ignore
1539959851
Reply with quote  #2

1539959851
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
HCP
Hero Member
*****
Offline Offline

Activity: 756
Merit: 932

<insert witty quote here>


View Profile
September 18, 2017, 12:24:14 PM
 #2

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
Member
**
Offline Offline

Activity: 119
Merit: 12


View Profile WWW
September 18, 2017, 01:18:19 PM
 #3

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?

Cointessa.com - https://www.cointessa.com/ - easy bitcoin buying via SEPA and national bank transfers
Coinvertit.com - https://www.coinvertit.com/
Buy and Sell Digital Currency Safe and Easy via SEPA bank transfers in Europe or national bank transfers in Romania
ScripterRon
Full Member
***
Offline Offline

Activity: 136
Merit: 106


View Profile
September 19, 2017, 02:51:59 PM
 #4

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
Member
**
Offline Offline

Activity: 119
Merit: 12


View Profile WWW
September 19, 2017, 02:54:02 PM
 #5

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.

Cointessa.com - https://www.cointessa.com/ - easy bitcoin buying via SEPA and national bank transfers
Coinvertit.com - https://www.coinvertit.com/
Buy and Sell Digital Currency Safe and Easy via SEPA bank transfers in Europe or national bank transfers in Romania
2112
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
September 19, 2017, 07:01:37 PM
 #6

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.

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
Kogs
Member
**
Offline Offline

Activity: 86
Merit: 12


View Profile
September 20, 2017, 06:56:24 AM
 #7


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
Member
**
Offline Offline

Activity: 119
Merit: 12


View Profile WWW
September 20, 2017, 08:31:18 AM
 #8

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

Cointessa.com - https://www.cointessa.com/ - easy bitcoin buying via SEPA and national bank transfers
Coinvertit.com - https://www.coinvertit.com/
Buy and Sell Digital Currency Safe and Easy via SEPA bank transfers in Europe or national bank transfers in Romania
ScripterRon
Full Member
***
Offline Offline

Activity: 136
Merit: 106


View Profile
September 20, 2017, 03:18:55 PM
 #9


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
Member
**
Offline Offline

Activity: 86
Merit: 12


View Profile
September 20, 2017, 03:49:37 PM
 #10


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
Legendary
*
Offline Offline

Activity: 1386
Merit: 1052


View Profile
September 20, 2017, 04:46:47 PM
 #11

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
Full Member
***
Offline Offline

Activity: 136
Merit: 106


View Profile
September 20, 2017, 10:41:00 PM
 #12

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
Sr. Member
****
Offline Offline

Activity: 336
Merit: 250

There is a day to be born, and another to die


View Profile
September 20, 2017, 11:51:35 PM
 #13

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
Member
**
Offline Offline

Activity: 86
Merit: 12


View Profile
September 21, 2017, 05:09:17 AM
 #14

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
Legendary
*
Offline Offline

Activity: 2114
Merit: 1027



View Profile
September 22, 2017, 05:32:26 PM
 #15

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... Smiley
Also, don't forget about "rpcport"!

Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0
Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0
zoltanb
Member
**
Offline Offline

Activity: 119
Merit: 12


View Profile WWW
September 22, 2017, 06:46:59 PM
 #16

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... Smiley
Also, don't forget about "rpcport"!


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

Cointessa.com - https://www.cointessa.com/ - easy bitcoin buying via SEPA and national bank transfers
Coinvertit.com - https://www.coinvertit.com/
Buy and Sell Digital Currency Safe and Easy via SEPA bank transfers in Europe or national bank transfers in Romania
Lyddite
Member
**
Offline Offline

Activity: 97
Merit: 10



View Profile
November 13, 2017, 08:59:22 AM
 #17

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.

- Lyddite -
zoltanb
Member
**
Offline Offline

Activity: 119
Merit: 12


View Profile WWW
November 13, 2017, 10:51:22 AM
 #18

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?

Cointessa.com - https://www.cointessa.com/ - easy bitcoin buying via SEPA and national bank transfers
Coinvertit.com - https://www.coinvertit.com/
Buy and Sell Digital Currency Safe and Easy via SEPA bank transfers in Europe or national bank transfers in Romania
Lyddite
Member
**
Offline Offline

Activity: 97
Merit: 10



View Profile
November 13, 2017, 10:16:47 PM
 #19

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.

- Lyddite -
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!