Tutorial Video
For this week’s post, I made a tutorial video where I show how to set up for the qPoS public testnet. It is an hour and a half long, but has plenty of information that could save at least that much time. I recommend watching it, and if you want to participate in the testnet, following along to set up a network node, or a StealthNode if you got on the list to be a StealthNode tester.
[VIDEO EMBEDDED HERE]
Server Specifications
Stealth qPoS is designed to deliver five second blocks, meaning that it can be demanding of the computer nodes that comprise the Stealth network. Because of these demands, qPoS network nodes (and especially the validating nodes, called StealthNodes) should run sufficient hardware to meet these demands. After working with the internal testnet for a few months, I came up with what I think should be the minimal resources for a well function qPoS public testnet node.
4 GB of RAM
2 dedicated virtual cores
10 GB free of SSD storage
Looking around, I found that a very good VPS option is the DigitalOcean CPU Optimized 4 GB server, as found at https://www.digitalocean.com/pricing/ and clicking the “CPU Optimized” tab. This VPS is $40/month. DigitalOcean has excellent servers, but they can be priced slightly higher than other companies that may offer similar machines. It may be worth the time to look around. Not all hosting providers are the same, so even though a server may have similar stats, it may not have similar performance. If in doubt, go with an established hosting provider with a good reputation.
Operating System
These instructions assume Ubuntu 16.04 or Ubuntu 18.04. Both are stable releases from one of the best Linux distributions available.
Minimally Hardening Your Server
VPS nodes typically are not “hardened” against common vulnerabilities, the most basic of which is brute force guessing an SSH password. You will want to do some basic hardening, which includes boils down to using SSH keys and not passwords.
To use SSH keys, perform the following steps:
Create the “~/.ssh” directory on the remote computer (the server running your Stealth qPoS node), using the “ssh-keygen” command. Take the defaults and don’t bother setting a password for this keypair, because you won’t use it. This command is a quick, easy way to properly create the “.ssh” directory on the remote machine.
Use the “ssh-keygen“ command to generate a public-private RSA keypair on your local machine. Leave the private key in your local machine (the computer at which you sit when you work, at home or in your office).
Copy the public key of the keypair made in Step 2 to a new file on the remote machine with the location and name “~/.ssh/authorized_keys”.
Edit the file “/etc/ssh/sshd_config” to contain the lines at https://gist.github.com/StealthSend/2b6cdda3ed5779623c122a4b63eddc2d. The video tutorial shows where to put these, if it is not obvious from inspecting the sshd_config file.
Restart the SSH service with the command “sudo service ssh restart”.
Ensure you can get into the server by SSH logging out of the remote machine then using SSH to get back in.
It’s also a good idea to remove the default web server that some hosting providers insist on including with their default configurations. Instructions are here: http://xmodulo.com/how-to-uninstall-and-remove-apache2-on-ubuntu-debian.html
Build the Daemon
Instructions for building the Stealth daemon for Ubuntu 16.04 and Ubuntu 18.04 are at the Stealth client repository wiki. You can simply copy-paste instructions in the respective Build the Daemon section. Don’t proceed past this section in the wiki.
Note that one command is designed to fail, and that is “git checkout NONEXTANT”. When that command fails, re-issue it with “NONEXTANT” replaced by “qpos-3.0”, that specifies the branch for the public qPoS testnet. So the command would be “git checkout qpos-3.0”.
For later convenience, strip the daemon from the source directory with the command “strip StealthCoind” and copy it to a central location. I copy to /usr/local/bin with the command “sudo cp StealthCoind /usr/local/bin”.
Configure the Server
To configure the server, generate the RPC user and password pair by running the StealthCoind executable (that should be in /usr/local/bin or similar). The command is simply “StealthCoind”.
This command will start with an error and tremendously helpful output. The two lines to look for start with “rpcuser” and “rpcpassword”. Using a true text editor like pico or vim, create a new file “~/.StealthCoin/StealthCoin.conf” and add those lines. Also add some other lines, to create a file similar to the one here: https://gist.github.com/StealthSend/8cc3afad9a4185d5f0cc2a2057880ab3
The command is “pico ~/.StealthCoin/StealthCoin.conf”. Edit in the terminal.
This will configure the daemon to run on testnet, as specified in the line “testnet=1”.
Encrypt Your Wallet and Back it Up
While not strictly necessary for testnet, it is a good idea to use the “encryptwallet” command to encrypt your wallets with a strong password. After the client shuts down, copy the encrypted wallet.dat in “~/.StealthCoin/testnet/wallet.dat” (testnet) or “~/.StealthCoin/wallet.dat” (mainnet) to a good backup location. For help, use the command “StealthCoind help encryptwallet”. To use your wallet after restarting the Stealth client, use the command “walletpassphrase”.
StealthNode Testers: Generate an Address and Pubkey
If you are a StealthNode tester, you will need to supply the team with a public key and StealthNode name. Coming up with a name is easy, but they must conform to the rules here: SDBS #7: Finishing up Registry Housekeeping and Starting Registry User Operations
Let’s call this node MYSTEALTHNODE herein.
Generating a public key is almost as easy. Simply issue the commands
StealthCoind getnewaddress
StealthCoind validateaddress ADDRESS
The address generated in the former command is substituted for the word “ADDRESS” in the latter command. We will refer to this address as ADDRESS in the remainder of this post. Additionally, the public key reported by the “validateaddress” command will be referred to PUBKEY.
Set Your Certified Node
Core network connectivity is greatly improved by setting a certified node using the “setstakermeta” RPC command. When the team sends you a StealthNode for the testnet, we will also send a few testnet XST for transaction fees and experimentation. First, send yourself enough for a transaction fee with the command:
StealthCoind sendtoaddress ADDRESS 0.01
This command will create a transaction identifier we will call TXID_1. Transaction identifiers are length 64 pseudo-random strings of the characters a-f and 0-9.
You need to figure out how to reference this 0.01 XST by issuing the command
StealthCoind gettransaction TXID_1
Remember you are substituting the real 64 character transaction identifier for “TXID_1” in this command.
Find the “vout” index of the 0.01 XST to the ADDRESS generated above in the “getnewaddress” command. Note the number keyed by “n”. This number will be either “0” or “1”. We will call this index VOUT_1.
Now find what your Tor hostname is with the command
cat ~/.StealthCoin/testnet/onion/hostname
It should take the form of a 16 character address followed by “.onion”. We’ll call this HOSTNAME.
The command to set the certified node would then be
StealthCoind setstakermeta TXID_1 VOUT_1 MYSTEALTHNODE certified_node HOSTNAME
Enable Your StealthNode
If you are a StealthNode tester, Your StealthNode comes disabled from the team. You need to enable it to start earning, using the command “enablestaker”. It is recommended to enable it before testnet starts. This process is similar to the steps above for setting your certified node address with the command “setstakermeta”. Briefly the steps are
Issue the command “sendtoaddress ADDRESS 0.01”
Note the transaction identifier, we will call this one TXID_2
Get the index for the vout with the command “gettransaction TXID_2”. We’ll call this index VOUT_2.
Issue the command “enablestaker TXID_2 VOUT_2 MYSTEALTHNODE”
After the transaction confirms (within a few minutes at most), you can check your staker is enabled with the “getqposinfo” command.
RPC Commands
For completeness, a list of all qPoS related RPC commands follow.
claimqposbalance <txid> <vout> <amount>
disablestaker <txid> <vout> <alias>
enablestaker <txid> <vout> <alias>
exitreplay
getqposbalance <pubkey>
getqposinfo
getstakerid <alias>
getstakerinfo <alias>
getstakerprice
purchasestaker <txid> <vout> <alias> <owner> [amount] [delegate controller payout]
setstakercontroller <txid> <vout> <alias> <controller>
setstakerdelegate <txid> <vout> <alias> <delegate> <payout>
setstakermeta <txid> <vout> <alias> <key> <value>
setstakerowner <txid> <vout> <alias> <owner> iunderstand
Except for “exitreplay”, these RPC commands are detailed in SDBS #10 and SDBS #21. The “exitreplay” command is useful in certain testnet situations, and will probalby never be used by non-developers.