TurtleCoin Mining Pool¶
Cryptocurrency miners will "pool" their GPU resources ("hashpower") into aggregate "mining pools", so that by the combined effort of all the miners, the pool will receive a reward for the blocks "mined" into the blockchain, and this reward will be distributed among the miners.
The end result is a mining pool which looks like this: https://trtl.heigh-ho.funkypenguin.co.nz/
WTF is a TurtleCoin and why do I want it?"
- Docker swarm cluster with persistent shared storage
- Traefik configured per design
- DNS entry for the hostnames (pool and api) you intend to use, pointed to your keepalived IP
- At least 16GB disk space (12GB used, 4GB for future growth)
Create user account¶
The TurtleCoin pool elements won't (and shouldn't) run as root, but they'll need access to write data to some parts of the filesystem (like logs, etc).
To manage access control, we'll want to create a local user on each docker node with the same UID.
The pool uses Redis for in-memory and persistent storage. This comes in handy for the Docker Swarm deployment, since while the various pool modules weren't designed to run as microservices, the fact that they all rely on Redis for data storage makes this possible.
Playing it safe
Be aware that by default, Redis stores some data only in memory, and writes to the filesystem at default intervals (can be up to 5 minutes by default). Given we don't want to loose 5 minutes of miner's data if we restart Redis (what happens if we found a block during those 5 minutes but haven't paid any miners yet?), we want to ensure that Redis runs in "appendonly" mode, which ensures that every change is immediately written to disk.
We also want to make sure that we retain all Redis logs persistently (We're dealing with people's cryptocurrency here, it's a good idea to keep persistent logs for debugging/auditing)
Create directories to hold Redis data. We use separate directories for future flexibility - One day, we may want to backup the data but not the logs, or move the data to an SSD partition but leave the logs on slower, cheaper disk.
1 2 3 4 5
Create /var/data/turtle-pool/redis/config/redis.conf using http://download.redis.io/redis-stable/redis.conf as a guide. The following are the values I changed from default on my deployment (but I'm not a Redis expert!):
1 2 3 4 5
I also had to disable the following line, by commenting it out (thus ensuring Redis container will respond to the other containers):
We'll run a simple Nginx container to serve the static front-end of the web UI.
The simplest way to get the frontend is just to clone the upstream turtle-pool repo, and mount the "/website" subdirectory into Nginx.
Edit /var/data/turtle-pool/nginx/website/config.js, and change at least the following:
Setup TurtleCoin daemon¶
The first thing we'll need to participate in the great and powerful TurtleCoin network is a node. The node is responsible for communicating with the rest of the nodes in the blockchain, allowing our miners to receive new blocks to try to find.
As of June 2018, the TurtleCoin daemon is not what you'd call "stable". Certain known circumstances (like unusual blocks) can cause the daemon to crash, and permanently corrupt its stored blockchain data. When (not if) this happens, the only solution is to delete all the stored blockchain data, and allow the daemon to resync (from checkpoints and then from other nodes). This resyncing process takes time, during which your miners can't mine. To partially mitigate this risk, we run 2 extra copies of the daemon, which we'll then start/stop at alternate intervals, so that in the event of a corruption of the daemon's data, we have hopefully-safe recent copies of the blockchain, allowing us to recover and restore quickly.
Create directories to hold the blockchain data for all 3 daemons:
1 2 3
Create cron entries (in /etc/cron.d/turtle-pool-failsafe) to start/stop the failsafe daemons:
1 2 3 4 5 6
Setup TurtleCoin wallet¶
Our pool needs a wallet to be able to (a) receive rewards for blocks discovered, and (b) pay out our miners for their share of the reward.
Create directories to hold wallet data
1 2 3 4 5
Now create the initial wallet. You'll want to secure your wallet password, so the command below will prompt you for the key (no output from the prompt), and insert it into an environment variable. This means that the key won't be stored in plaintext in your bash history!
After having entered your password (you can confirm by running
env | grep PASS), run the following to run the wallet daemon once, with the instruction to create a new wallet container:
1 2 3 4 5 6
You'll get a lot of output. The following are relevant lines from a successful run with the extra stuff stripped out:
1 2 3 4 5 6 7 8 9 10 11 12 13
Take careful note of your wallet password, public view key, and wallet address (which starts with TRTL)
Create /var/data/turtle-pool/wallet/config/wallet.conf, containing the following:
1 2 3 4 5 6 7
Setup TurtleCoin mining pool¶
Following the convention we've set above, create directories to hold pool data:
1 2 3
Now create /var/data/turtle-pool/pool/config/config.json, using https://github.com/turtlecoin/turtle-pool/blob/master/config.json as a guide, and adjusting at least the following:
Send logs to /logs/, so that they can potentially be stored / backed up separately from the config:
1 2 3 4 5 6
Set the "poolAddress" field to your wallet address
1 2 3 4
Add the "host" value to the api section, since our API will run on its own container, and choose a password you'll use for the webUI admin page
1 2 3 4 5 6 7 8 9
Set the host value for the daemon:
1 2 3 4
Set the host value for the wallet, and set your container password (you recorded it earlier, remember?)
1 2 3 4 5
Set the host value for Redis:
1 2 3 4
That's it! The above config files mean each element of the pool will be able to communicate with the other elements within the docker swarm, by name.
Setup Docker Swarm¶
Create a docker swarm config file in docker-compose syntax (v3), something like this:
I share (with my patreon patrons) a private "premix" git repository, which includes necessary docker-compose and env files for all published recipes. This means that patrons can launch any recipe with just a
git pull and a
docker stack deploy 👍
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145
Setup unique static subnets for every stack you deploy. This avoids IP/gateway conflicts which can otherwise occur when you're creating/removing stacks a lot. See my list here.
Launch the Turtle! 🐢¶
Launch the Turtle pool stack by running
docker stack deploy turtle-pool -c <path -to-docker-compose.yml>, and then run
"docker stack ps turtle-pool``` to ensure the stack has come up properly. (See troubleshooting if not)
The first thing that'll happen is that TurtleCoind will start syncing the blockchain from the bootstrap data. You can watch this happening with
docker service logs turtle-pool_daemon -f. While the daemon is syncing, it won't respond to requests, so walletd, the pool, etc will be non-functional.
You can watch the various elements of the pool doing their thing, by running
tail -f /var/data/turtle-pool/pool/logs/*.log
So how do I mine to it?¶
That.. is another recipe. Start with the "CryptoMiner" uber-recipe for GPU/rig details, grab a copy of xmr-stack (patched for the forked TurtleCoin) from https://github.com/turtlecoin/trtl-stak/releases, and follow your nose. Jump into the TurtleCoin discord (below) #mining channel for help.
What to do if it breaks?¶
TurtleCoin is a baby cryptocurrency. There are scaling issues to solve, and large amounts components of this recipe are under rapid development. So, elements may break/change in time, and this recipe itself is a work-in-progress.
Jump into the TurtleCoin Discord server to ask questions, contribute, and send/receive some TRTL tips!
Chef's Notes 📓¶
- Because Docker Swarm performs ingress NAT for its load-balanced "routing mesh", the source address of inbound miner traffic is rewritten to a (common) docker node IP address. This means it's not possible to determine the actual source IP address of a miner. Which, in turn, means that any one misconfigured miner could trigger an IP ban, and lock out all other miners for 5 minutes at a time.
Two possible solutions to this are (1) disable banning, or (2) update the pool banning code to ban based on a combination of IP address and miner wallet address. I'll be working on a change to implement #2 if this becomes a concern.
The traefik labels in the docker-compose are to permit automatic LetsEncrypt SSL-protected proxying of your pool UI and API addresses.
After a power fault in my datacenter caused daemon DB corruption, I added a second daemon, running in parallel to the first. The failsafe daemon runs once an hour, syncs with the running daemons, and shuts down again, providing a safely halted version of the daemon DB for recovery.
Tip your waiter (support me) 👏¶
Did you receive excellent service? Want to make your waiter happy? (..and support development of current and future recipes!) See the support page for (free or paid) ways to say thank you! 👏
Flirt with waiter (subscribe) 💌¶
Want to know now when this recipe gets updated, or when future recipes are added? Subscribe to the RSS feed, or leave your email address below, and we'll keep you updated. (double-opt-in, no monkey business, no spam either - check the archive for proof!)