Feature Story

That’s It, Old Nodes Have Got To Go!

Ever wonder when your node is syncing why it jumps back and forth between 2 days and 2 months behind? Yeah, we’ve had enough of that too.

It’s Time We Clean Up the Town!

We take network upgrades very seriously here at TurtleCoin. We want the network to be as safe, easy, and secure as possible for our Turtle brethren. We do our best to test all changes and make sure that our fellow Turtle are given plenty of time to upgrade their software before a change takes effect. Unfortunately… not everyone upgrades when necessary.

Running Legacy Software

We attempt to provide everyone ample notice before upgrades occur, what the upgrades will do, and how they benefit the network. However, not every Turtle visits the TurtleCoin discord, checks the GitHub repo, or watches the various forms of social media we have.

There are uncountable nodes running around on the network playing by antiquated network rules disrupting the network and causing utter chaos at times. When Turtles run old software it causes a variety of issues, including but not limited to the following:

  • Slower syncronization as the out of date nodes attempt to push blocks that don’t match the current network rules
    • Your node has to waste time checking their block and finding out it doesn’t fit the mold before the connection is dropped. Then your node has to find a new peer to hopefully get the correct block(s) from
  • The daemon must store old alternative chains in memory in the event that they one day resolve (highly unlikely)
    • This results in the blockchain wasting space on your system
  • Your log is filled with messages about unexpected hashes, failed hashes, etc.
  • Many other issues we don’t know about yet

The Solution

TurtleCoin v0.8.3 implements a new version checking mechanism that starts the process of checking the version of peer software when trying to exchange blockchain data. When we connect to a peer, or a peer connects to us, the version of the peer is compared against a minimum version that is supported. If the peer is not at or above that minimum version, the connection is dropped. This helps us to ensure seamless network upgrades in the future that aren’t cluttered by those that do not keep their software updated.

Note: Version 0.8.3 does not perform this purge of old nodes, it merely sets the stage for the event in future release(s).

We’ve also added additional log messages that warn you when you may be out of date (as you’re seeing nodes with higher versions than the one you’re running). If you see such a message, as always head over to to make sure you have the latest version of the software.

Future Purges

The development team aims to utilize this feature for soft forks that are the result of a mining algorithm change, difficulty algorithm change, or any other event that requires that the project to implement a soft fork.

Such a strategy helps us maintain the security of the network by alterting our fellow Turtles of upgrades and keeping legacy nodes off the network.

Thanks, No, Seriously, Thanks

We appreciate everyone that runs a node on the network, public, private, or some mix in between. It helps the stability of the network and shows everyone that we are here to stay. However, if you are one of the people running an ancient copy of TurtleCoin, please upgrade to v0.8.3 and all future releases within the posted ugprade window in the version release notes. You’ll help the community out considerably.


Feature Story

Running A Public Node For Fun & Profit: Part Deux

Make it Rain Yo!

Hopefully you’ve read Part 1 of this series of articles and already have your public node up and running. If not, we highly suggest you head over there and give it a read before continuing with this article.

Note: To make sure that you’ve read this document before proceeding, you won’t be able to copy and paste any of the commands.

What Next?

Running a public node that the community can use can be challenging at times. 100% uptime is great but that’s not always possible in some environments. Running a public node takes work. Despite our best efforts right now, we can’t just Set it and Forget it.

We can; however, use some cool tools developed by the community to help make it easier to maintain a public node. We’ll take a look at how to do this below.

TurtleCoind High Availability Daemon Wrapper

This project is designed to wrap the TurtleCoind daemon on a system and monitor it for hangups, locks, fork, or other events that cause the daemon to stop responding to requests in an accurate manner.

The wrapper does its best to keep TurtleCoind running in tip top shape and always responding to requests from your users. Follow the directions below to set it up on your system. We’ve included instructions below designed to work on a your favorite flavour of *nix variants.

Node.js Setup

You’re going to need a newer version of Node to get things started. Use of any of the older v0.x releases hasn’t been supported for a while so don’t even bother trying to use those. If you are not sure what version of Node.js is installed on your system (if at all), simple run the below command:

Hopefully you’ll see something relatively modern come back like version 8:

If not, head on over to Installing Node.js via package manager for instructions on how to install the latest version for your distro.

Once you’ve completed that step and have verified you are running an up-to-date copy, we’ll continue on below.

Setting up PM2

Setting it up from here is pretty easy going forward. We’ll start by installing PM2: Advanced, production process manager for Node.js to help keep our node script running 24/7/365 and persist across system reboots.

To do so, we’ll run the following commands:

If everything completes successfully, we’ll have the PM2 process up and running and ready to run our script.

Image result for saran wrap fail gif

Setting up the Wrapper

The turtlecoind-ha package is registered with NPM, so installation is pretty easy. We’ll create a new directory for our process to live in and install it there.

After a few moments, the package will download and install with all the needed dependencies. As long as the installation finishes with the line(s) like those below you are good to proceed.

Next, we’re going to create a new file in our folder named turtlenode.js and dump the code below into that file. We’ve linked to the raw code here.

Most of the code above is designed for spitting us understand what’s going on with our node at any given time. For education purposes, we’re going to leave that intact.

We want to pay attention to the section above that initializes the node parameters.

You’ll need to change those values to match the TurtleCoin address you’re using to collect your node convenience charges as well as the amount of that fee. Remember, as stated in Part 1 of this series, the fee amount is expressed in shells or “atomic units” not TRTL.

Once we’ve made the necessary changes, we’ll save that file and we’re almost ready to rock and roll.

Prepping the Node

