need help to setup multichain, and switcher api

[BobZombiE69]

Can you please help me and guide me i need to setup btcpool and use "one click switcher" Switcher API Server for BTC, BCH, BSV

for every chain (BTC, BCH, BSV) : should i run one separate machine with all of these : blkmaker, jobmaker, gbtmaker, slparser, sharelogger, statshttpd, sserver

or can i run only one server, but with multi-chain configs like this:

sserver.cfg:

sserver = { type = "BTC"; .... } chains = ( { name = "btc"; .... }, { name = "bch"; .... }, ...... );

jobmaker.cfg:

job_workers = ( { chain_type = "BTC"; ... payout_address = "...my BTC address..."; }, { chain_type = "BCH"; .... payout_address = "...my BCH address..."; }, ..... );

blockmaker.cfg:

blk_makers = ( { chain_type = "BTC"; ... }, { chain_type = "BCH"; ... }, .... );

.......

or for every chain i should run different gbtmaker, slparser, and statshttpd if yes then on different machines ? or on the same machine but run from different folders ?

[SwimmingTiger]

Only sserver can contain multiple chains definitions at the same time. Use -DCHAIN_TYPE=BTC binary, set type = "BTC" in sserver section, then add name = "btc" and name = "bch" to chains section. It actually runs the BTC version of sserver (because sserver.type=BTC), but since the logic of the BCH version of sserver is exactly the same, you can use the same binary and you can switch the chains between BTC and BCH.

Other components (such as jobmaker) are completely different. The BCH version is significantly different from the BTC version (for example, the supported address formats are different, and the transaction signature method in generated coinbase is also different). Therefore, the binary of BTC cannot be used to mine BCH, so multi-chain cannot be implemented in a single binary. You need to build separate versions for different chains and put them in different directories.

These restrictions exist only in chains that have node source code dependencies (BTC/BCH/UBTC/LTC/ZCash). Other chains (ETH/Decred/Beam/Grin) are available in any build, but only guaranteed to be correct in BTC builds because they rely on uint256.h provided by BTC. Using alternative implementations in other node source code may have unexpected results, as these implementations are not necessarily exactly the same as BTC implementations.

So, you can actually run combinations like this in the jobmaker: BTC and ETH, ETH and ETC (The ETC option does not exist, chain_type can only be configured as ETH, and then ETC is supported by setting the chain_name option to CLASSIC), Grin and Beam...

BTC and BCH in the same configure file is not allowed (The code of chain_type=BCH does not exist in BTC build). In fact, sserver has exactly the same restrictions: it has only one sserver.type definition, and the BCH option does not exist in the BTC build.

The name field in chains section is not the type of blockchain, just the name tag and you can fill in any value. In the actual switchable deployment, we use BTC build, define the chain type of sserver as BTC, then add the BCH as the second custom name in the chains configuration section.

However, other components of the BCH must come from the BCH build, otherwise there may be an unknown consensus rule error and the block submission may fail.

[SwimmingTiger]

Further explanation: These limitations are due to the fact that there is only one source code for the processing of getblocktemplate mining, located in the src/bitcoin directory and shared by all blockchains using getblocktemplate.

We program with different blockchains by conditional compilation and statically link to the blockchain node's source code. So it is impossible to build a binary that supports both BTC and BCH, unless the BCH can directly handle by the BTC's binary (sserver is the case).