PoS testing brain dump
Some random thoughts about testing on the Crown PoS testnet.
I generally assume testers are somewhat familiar with setting up systemnodes/masternodes because in the Crown PoS implementation only nodes stake. There are PoS testnet install/upgrade instructions at https://gitlab.crown.tech/walkjivefly/crown-core/snippets/5 which are very similar to the normal SN/MN installation instructions in the Crown forum (https://forum.crown.tech/index.php?topic=7705.0 and https://forum.crown.tech/index.php?topic=7706.0)
There is no formal testing plan. Test anything you can think of. Some possibilities are:
- node creation
- startup, shutdown and operation
- normal sends
- instant sends
- to yourself and others
- proposal preparation and submission
- proposal voting
- obviously make sure you're receiving node rewards and stake rewards. On testnet they are respectively 4.5, 0.9 and 3.6 tCRW.
- take a look at your nodes' debug.log files. If you see errors please follow the instructions below...
What to do if you find a problem
If you encounter a problem please mention it in the Discord #testing-mn-pos channel and/or check if it has already been reported in Gitlab https://gitlab.crown.tech/crown/crown-core/issues If the problem has not been reported yet, and you know how to, please open a new issue for it.
Block generation times
The block time on testnet is 90 seconds instead of 60. If you think there's an issue with the block generation times you can get an idea of the timing by:
cd .crown/testnet3 grep UpdateTip debug.log
This will show you the times your node received blocks which is usually a close approximation to when they were generated. If you look to the right end of each line you can see the actual block generation times.
Checking node status
Here's a little script check_node that you can install on your node by:
wget https://gitlab.crown.tech/uploads/-/system/personal_snippet/6/ee556560c50b296355bd6ebb2bd6dcab/check_node chmod +x check_node sudo mv check_node /usr/local/bin
You can run it remotely by something like:
ssh pmn01 check_node label
where label is something to remind you which node you're checking. I expect there's a PuTty equivalent, but don't do winbloze so don't know what it is. It reports the protocol version, node current block height, masternode or systemnode status text and staking status.
If you have a bunch of nodes you can simplify checking the status of all of them by adapting this script checkpos. Edit the list of node names to suit your ssh configuration, stick it somewhere in your path and run it whenever you feel curious. The checkpos script runs check_node on each node, eg:
mark@x230:~/bin$ checkpos morra1: 27988 - Masternode successfully started - "staking_active" : true, morra2: 27988 - Masternode successfully started - "staking_active" : true, pmn01: 27988 - Masternode successfully started - "staking_active" : true, pmn02: 27988 - Masternode successfully started - "staking_active" : true, ...
It can also send an additional command when required, eg:
mark@x230:~/tmp$ checkpos crown-cli getblockhash 27929 morra1: 27974 - Masternode successfully started - "staking_active" : true, 460b4c9ccab49e121740826dca5c7db73884b41028fc3070e53c193e0ee3b7aa morra2: 27974 - Masternode successfully started - "staking_active" : true, 460b4c9ccab49e121740826dca5c7db73884b41028fc3070e53c193e0ee3b7aa ...
The additional command can be anything you like but the script is super simple. It doesn't do anything clever with the arguments so shell processing might mean some commands don't work as expected. You might have to get creative with quoting and escape characters!
Check which version of the code you're running and/or when the node was (re-)started
grep "Crown version" ~/.crown/testnet3/debug.log
You need this info if you open an issue in Gitlab and use the standard bug template. If you installed the node using the pos-server-install.sh script this grep might well return no results because...
pos-server-install.sh configures logrotate to rotate debug.log and instantsend.log daily to try to prevent storage exhaustion. logrotate is configured to rename and compress upto 4 days worth of logs. If you don't find what you're looking for in debug.log you can use gunzip to uncompress previous logs.
If you restart a node it is possible to lose debug.log information because by default Crown uses
which truncates debug.log if it larger than 10MB (iirc) at startup. To prevent this you can configure
shrinkdebugfile=0 in crown.conf
How big is testnet?
You can get the answer from the GUI wallet masternode and systemnode tabs, but if you're not a GUI wallet user you can
crown-cli masternode count crown-cli systemnode count
Actually, you can use crown-cli commands even if you are a GUI wallet user.
Simplifying access to testnet wallet when it shares a machine with your normal wallet
Create an alias or shell script for each of the commands you want to use. For example I have these aliases:
alias pcrowncli='/home/mark/.crownpos/bin/crown-cli -testnet -conf=/home/mark/.crownpos/crownpos.conf -datadir=/home/mark/.crownpos' alias pcrownd='/home/mark/.crownpos/bin/crownd -testnet -conf=/home/mark/.crownpos/crownpos.conf -datadir=/home/mark/.crownpos' alias pcrownqt='/home/mark/.crownpos/bin/crown-qt -testnet -conf=/home/mark/.crownpos/crownpos.conf -datadir=/home/mark/.crownpos'
so I can easily
pcrowncli sendtoaddress tWherever loadsadosh pcrowncli mnbudget nextblock