For maximum ease of setup you’ll need to copy the latest version of TurtleCoind for your system into the directory we created above. You can compile your own, or download the latest release binaries from the TurtleCoin GitHub repository.

We also advise that you download the latest checkpoints from the Offical Repo to help your node sync up as quickly as possible. The following command will make this quick and easy for you.

Testing the Node

Now that we have all of that set up and ready to rock and roll, we’ll test our node to make sure everything is set up correctly.

Run the following command to find out if everything will start up correctly.

If all goes well, you’ll see output like this:

Depending on if you’ve ever synced a daemon on this machine – it could take a while. Don’t fret if that’s the case. We can continue with even an unsyncronized daemon.

As long as we see TurtleCoind has started followed by TurtleCoind is attempting to synchronize with the network… we know that we’ve set up our environment correctly. Press CTRL-C to stop the node from running. We’re ready to hand off control to PM2.

Launching the Node

Handing off control to PM2 is pretty simple. To do so enter the following command(s):

Checking the Node

To verify that the node is running, we can issue the following command:

PM2 will spit back a list of processes maintained by the software such as:

To view our node logs, issue the command:

Once your node is synced, you’ll start to see log entries such as:

Now sit back, relax, and let people know about your public node.

Feature Story

Introducing CryptoNight Soft Shell


To provide the next generation PoW algorithm for TurtleCoin that accomplishes the following goals:

  • Must be a PoW that is different than any other PoW algorithm deployed by another blockchain.
  • Provides additional ASIC/FPGA resistance
  • Encourages solo-mining for decentralization of hashrate
  • Uses a variable amount of of resources (CPU & Memory) that changes dynamically as the chain progresses.
  • Helps to stablize hashrate over time


Typical implementations of the CryptoNight slow hash routines require static resource amounts to complete the hash calculations.

The figure below is provided for illustrative purposes.

Developers typically jump between any of the resource levels presented by the PoW algorithms or create slight variations of those algorithms to define new resource requirement levels for generating PoW hashes. What fun is that though?


As @angrywasp explains in the interview CN Adaptive, Nerva, and the Quest For Fair Mining they approach this issue by changing the PoW every block with CN-Adaptive. This provides a resource requirement that changes over time.

The figure below is provided for illustrative purposes.

As you can see, the line is not straight like normal CryptoNight variants. This change is provided by altering the number of iterations the slow hash algorithm performs in relation to the chain height. They do this in the following way (see permalink). This variation is enough that it makes it harder to implement specialized hardware to mine this PoW algorithm.

Let’s break this down with some sample math. Don’t worry, I’ll keep this simple.

We’ll use an example height of 10,000 to make things easy.

  1. We take height and add 1 to it giving us 10,001.
  2. We then perform a modulo operation on the values such that 10001 % 1024 and get the result 785.
    Note: A modulo operation is a division operation that returns just the remainder.
  3. The result of #3 is fed to a simple addition operation that adds the value to either 0x40000 (262144) or 0x80000 (524288) arriving at the result 262929.
  4. That value, 262929 is then fed to the slow hash routine as the number of iterations to perform.

NERVA creates a Sawtooth that climbs a hill that at it’s peak increases the iterations performed by 1,023. Zooming in, it might look something like this:

Sawtooth Wave

The work NERVA is doing is interesting and got us thinking… if they can change the iterations… what happens when we go crazy?

CryptoNight Soft Shell

I want more!

Being a Turtle has it’s advantages at times, we’re slow, steady, reliable, and like to do things our own way. As such, our buddy @iburnmycd has created a variation of the PoW that is complex enough to meet the requirements above and provides an interesting resource utilization curve.

Instead of a flat (or nearly flat) resource utilization curve CryptoNight Soft Shell has a curve like this:

How do we do this? To put it simply, we vary both the iterations and the scratchpad memory used in such a way that we move from what we’ll call CryptoNight Ultra Fast all the way up past CryptoNightv1 and then cycle back around again to CryptoNight Ultra Fast. One full cycle is completed every 4,096 blocks (and is highly configurable).

We still use height as the foundation of how the math is performed as it is something that we can all easily agree upon. The resulting code looks something like this (subject to change and protected under GPLv3).

Changing just one of the initial defitions drastically changes the results.

If we change the CN_SOFT_SHELL_WINDOW to 1024 our cycle looks something like this:

If we change the CN_SOFT_SHELL_MULTIPLIER to 1 our cycle looks something like this:

Or change the CN_SOFT_SHELL_MULTIPLIER to 16 our cycle looks something like this:

Or we can have a little bump here and there by changing CN_SOFT_SHELL_MULTIPLIER to 16 and CN_SOFT_SHELL_WINDOW to 512

The options are practically endless in how the PoW algorithm can be altered.

Hashrate Variance

A by-product of CryptoNight Soft Shell is that a miner’s hashrate moves according to where in the cycle the blockchain is as the algorithm itself changes over time. This means that as the blockchain reaches the peak of the given cycle, a miner’s hashrate slows. Then, as it starts to return back to the lower valley of the curve, a miner’s hashrate speeds up very fast.

Difficulty Variance

One problem with a Sawtooth Wave is that if the peak of the wave is too far off from the bottom it becomes possible that a mining difficulty adjustment is required otherwise the first few blocks of any given cycle may come out very fast or in some situations very slow. Unlike a Sawtooth Wave, CryptoNight Soft Shell climbs and falls in a safe way. Each step is clearly defined throughout the entire cycle. This helps protect network difficulty from sudden changes as a result of the mining resource utilization rising and/or dropping with each block.

Questions? Comments?

Given the choice, which PoW algorithm looks like the most fun to you?

Hit us up on Discord at in the #dev_general channel to learn more.