Create Komodo Testnet

[jmjatlanta]

Possible solution for #519

This fix

• Lowers the PoW threshold for testnet to be equal to mainnet
• Provides a valid solution for the genesis block
• Sets testnet coin name to TKMD

ToDo:

• komodo.conf shared for both mainnet and testnet if no -conf parameter passed (perhaps testnet should look in "testnet3" directory instead?)
• komodostate file shared (overwritten) for both mainnet and testnet if no -datadir parameter passed (perhaps should look in "testnet3" directory instead?)
• .komodo directory attached too many times in some cases (i.e. looks for ".komodo/.komodo/komodostate")
• No faucet - perhaps something automated to make it easy for developers to get some TKMD to play with
• Only 1 seed node - The more the better
• Notaries shared between mainnet and testnet. This should be fixed to allow for testing notary functionality
• Document and modularize better the chainparams.cpp for each derivative chain. The MYCHAIN repository could customize their chainparams.cpp to their liking and simplify command line parameters and config file settings.

[dimxy]

I think if a testnet is started with no ac_name param it should have KMD name (bcz if we use it for testing like notarization apps, they rely on the main chain as 'KMD', I believe), or it should have the ac_name, if it is set.
Basically it should allow to start a copy of KMD or an asset chain with a different difficulty and a set of seeds

[jmjatlanta]

I would like to discuss the pros and cons of a Testnet. My views are:

Pros:

• Testing of specific areas
  • Notarization (including to tBTC/tLTC)
  • all of the if (ASSETCHAIN_NAME[0] == 0) logic
  • Hardforks
  • Gateway
• No chance of losing value

Cons:

• Maintenance
  • faucet / mining
  • versioning
• disk space
• If a new token name is chosen, existing code that relies on mainnet settings will need adjustment

As for the token name, I would strongly prefer something other than KMD, as that introduces the chance of someone losing value if accidentally hooking to the wrong wallet and such. Would TKMD work?

I look forward to comments, and will update the list above based on responses.

I will also make an unofficial testnet and post the seed here if I get it working. This will be a side project, so turn-around times will be slow.

[dimxy]

I would like sometimes to have a KMD testnet, for example to develop and test the gateways cc (where KMDs are deposited on a gateways address to issue the equivalent amount of tokens in an assets chain). But for this use case it should be an exact replica of the original main KMD chain, including the name (and there are several on-chain services, including notarisation, that work differently depending on if this is the KMD or an assets chain - and "KMD" string is often used for that)

I also remember an advice in the docs that if one needs a testnet he may create an assets chain for this.

[jmjatlanta]

This is a suggestion:

The string "KMD" means "the coin" as well as "the chain that notarizes". Can we break that link? "KMD" can be the coin, and "the chain that notarizes" can be computed via a method call.

Instead of ASSETCHAINS_NAME[0] == 0 we can have methods that answer the exact question we are asking.

std::string CChainParams::NotarizingCoin() { return ASSETCHAINS_NAME.empty() ? strParentCoin : strCurrencyUnits; }
std::string CChainParams::ThisChainCoin() { return ASSETCHAINS_NAME.empty() ? strCurrencyUnits : ASSETCHAINS_NAME; }
bool CChainParams::IsNotarizingChain() { return ThisChainCoin() == strCurrencyUnits; }
bool CChainParams::IsAssetChain() { return !IsNotarizingChain(); }
bool CChainParams::IsNotarizingCoin(const std::string& coin) { return coin == NotarizingCoin() || coin == strCurrencyUnits; }
bool CChainParams::IsThisChainCoin(const std::string& coin) { return coin == ThisChainCoin(); }

