zoltanb (OP)
Member
Offline
Activity: 162
Merit: 24
|
|
September 18, 2017, 11:48:59 AM |
|
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?
|
|
|
|
HCP
Legendary
Offline
Activity: 2086
Merit: 4318
<insert witty quote here>
|
|
September 18, 2017, 12:24:14 PM |
|
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 (OP)
Member
Offline
Activity: 162
Merit: 24
|
|
September 18, 2017, 01:18:19 PM |
|
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
|
|
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.
|
|
|
|
zoltanb (OP)
Member
Offline
Activity: 162
Merit: 24
|
|
September 19, 2017, 02:54:02 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.
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
Legendary
Offline
Activity: 2128
Merit: 1073
|
|
September 19, 2017, 07:01:37 PM |
|
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
Member
Offline
Activity: 86
Merit: 26
|
|
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? 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 (OP)
Member
Offline
Activity: 162
Merit: 24
|
|
September 20, 2017, 08:31:18 AM |
|
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
|
|
September 20, 2017, 03:18:55 PM |
|
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
Activity: 86
Merit: 26
|
|
September 20, 2017, 03:49:37 PM |
|
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
Activity: 1610
Merit: 1183
|
|
September 20, 2017, 04:46:47 PM |
|
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
|
|
September 20, 2017, 10:41:00 PM |
|
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
Activity: 336
Merit: 250
There is a day to be born, and another to die
|
|
September 20, 2017, 11:51:35 PM |
|
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
Activity: 86
Merit: 26
|
|
September 21, 2017, 05:09:17 AM |
|
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
Activity: 2128
Merit: 1073
|
|
September 22, 2017, 05:32:26 PM |
|
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 (OP)
Member
Offline
Activity: 162
Merit: 24
|
|
September 22, 2017, 06:46:59 PM |
|
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
Member
Offline
Activity: 98
Merit: 10
|
|
November 13, 2017, 08:59:22 AM |
|
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 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 (OP)
Member
Offline
Activity: 162
Merit: 24
|
|
November 13, 2017, 10:51:22 AM |
|
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 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
Member
Offline
Activity: 98
Merit: 10
|
|
November 13, 2017, 10:16:47 PM |
|
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 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 -
|
|
|
|