(the above assumes we migrate ASSETCHAINS_NAME to a std::string, and it is still a global. It also assumes that strParentCoin is set to the coin used to verify Komodo's transactions (i.e. "BTC" or "LTC" in the case of Mainnet )

I am asking for verification/standardization in terminology.

• An "Asset Chain" is
  • A chain that uses komodo software, and utilizes the -ac_name command-line parameter
• A "Notarizing Chain" is
  • a chain that can notarize "child" asset chains
  • a chain that may rely upon the hashing power of a "parent" chain to validate its own transactions
  • a chain that may or may not use Komodo core
• "KMD" is a coin.
• "Komodo Mainnet" is the home of the KMD coin and is also a notarizing chain, currently using Litecoin Mainnet as a parent.
• "LTC" is a coin.
• "Litecoin Mainnet" is both a notarizing chain with no parent, and the home of the LTC coin.

That allows for:

• "TKMD" is a coin.
• "Komodo Testnet" is the home of the TKMD coin and is also a notarizing chain, soon to be using the Litecoin Testnet as a parent.
• "JMJATLANTA" is a coin.
• JMJATLANTA Mainnet is the home of JMJATLANTA coin and is an asset chain that uses Komodo Mainnet as a parent.
• "JMJTEST" is a coin.
• JMJAtlanta Testnet is the home of JMJTEST coin and is an asset chain that uses Komodo Testnet as a parent.

I am not asking that we standardize on MY terminology. Tweak it if necessary. I am asking that we clarify the code by

• Stop hard-coding KMD or relying on ASSETCHAINS_NAME[0] == 0 in a myriad of places.
• Ask the appropriate questions (i.e. call the appropriately named method) that make the intent clear
  • Variable / member / function names should reflect a standardized terminology to allow for clear intent to be shown.
  • Comments should reflect approved/standardized terminology when possible

With such changes implemented throughout core, things like the gateway code work on Komodo Mainnet and any other chain without modification. It is then fairly easy to write often write self-documenting code:

• a particular coin belongs to this chain (IsThisChainCoin("Blah"))
• a particular coin is the coin of the parent chain (IsNotarizingCoin("Blah"))
• this chain is an asset chain (IsAssetChain()) or a notarizing chain (IsNotarizingChain())

NOTE: CChainParams may not be the appropriate place for the pseudo-code above. A higher layer may be more appropriate to separate dynamic state (ASSETCHAINS_NAME, even strParentCoin) from static/const (strCurrencyUnits).

[dimxy]

I heartily support this idea - to make methods and global vars into ChainParams, it's a good place.
We need to decide on conceptual points yet. (F.e. IsNotarisingChain as the opposite of IsAssetsChain a bit embarrasses me as the whole notarisation service is optional but maybe this is okay).
My addition to this is to create a dedicated ChainParams object for asset chains where f.e. we could set a different set of seeds for a chain and this also may help to create a method for determining the current chain type

[jmjatlanta]

I heartily support this idea - to make methods and global vars into ChainParams, it's a good place. We need to decide on conceptual points yet. (F.e. IsNotarisingChain as the opposite of IsAssetsChain a bit embarrasses me as the whole notarisation service is optional but maybe this is okay).

^ That may just be my concept of how things work. By you saying that shows a gap in my knowledge. We'll sort it out.

My addition to this is to create a dedicated ChainParams object for asset chains where f.e. we could set a different set of seeds for a chain and this also may help to create a method for determining the current chain type

So ChainParams is the base class with the basics. We derive from that and supply our own values. In the case of Komodo Mainnet or Testnet, they are derived classes (children of ChainParams). In the case of asset chains, they can make their own class (a child of ChainParams) or use a class that gets built based on config file / command line parameters. Am I following your idea correctly?

[dimxy]

In the case of asset chains, they can make their own class (a child of ChainParams) or use a class that gets built based on config file / command line parameters. Am I following your idea correctly?

yes there are 2 options I think:

• just have a dedicated ChainParams instance for all assets chains. At least we can remove kmd seeds from it, put global vars like ASSETCHAIN_SYMBOL and create functions like you described in ChainParams
• an even better option is to have a dedicated ChainParams for each asset chain and have in there all asset chain's cmd line params, checkpoint data. So we could avoid multiple if (strcmp(ASSETCHAINS_SYMBOL,"SOMECHAIN") == 0) in the codebase

[jmjatlanta]

I have made some changes to the codebase to get -testnet working. It is deployed on my public server. If you compile this branch you should be able to connect to it, mine TKMD, and so forth.

I did not modify the collection of notaries. I want to work on that next, so we can test any notarization changes by merging them into the testnet branch and deploying it.

Here are the details if you want to give it a shot:

What I changed:

• Made the token TKMD
• Added the correct solution to the genesis block
• emptied the checkpoint data
• added my public node to the seed list

Startup parameters: ./komodod -testnet or if you wish to devote 1 thread to mining: ./komodod -testnet -gen -genproclimit=1

[jmjatlanta]

The testnet now has 1 notary (one of my nodes). Hardforks are still there, with their dates and heights unadjusted.

The next step will be how to handle hardfork dates/heights between the two chains.

The idea was that when we get an official testnet branch, the komodo_hardfork.cpp file can be modified within that branch, and code changes within that file will be rare. The advantage was upgrading testnet with code changes will almost always have no conflicts and testnet node upgrades would be fairly straightforward. The disadvantage was that regular nodes starting the daemon with the -testnet parameter will not have the correct hardfork dates.

So the debate is: which is easer?

1. Switch branches and recompile to connect to testnet (disable the -testnet parameter)
2. Ask CChainParams for hardfork dates and notaries

Chosing option 2 means we need to maintain those items for mainnet, testnet, and regtest in 1 codebase. My current opinion is that should not be too difficult. Mainnet and regtest could probably share the same set, and testnet have its own. I look forward to the opinions of others.

[tonymorony]

these changes implemented in combined PR: #559