Feature Story

TurtleCoin® Podcast

Where’d the news go?

Sure has been quiet on the blog lately hasn’t it? Wondering where all the geeky news went?

We may have neglected to mention here on the blog that a while back we started a TurtleCoin® Podcast that brings the latest news to you regarding the project in audio form. Shame on us. Feel free to hop into Discord and give the Rocksteady(s) the heretofore. This is your one chance to put your hands on your hips. Use it wisely.

Once you get that out of the way, you can find the podcast via some of your favorite podcast aggregators. You’re probably a few episodes behind so get all caught up by listening to all of the episodes.

The Struggle is Real – Part 2 TurtleCoin Official Podcast

We're back again this week discussing a v2 development timeline update, the struggle of balancing priorities, and what that means for the community.
  1. The Struggle is Real – Part 2
  2. From Zero To Blockchain
  3. The Struggle Is Real
  4. Shell Shopped
  5. Shitcoin Forkers!

Or find the podcast via your favorite platform.

Feature Story

Emission Schedule Change

The Relaunch (v2)

Please keep your arms, legs, and appendages inside the train at all times. We won’t be stopping to go back if you’ve left something behind.

We announced the plans for v2 back in October 2020 wherein we stated that the TurtleCoin® v1 network would start its path to it’s own destruction around block 4 million and ultimately kill itself off at block 5 million.

We expanded on this idea in the v2 overview article which included information about the v1 chain ramping down over time so that we make it to block 5 million in a predictable way. We’ve also stated that the v2 “pre-mine” (so to speak) will be equivalent to the number of coins expected to be emitted in v1 at block 5 million with the swap ratio (100,000:1) being maintained.

In the v2 FAQ we clarified what the total supply in v2 would look like at launch.

Right now, we estimate that the circulating supply of TRTL v1 at block 5,000,000 (when the chain ends) will be around 120,000,000,000 TRTL when accounting for the ramp down of the v1 chain. At the swap ratio of 100,000:1, this means that approximately 1,200,000 TRTL will be pre-mined on the v2 chain to fund the swap process (details below).

v1 Total Supply

Technically speaking, you have until just before block 5M to turn in your v1 coins, which means that we’ll have operated a 5M block pre-mine for v2. Congrats, you’re part of history.

Since that time, we have busted out our abacuses, carried the niner, and found a few extra toes so that we could calculate the expected amount of circulating TurtleCoin® on the v1 chain at block 5 million.

Note: Block rewards, and hence emission is defined in the code base, it’s pretty easy to run the calculation if you’ve got a few minutes.

What that calculation revealed was that, based on our ramp down mechanics, the adjusted total supply of v1 comes to 125,506,496,777.95 TRTL.

To be abundantly clear, there never will be more than just over 125 billion v1 TRTL in existence because the v1 chain will die, it will come to and end, at block 5 million.

The block explorer, the circulating supply page, etc. were updated to reflect the adjusted v1 total supply as a result of this fact.

So… where did the other 875 billion coins go?

Burning ~87.5% of v1 Total Supply

Admittedly, Rock said “just the tip” but sometimes you can’t help yourself.

The Total Supply of TurtleCoin® v1 was just reduced from 1,000,000,000,000 TRTL to 125,506,496,777.95 TRTL. The remainder (874,493,503,222.05 TRTL) won’t ever be mined, no one has it, it will never exist.

However, from the perspective of the total supply (ie. economics) it’s basically a coin burn of ~87.49% of the total supply. The coins will never be minted, they’ll never exist, they just disappear from the total supply. Simple as that.

The v2 Total Supply

The end of v1 is simply a portal to v2. Bring your friends, everyone is invited.

We’ve touched on this in the FAQ, overview, and few other articles and most recently in Podcast #002 – Coin Burn.

The Total Supply of TurtleCoin® v2 will be dynamic. At launch, the total supply will be the amount of the pre-mine (1,255,065.97 TRTL) generated to fund the swap process. As the chain is used, transactions are handled, and new coins are minted, the total supply will increase. If candidate nodes (Producers and Validators) perform… poorly… and their stakes are slashed, the total supply will decrease.

As we discussed in Podcast #002, the v2 supply consists of more than just Total Supply and Circulating Supply. There’s actually a few different buckets that currency lands in:

  • Circulating Supply: The coins that are free to move within the network. Users can send it back and forth, buy things with it, move it around, etc.
  • Staked Supply: The coins are actively in a stake (whether the entry fee for a candidate node or as votes) and cannot be freely moved without withdrawing the stake (and their votes)
  • Slashed (Burned) Supply: The coins have been slashed or burned from the staked supply as a result of producers and/or validators not doing their job or doing it poorly. These coins are never coming back.

This means that the Total Supply = (circulating supply) + (staked supply).

Hold Up

Put down your shovel for a second and stop digging, let’s step back for a high level view of what’s going on.

Before you scrunch your nose, put your hands on your hips, and take to reddit or discord to give us the heretofore about an uncapped total supply in v2, let’s take a break and talk through some example numbers.

We’ll work with the following assumptions based upon the observations of v1 transactions and what we’ve discussed to date regarding v2:

  • +95% of transactions in v2 will pay a 0.01 TRTL transaction fee.
  • Block rewards will be a 1:1 match (1x multiple) of the aggregate base transaction fees in a block.
  • v2 transactions require PoW when sending that takes an average of ~5s to complete.
  • Block rewards are distributed as outlined in v2 overview
  • The 100,000:1 swap and 0.01 TRTL transaction fee will result in less transactions in v2
  • No stakes are slashed because everyone does their part and follows the rules
  • Stakes funds cannot be “spent” as part of the circulating supply
  • Blocks (and thus rewards) are only created when there is enough aggregate transaction PoW in the mempool to do so

Today, we mine ~2,880 blocks per day (using a 30s average block time). This mints ~77 million v1 TRTL. Swapping those 77 million v1 TRTL, if we were still doing PoW in v2 and adhering to 30s block times (we’re not doing this), we would mint 771.26 new v2 TRTL per day.

How many transactions need to take place in v2 to generate that amount of TRTL. Simple really. 771.26 * 100 (drop the decimals) gives us 77,126 transactions per day or just under 1 transaction per second. Seems doable, right? Maybe…

77,126 transactions would take (at an average of 5s per transaction for PoW) about 385,630 compute seconds to complete. That’s about 4.5 compute days – just to maintain the v1 per day new coin emission (as of May 15, 2021).

compute time is used here because the transaction PoW is distributed in the sense that each user sending a transaction is responsible for their own transaction PoW. Simply put, 5 users mining their transaction each taking 5s would be a total of 25 compute seconds.

How many transactions in v2 would it take to mint 1,255,065.97 v2 TRTL (a doubling of the initial total supply)? Again, drop the decimals. Users will need to generate about 125,506,597 transactions to double the v2 total supply.

That’s 27x more user generated transactions than exists in the v1 chain after more than three years of use.

Stop and think about this for just a moment. Let the thoughts flow through you…

If every transaction takes an average of 5s of PoW work to complete, it’ll take an aggregate of 627,532,985 seconds to generate that number of transactions.

That’s 7,263 compute days (or 19.89 compute years).

Even if the transaction PoW is optimized by some new fangled mining hardware or software, and those transactions are distributed across all users thus shortening that 19.89 compute years to say 3 years of actual time, emission is essentially slowed to a trickle.

When you combine the transaction PoW requirements, a 1:1 match of new rewards, stakes being locked (where they can’t be spent), stake slashing, blocks only being minted when required, and the fact that the vast majority of transactions will carry fees of just 0.01 TRTL, the chances of rampant inflation on the v2 network seems pretty low.

Feature Story

TurtleCoin® v2 FAQ

The community sent in questions and we’re here to answer some of the most popular ones. We’ll try to keep the answers straight and to the point wherever possible. 

This article is living and breathing and additional topics may be added as they come in. This permalink is the best way to always link to the latest version of this article.

Note: Some questions may be paraphrased from the questions submitted by the community to help avoid ambiguity in duplicate questions.

Q) What is TurtleCoin® v2?

Put simply, v2 is the next generation of the the TurtleCoin® project. Out with the old and in with the new as they say. The v1 network served us well, but as time has passed we want to do more, and to do that best, we need a clean slate. By starting a new network from scratch, we are able to make much bigger improvements without worrying about being backwards compatible with previous history.

For more information, we suggest reading TRTL v2 and TurtleCoin® v2 Overview as well as other blog articles as they are produced.

Q) When will v2 be released?

We’re aiming for before block 4,000,000 of the v1 chain. The actual date is fuzzy at this time but as we get closer to a release date more information will be made available.

Q) Where is the v2 whitepaper?

We gave ourselves a short deadline to come up with v2 software, so for now we are focusing on writing that first, with a whitepaper coming soon after.

If you’re looking for write-ups on what we’re doing as we are doing it, check out the blog articles for the latest and greatest about TRTLv2.

Q) Are you planning to have an audit performed?

We very likely won’t pay for an audit like other projects and instead are working with volunteers in their respective areas to provide feedback and guidance on our implemenation of the cryptographic primitives used in v2. We are also keeping a close eye on the audits performed on other implemenations that may provide insight or changes in how we have implemented the cryptographic concepts.

We encourage everyone to take a look at the cryptographic code that’s being used in v2. It is currently available in the turtlecoin-crypto repository. If you have questions, comments, or suggestions, simply open an issue on that repo.

Q) What are the biggest enhancements or benefits of v2 that we can look forward to?

  • New Core software, written from scratch, in-house.
  • Delegated Proof of Stake
    • No more mining blocks which enables faster settlement of transactions that is backed by users staking nodes as producers and verifiers of transactions and blockchain data.
    • The delegated portion of this means that users vote for producers and validators by staking funds instead of all producers and validators being predetermined.
  • Staking
    • Enables every user who wishes to stake a chance to win block rewards by helping to secure the network
  • Bulletproofs+
    • Range proofs enabling masked amounts which reduces the occurrence of dust on the chain.
  • CLSAG and maybe Triptych
    • Faster transaction signature verification with larger anonymity sets
  • Transaction Pruning
    • Less chain bloat means a smaller chain and lower storage requirements for operating a node
  • No Block Intervals
    • Blocks are only created when there are transactions to be processed, there will be no empty blocks.

All of these changes allow the network to be even more stable, fast, and easy to transact with. The chain will be smaller, faster, and easier to sync than v1. The network will move faster, transactions will move faster, and we’ll see significantly lower transaction fees.

For more information, we suggest reading TRTL v2 and TurtleCoin® v2 Overview as well as other blog articles as they are produced.

Q) Faster transactions and pruning? How might these changes apply to applications that are built on TRTL?

Due to the overzealous use of extra data in transactions in the past and a lack of the fee-per-byte structure we had to implement a maximum to the amount of arbitrary data you could put in each transaction. This was to prevent attacks on the network caused by the propagation of bloated data for the low low price of 0.10 TRTL (the network fee at the time).

The extra space had valid uses for things such as payment IDs, transaction public keys, and a few other pieces of necessary information. This same space could be used to load arbitrary data such as messages, files, and other bits into the transaction as well. However, with a maximum of 1,024 bytes (1KB) developers have to get very creative in how they store data on chain.

The significant reduction in transaction sizes in v2 coupled with the changes to transaction structures and a fee-per-byte model incorporated at chain launch will allow us to open up the maximum amount of space that can be used to carry arbitrary data on chain. This will enable developers to leverage the chain in new ways and we’re excited to see what people come up with.

Q) What will be the minimum amount required to stake?

We haven’t settled on the required amount to propose a new candidate node into the network just yet. While we want anyone to be able to run a candidate node in v2 we have to make sure that there is sufficient “skin in the game” to ensure the success of the network. You’ll be required to “lock up” your stake to be a candidate node for a minimum amount of time.

As for users staking (“voting”) for a candidate node, 1 TRTL = 1 vote. You’ll need to stake whole TRTL coins to cast a vote. Like the stakes for candidate nodes, you’ll be required to stake your funds for a minimum amount of time before they can be recalled.

In any event, you’ll want to vote for trustworthy nodes that do their job in securing the network otherwise it puts your funds at risk.

Q) Does DPoS mean that TRTL is becoming a governance token?

TRTL isn’t a token. It’s a currency, an asset, a network, not a token riding on another chain.

TRTL’s take on DPoS uses PoS as a facility to put skin in the game to produce and validate blocks and gives normal users a chance to get a portion of each block reward. It’s far less about governance in the sense of voting for protocols and more about maintaining consensus and keeping the chain moving in an agreeable way.

Q) Is TurtleCoin® v2 focused on privacy?

Privacy is a beneficial side effect of some of the technologies that will be used such as CLSAG, possibly Triptych, Bulletproofs+, and Pedersen Commitments though it isn’t a specific goal we had from the beginning. All of these technologies are being adopted to reduce transaction sizes, speed up transaction verifications, and reduce network overhead thereby allowing for a much high transaction volume through the network. Those improvements happen to come with the bonus of a high level of privacy. 

As technologies such as CLSAG and Triptych allow us to have smaller signature sizes and have lower verification times – why not crank it up to 11 and enable massive ring sizes. Sure, this increases privacy on the network but that’s enabled by the changes we’re making to make the chain smaller, faster, better, and stronger.

Q) Why is the total supply changing from 1,000,000,000,000.00?

Right now, to buy a sandwich, you’d spend about half a million TurtleCoin. 500,000 can be made up of a LOT of inputs, and in our current way of making transactions, each of those inputs has a lot of signatures attached to it, which means fat transactions and big fees. That can’t be realistic. This would mean TRTL is near useless as a currency if you can’t even buy lunch with it.

In a nutshell, we call this dust. There are over 100,000,000 outputs on the v1 chain right now and most of those are dust. Seriously, go check it out on the mixable amounts page of the explorer. Over 10% of the outputs on the network are worth 0.01 TRTL today. We need to avoid this like the plague in v2. Moving to pedersen commitments and amount masking helps a lot in v2 and saying “1 trillion TRTL” was fun and all – but we really don’t need this baggage going into the overhaul, do we?

Q) So the total supply will be 10,000,000 TRTL in v2?

Not quite. The relation to 10M TRTL in v2 was to give people an idea of what the reduction via the swap will look like. In actuality, there is no cap to the total supply in v2. Hold on, put down the pitchfork, we’ll explain.

Right now, we estimate that the circulating supply of TRTL v1 at block 5,000,000 (when the chain ends) will be around 120,000,000,000 TRTL when accounting for the ramp down of the v1 chain. At the swap ratio of 100,000:1, this means that approximately 1,200,000 TRTL will be pre-mined on the v2 chain to fund the swap process (details below).

After that pre-mine, emission mechanics will be driven by use of the network. Block rewards will be granted at a 1:1 ratio of the full value of the transactions contained in the block in a fee-per-byte manner. This means that if a block contains transactions with a total of 1,000 TRTL in transaction fees, the base block reward will be 1,000 TRTL and the total block reward will be 2,000 TRTL.

Blocks will only be created when there are transactions to process so emission will be tied directly to the use of the network with no upper limit. The more the network is used, the more that is released into the circulating supply.

Q) Why will v2 only have two decimals?

Two decimals works at this point and helps keep dust in check. More than two decimals is confusing in many ways and makes it very hard to understand how much you are really sending in a transaction.

Q) How will the v1 to v2 transition work exactly? What happens to my current coins?

The transition period will last 1,000,000 blocks (or about a year), during that time you will use a website to generate an address unique to you where you can send your old coins, and you’ll be able to specify your new wallet address to receive your new coins. If you do nothing, your coins will eventually be burned after the swap has concluded.

When the service sees that the funds were indeed sent on the v1 chain and enough confirmations have passed (TBD, but likely 120 blocks), the service will submit a transaction on the v2 network that will send you the proper number of v2 coins to the v2 wallet address you supply the site. As mentioned previously, the swap will be at a rate of 100,000:1 meaning for every 1,000 v1 TRTL you send in via the swap service, you will receive 0.01 v2 TRTL.

Yes, it’s really that simple. TurtlePay® makes this easy.

Q) Do I have to do anything with my wallet(s) right now?

Find your seed phrase, and write it down. The swap period won’t start until block 4,000,000 but when it happens you’ll want quick access to your coins, including any time to sync.

Sit tight for now and we’ll provide directions on how to interact with the swap service when it’s ready and the swap window is open.

Seriously, sit tight, keep your v1 wallet synced, and be ready when the announcement(s) for the swap go out.

Tip: If you absolutely want to be notified when the swap happens, go in the discord chat and type *news which should apply a role that gets a notification any time we post v2 updates.

Q) If I have 1,000,000 coins in v1, how many coins will I have in v2?

The swap will be at a rate of 100,000:1 meaning for every 1,000 v1 TRTL you send in via the swap service, you will receive 0.01 v2 TRTL.

1,000,000 / 100,000 = 10. You’ll have 10.00 coins in v2.

Q) Do I have to change to the GUI wallet?

Nope. The core suite software will always include a CLI software wallet implementation. Use of a GUI wallet is optional and up to you.

Q) I used to mine TRTL but now I cannot open my wallet. Did I miss the upgrade to v2?

No, you didn’t miss the upgrade to v2, but you very likely missed numerous releases on the way to v1.0.0.

You’re going to need to grab yourself a copy of v0.28.3 and upgrade your wallet to the latest format.

Then you can open your wallet with the latest release and proceed with syncing your wallet. Backup your keys while you’re at it as you’re going to need them.

Q) What will be the ticker for TurtleCoin® v2?

v2 will completely replace the v1 chain and v1 will be retired. The ticker will remain TRTL.

Q) Are you going to get TRTL listed on more/bigger exchanges?

As developers, we focus on code and the reliability of the network. If the community finds an exchange that wants to list us, we are happy to assist them with engineering-level questions they may have about implementing TRTL, but other than that, we don’t go endorsing exchanges, engaging in partnerships, or paying for listings.

Q) I have v1 coins on “X” exchange and they are down for maintenance – can you advise when this will be fixed?

Ask that exchange why they haven’t jumped in the chat through matrix or discord and asked for help. We are happy to help with engineering questions, always.

As always, please remember, if your coins aren’t in a wallet with keys you control, they’re not your coins. This will be even more important as staking begins on the network, as you’d be forfeiting any ability to stake your own coins or get the benefits from doing so.

Q) Should I buy v1 coins before the swap?

Buy comfy sweatpants, ice cream, and maybe some whiteclaw. That’s the best advice we can give.

We aren’t investment advisors nor do we play one on the Internet. We can’t give you investment advice and never will. Your best bet is to do your own research, make your own decisions, and consult with a financial advisor on any financial decisions you may make.

Q) Will you re-evaluate the conversion (swap) rate if the value of TurtleCoin v1 climbs?

Nope, sorry, ain’t gonna happen, no. We have said it before and we will say it again. The swap rate is based on nothing but technical/engineering details and the impact of such on chain growth and bloat. It has nothing to do with “value”, “profit”, “gains”, and etc. If you have technical/engineering reasoning on why you think a different swap rate makes more sense, let us know.

Q) What are you doing about marketing efforts?

We’re trying to be more active on social media platforms like Twitter, Reddit, and countless other mediums but it’s largely a volunteer driven effort with it’s focus on getting the word out about v2. If you’ve got an idea join the discussion and maybe others will help you drive an effort.

Keep in mind that we’re developers that are allergic to suits, PowerPoint presentations, and sunlight so our social skills aren’t exactly aligned with marketing.

Q) Don’t remove PoW for the love of god.

Mistakes were made and we are fixing those mistakes by removing PoW from the mining of blocks. Also, that wasn’t a question.

Q) What is it good for? What is it’s utility?

TurtleCoin aims to be a fun, fast, and easy way to send funds between family, friends, and organizations. That’s the primary driving force behind the project – beyond that, it’s basically a choose your own adventure story. What do you want to use TurtleCoin for?

Q) Can I still mine TRTL once the v2 swap period has begun until the v1 chain stops?

Yes, the v1 chain will remain mineable for about 1,000,000 blocks once the swap period starts. Mining will end completely on the v1 chain by block 5,000,000 as the chain will end. The v1 chain will remain mineable until that block to facilitate the transfer of v1 funds to the burn address provided via the swap site so that you can receive your v2 funds.

Q) What is the website we need to use for converting v1 coins to v2 coins?

The website has not been launched yet and the URL is to be determined.

Sit tight for now and we’ll provide directions on how to interact with the swap service when it’s ready and the swap window is open.

Seriously, sit tight, keep your v1 wallet synced, and be ready when the announcement(s) for the swap go out.

Tip: If you absolutely want to be notified when the swap happens, go in the discord chat and type *news which should apply a role that gets a notification any time we post v2 updates.

Q) How will you ensure that network fees remain reasonable with only two decimal places?

The minimum network fees for transactions will be 0.01 TRTL. That’s the minimum amount that a fee can be without being 0 (free). Beyond that, we have ran the numbers to ensure that the majority of transactions fall within the range of the minimum network transaction fee (0.01). This is driven by the mechanics behind the fee-per-byte mechanism that calculates the required network transaction fee. Given that we know how large each part of a transaction is (in bytes) and how big signatures, proofs, etc. are we are able to arrive at a reasonable base chunk size that accounts for the majority of “normal” transactions.

Q) What will be the actual fee per byte (KB or MB)?

As it stands today, each chunk of 256 bytes (0.25KB), rounded up, will cost 0.01 TRTL; however, the first 10 chunks (2,560 bytes — 2KB) are included in the base network fee of 0.01 (to permit the majority of “normal” transactions to enjoy the minimum network transaction fee). This means that if your transaction is 2,561 bytes the network transaction fee will be 0.02 TRTL (before any PoW discounts) and a transaction of 2,000 bytes will be 0.01.

If, for instance, your transaction was 9,172 bytes, you can quickly calculate the base network transaction fee (before any PoW discounts) as 9,172 – 2,560 = 6,612 (bytes that are in excess of the “free” zone). 6612 / 256 = ~25.828 (rounded up) = 26. Therefore you’ll pay 0.01 (the base) + 0.26 (the chunk cost above the base) = 0.27 TRTL total.

Note: The actual chunk sizes may be tweaked during the Testnet runs of v2 before it launches by the general process will remain the same. After all, it’s worked quite well for v1 and has greatly curbed the amount of spam and junk transactions that enter the chain.

Feature Story

Ring Signature Performance Metrics

I wrote a bit about the differences in the resulting signature/proof sizes in the last article I posted (Bulletproofs+, Arcturus, Pruning, Massive Ring Sizes, Oh My!) and briefly mentioned some of the performance information for each of those methods. While signature size is important to the overall storage growth of the chain, verification time of those signatures (proofs) is very important to how quickly transactions are relayed throughout the network before being added to a block.

In this article, I’ll take you through the differences in the generation/proving time and the verification times of each of the signing schemes in a bit more detail and how these methods effect the different ways we interact with the blockchain.

Signature Generation

Every user initiated transaction on the network requires a signature that cryptographically proves that you have the knowledge of the private key that generates that signature. The signature is generated just once using that private key and is done (in most cases) only when you are sending a transaction. This work is performed on your device whether it is a PC, mobile phone, or otherwise. How long it takes to construct the signature is of no concern to the network as the network does not sign your transactions, You do.

While we don’t want signature generation to take forever as it negatively impacts the user experience as the time increases — the speed of signature generation is not a large determining factor when selecting a signing scheme.

Signature Verification

What we are very concerned with is signature verification time. This is due to the fact that unlike generating a signature, every node participating in network consensus must verify that a signature is valid (producers/validators).

Checking that signature occurs not once per transaction but twice at minimum:

  • It checks that a signature is valid as the transaction enters its memory pool to ensure that we are not injecting invalid transactions into that pool.
  • Transaction signatures are also checked as they are added to blocks for exactly the same reason.

Each transaction in the memory pool requires multiple iterations of the verification routine. Including transactions in a block has the same requirement. That means that to keep things moving quickly, we need the verification routine to take as little time as possible. Doing so allows the transactions to enter the memory pool faster, propagate across the network faster, and ultimately be committed to a block faster.

In the v1 blockchain, those signatures must also be verified during the node syncing process and only those already included in checkpoints are skipped. This is why syncing a node is slow.

We plan to mitigate this problem via the pruning mechanism that was mentioned in the last article which will allow for skipping this process while syncing a node.

It is also important to note that syncing your wallet does not require that signatures are verified. After all, a wallet does not maintain network consensus and maintain the chain, a node does.

Signature Generation Times

Let’s take a look at the signature generation times of the current v2 implementations of the ring signature signing schemes: Borromean, CLSAG (w/ commitments), and Arcturus.

The y-axis depicts the time in milliseconds (ms) and the x-axis depicts the number of ring participants. As a reminder, there’s 1,000ms in a second.

Note: These results were generated using an AMD 1950X, on Windows 10, using mingw-gcc-8. Actual performance results will vary by CPU, OS, compiler, etc.

But… but… but… you said CLSAG was faster than Borromean. You’re right, I did and that does hold true when the code is optimized; however, I didn’t optimize the hell out of the CLSAG implementation in the v2 crypto library because…

While CLSAG and Borromean generation times stay relatively steady — the Arcturus generation time climbs pretty quickly as the ring size explodes. This may seem concerning; however, as discussed in the previous article the benefit of this is that the signatures are significantly smaller at those massive ring sizes. In addition, we’re forgetting something very important here:

With Borromean & CLSAG sag, we have to have a separate signature for each input of a transactions. The same does not hold true for Arcturus which allows us to prove the knowledge of multiple keys in the same signature.

So, let’s graph those same values again assuming we have eight (8) inputs in our transaction.

Now that looks like a comparison that makes a bit more sense.

Here we can see that at the largest ring sizes, Arcturus generation time is, in essence on par with CLSAG generation times. Also, as expected, Borromean Ring Signatures are still faster at those ring sizes; however, as you may recall, Borromean Ring Signatures are significantly larger.

The clear winner in this case considering the resulting signature size is clearly Arcturus.

Signature Verification Times

Now that we’ve taken a quick look at the generation times, let’s wander on over to the verification side of the fence. After all, it’s a very important side of the fence, probably the best side of the fence ever, and no one will ever make their side of the fence look like our side of the fence…

Less time is better and the gray line clearly won.

Using just one input in the transaction, Arcturus is the clear winner coming in at about 2x the speed of a Borromean Ring Signature verification and almost 4x the speed of the CLSAG verification.

Seriously though, I know my CLSAG implementation in the crypto library is unoptimized (for now) and I don’t need to remind myself with pretty graphs.

Bill Gates, 1986 – Founder at Microsoft

What’s that mean to a transaction with eight (8) inputs? Let’s take a look.

The proof is in the pudding as they say

The difference between the proving schemes is much more apparent with multiple inputs. Arcturus performance during verification of large rings doesn’t even break the one (1) second barrier until 8,192 ring participants. Meanwhile Borromean and CLSAG blow past the one (1) second mark at 512 and 256 ring participants respectively.

For the largest ring sizes measured, Arcturus is 13x faster than Borromean and 25x faster than CLSAG for the same ring size.

I’ve beat the literal crap out of CLSAG in this article. That wasn’t my intent. An optimized implementation performs far better than as shown here but Arcturus still eats CLSAG’s lunch.

And the Winner is…

Considering the sheer speed of Arcturus at larger ring sizes and the significant space savings, it’s clear that putting in the leg work to get a working implement of Arcturus in C++ was well worth the time.

Doing so allows us to investigate and use the large ring sizes (or bigger) mentioned in the previous article while knowing that in doing so we are not negatively impacting the performance of the blockchain as we continue to work towards v2.

Anyone else as elated as I am for v2? Good, you should be 🙂

Feature Story

Bulletproofs+, Arcturus, Pruning, Massive Ring Sizes, Oh My!

For the people who only read the headlines:

TurtleCoin v2 is 23x more private than Monero. We win.

For the rest of you nerds who like details, keep reading..

Cryptographic Methods

At the heart of every blockchain project is the code that makes the magic happen. The fundamental math that handles the calculations required to handle our good friend Elliptic Curve Cryptography (“ECC”). ECC serves as the method for how private keys and public keys are generated, how those points on the graph are related, and how those points are manipulated (added, subtracted, multiplied, etc.). The ability to manipulate the points in a secure way provides us with the foundational building tools to build the vast majority of blockchain networks.

TurtleCoin® is no different. Today, v1 relies on a slight variation of ED25519 using Curve25519. The implementation differs from ED25519 which relies on SHA-512 (SHA-2) by instead utilizing a non standards compliant implementation of Keccak (aka SHA-3) in the form of cn_fast_hash as well as encoding private keys slightly different than as defined in the RFCs.

For the nerds in the crowd, the implementation is non standard due to a use of a slightly different padding.

Those of you that have worked to create various implementations of wallet software, address generators, etc. have undoubtedly came across this variation a few times and said to yourself “wtf” when you try to use a standard SHA-3 or ED25519 library in the language of your choice.

When CryptoNote gives you lemons, throw them out and make orange juice.

Out With The Old, In With The New

The new crypto core is still built on Curve25519; however, instead of using non-standard Keccak, we’re moving to the SHA-3 standard. Every construction whether it be key derivations, output creation & scanning, signature construction, view key generation, etc. has been moved over to better support the use of standard hashing libraries. It’s not a huge change, but it does make a difference. The result of this is that if you were to restore a v2 wallet using a wallet seed generated by v1 software, you will get two totally different wallet addresses.

To be abundantly clear, v1 and v2 keys, seeds, and wallets will not be interoperable.

In addition to that change, considerable work has been done to make using the primitives a lot easier in downstream code. The framing around the cryptographic foundations has been rewritten to make using, reading, and understanding how those primitives work as easy as possible while still maintaining as much performance as we can. The end result is a generally easy to understand and read implementation of the framework required to build a blockchain project.

Turning code that looks like this:

Into this:

This not only makes the code about 1,000x easier to read and understand but greatly reduces the entry barrier required to get in there and start working with things. It also makes it a lot easier to build more advanced constructs including some of the additions that have been baked into the new cryptographic core.

Rock said he wanted smaller transactions… “I’ll show him smaller transactions” – IBMCD

Reducing Transaction Size

As we have discussed in previous updates, one of the foundational issues that the network has had in the past is the explosive growth of the chain in terms of storage requirements. While dropping junk in TX_EXTRA has been a large driver of that growth, the vast majority of the storage is driven by the input signatures attached to each transaction input. Today, these signatures amount to 512bytes (0.5KB) per input with a ring size of 4. It doesn’t seem like much, but when some transactions have 10s or hundreds of inputs that 512 bytes explodes at a very linear rate.

While the bulk of a transaction is the signatures of those inputs, the need for working with certain denominations of coins or “pretty amounts” (ie. 1, 2, 3, 10, 20, 30, 100, 200, 1000, etc.) also contributes to the bulk of a transaction size. The use of pretty amounts is what drives the need for fusion transactions whereby all of the smaller denominations (“dust”) are traded in for larger denomination outputs that can be spent later. The requirement that denominations exist and are used results in more dust, more transactions, and a larger chain overall.

To combat this issue, we’re doing away with the requirement to transact in denominations and changing the ways in which signatures are constructed.

Masked Amounts

To get rid of the requirement to transact in certain denominations v2 will utilize masked amounts and rely on Pedersen Commitments to denote both input and output values of the coins that are transacted without ever revealing to a third-party the actual value of the coins.

Pedersen Commitments have been heavily used in other blockchain projects such as Monero (XMR). A side benefit to this method includes the increased privacy of the transactions on the network.

Pedersen commitments have a nifty property in that they can be added and subtracted from each other much like regular numbers can be added and subtracted from each other and arrive at the same result.

For example, assuming our commitment generator is C:

C(a + b) = C(a) + C(b)

The commitments do not reveal the actual values of a and b and an outside party has no clue what those values are.

This is very handy for ensuring that the tally of output commitments is equal to the tally of input commitments – or put simply, that a transaction is in balance.

Range Proofs

The primary issue with using Pedersen Commitments for transacting on a network are that it is possible to construct output commitments that overflow the number space that ultimately results in the rampant creation of new coins without the authorization to do so.

For a quick example, let’s assume that we have an unsigned 8-bit number space available. We know that if we overflow the maximum value of that space (255), that the number overflows and comes back around to end up where it doesn’t make sense. We also know negative values stuffed into that same space results in a value that underflows and arrives at a place that doesn’t make sense.

Let’s take a quick look at this in practice and how this can be exploited.

Note: The values are shown below for explanation purposes, in practice, they are hidden by their commitments.

i_1 = 4
i_2 = 40
i = 4 + 4

Then we construct two (or more) outputs to arrive at the same value:

o_1 = 100
o_2 = 200
o = 100 + 200

We can clearly see that 300 \ne 44 However; in 8-bit math, the number rolls over the top such that 100 + 200 = 44 resulting in the tally of inputs and outputs matching. If you’re following along, you can see that we just minted coins (256 to be exact) out of thin air. Not cool.

The same trickery can be performed using negative values as well (ie. -100 + -120 = 44) because of the number bounds that turn that into 156 + 112 = 300 which wraps around again such that 156 + 112 = 44. Definitely not cool.

This is where Zero Knowledge Range Proofs come in to save the day. They allow us to prove to a third-party (ie. the network) that the values contained in the output commitments of a transaction are within a certain range without revealing the values they represent. In our case, the range is defined as 0 to 2^{64} - 1 otherwise known as what can fit within an unsigned 64-bit number space.

To simplify this a bit, think of a Pedersen Commitment like a cardboard box. Everyone on the network uses the same sized box (64-bits) and can stuff whatever they want into the box and ship it around the network. A range proof provides a cryptographically secure proof that what’s in the box fits inside the box and isn’t pulling a Dr. Who on us.


We will be using Bulletproofs+ (“BPs+”) for our Zero Knowledge Range Proof in v2. To prove to a third-party (the network) that the values of the commitments in our transactions are within the bounds specified.

You may have noticed that we skipped right over Bulletproofs (“BPs”) and instead went straight for Bulletproofs+. The constructions are relatively similar with the resulting difference being that the cryptographic proof of the values of our commitments are within the defined range are smaller in terms of byte size and verify just a little bit faster than Bulletproofs.

Another huge benefit of BPs or BPs+ is that a proof can be batched meaning that we can prove the values of multiple commitments all within a singular proof. Instead of submitting one proof for each output commitment, we are able to submit a single proof for all of the output commitments in a single transaction. This greatly reduces the amount of storage required to transmit and/or store the transaction while still maintaining masked amounts. This results in smaller transactions and thus lower transaction fees.

For the sake of testing and benchmarking the new cryptographic core contains implementations of both Bulletproofs and Bulletproofs+. We’ll be relying on BPs+ until something better comes along.

Signature Construction

Borromean Ring Signatures

Today, v1 uses Borroeman Ring Signatures and each input in a transaction contains such signature whose size is proportional to the ring size. As the size of the ring grows, the size of the ring signature for each input grows as mentioned above. The growth is linear to the number of ring participants which is detrimental to the size of transactions and thus drives up transaction fees.

In this case, an upward trend is a bad thing

Adding commitments into the mix only further slows things down and causes massive chain bloat. At a ring size of 256 participants, the signature size is 16,384 bytes or 16KB without including the signing of the commitments. Yikes!

So, what are our options if we want to increase ring size as part of the change to v2?

Concise Linkable Ring Signatures (CLSAG)

You may recognize CLSAG from a recent XMR upgrade performed in October 2020. CLSAG greatly reduces the size of the signature of each input supplied for a transaction. While it still grows at a linear rate it grows quite a bit slower. It’s also a bit faster in the construction and verification routines as opposed to Borromean.

It’s like Borromean but smaller… and still traveling in the wrong direction.

At a ring size of 256 participants, the signature size is considerably smaller in our construction coming in at 8,259 bytes or ~8KB including commitments which is a drastic reduction in storage space.

Cutting the size of the signatures in about half results in our transactions costing significantly less. Woot!

Can we do better? Can we crank this thing up to 11? You’re damn right we can.


Arcturus is the new hotness put together by the Monero Research Lab (“MRL”) that significantly reduces the size of a “ring signature” while ensuring the that tally of input and output commitments match. Not only that, but it also works to prove the commitments to zero for those commitments (ie. proving that you know the real values of those commitments). If that were not enough, it also permits multi-index proving such that it’s possible to combine all of the attestations that we know the values of the commitments as well as have the private ephemeral for each real input being spent into a single proof.

I’m taking a bit of liberty here in calling Arcturus a ring signature as it’s not so much a ring signature as it is a cryptographic proof; however it is functionally equivalent to a ring signature for our purposes and helps keep the information relatable.

Comparatively speaking, verification times are, at times, about twice (2x) as fast (or more) as a CLSAG verification of the same ring size.

The multi-index capabilities of Arcturus have massive benefits to v2. Instead of having a signature for each input in a transaction, we are able to combine all of the inputs into a single signature (proof). This means that as we include more inputs in a transaction the signature does not grow linearly anymore thus reducing transaction size resulting in even lower transaction fees.

The downside is that the construction (generation) time is considerably longer for large rings. That’s okay though as signatures/proofs are only constructed when you use your wallet to create a new transaction.

Well, well, well, ring size explosion with a slow growth rate? That’s what we need!

As you can see, the size of the ring no longer grows linearly with the size of the ring. At a ring size of 256 participants, the signature size comes in at a panty dropping 1,294 bytes in our implementation. This means that our signature is not only ~16% the size of a CLSAG signature but is also ~8% of the size of a Borromean signature. Couple that with the fact that we can now bake multiple spends inside a single signature (proof) and we’ve potentially cut up to 99% (depending on the number of inputs) of the signature bulk off a transaction sent on the network. HELL YES!

What’s this mean for users? Very, very, very, very low transaction fees!

The Code

You can find C++ code for all of these signing mechanisms as well as the range proofs in this article in the turtlecoin-crypto repo on the development branch. In addition to the C++ code, this repo also builds the Node Native C++ Addon Module, Javascript (ASM.js), and WASM targets for use in other downstream projects.

Kind of reminds us of the v1 chain, amirite?

A Smaller Chain He Said…

Now that we have cut down the size of transactions so that they are a fraction of their previous size, we got to thinking… how else can we cut down on the storage requirements of the v2 chain and cut down on chain sync time. As we all know syncing the chain on a node is by far the best way to find the time to learn a new hobby. It’s not fast – even with checkpoints – it takes a while.

After mulling it over a bit, the thought came to us that we don’t need to carry around our range proofs and transaction signatures indefinitely… that they are in fact… immediately and forever prunable. Notice we said immediately prunable as in we don’t need to wait for a certain number of blocks to pass before pruning the signatures and range proofs from the transactions. Nor do we need to make this optional for node operators – it just is. Transactions can be pruned as soon as they are committed to the chain (included in a block).

Nodes will keep transactions in an alternate mempool for a certain number of blocks, in the rare event that a re-organization event does occur, they will be able to pluck the full details of the transaction from that alternate mempool. Once enough blocks have passed, transactions in the alternate mempool can be purged.

You may be scratching your head and wondering what we’re thinking as that information has to be there to verify a transaction during the sync process… right? No, it doesn’t.

In a traditional PoW network, such information has to be maintained to ensure that the blockchain is valid from start to the tip of the chain – verifying every bit along the way. This method also allows for handling chain re-organization events which are common in blockchain networks.

We already use checkpoints to short-circuit many of the checks normally performed by providing a list of trusted hashes for prior blocks. Checkpoints allow us to bypass the need to verify everything in that range of blocks (including the transactions and their signatures/proofs) and saves a lot of time.

In the v2 PoS scenario, we vote to trust that the block producers and validators have verified the signatures and range proofs for each transaction in a block before throwing their stamp of approval on the block (via a signature). Once the producers and validators sign a block, it’s solid, it’s not going anywhere. It is “in stone” as they say and while a chain re-organization is possible, it’s very unlikely. If they don’t properly verify signatures and range proofs well… that’s where they get penalized.

Producers and validators that don’t do there job will be dealt with swiftly and with extreme prejudice.

What this allows us to do is to define the structure of our transactions differently. Whereas today transaction hashes (and thus the hashes included in blocks) are generally constructed based upon the hash of every byte of a transaction (prefix || signature || range_proof), TurtleCoin® v2 transaction hashes will be computed based upon the hash of (prefix || H(signature) || H(range_proof)).

By constructing our transactions in this way, we are able to keep the full transaction (including the full signature and range proof) in the pending transaction mempool so that producers and validators can verify the signatures and range proofs. When the transaction is committed to the chain (included in the block), we can instantly drop the full signature and range proof from the data and swap the hashes of those structures into their place for long term storage which drastically reduces the storage required to operate a node.

While a signature + range proof may require 1,938 bytes in the mempool, once committed to disk, that same signature and range proof will only require 64 bytes of storage. This results in a reduction in transaction storage requirements of over 96%. Combine this with the fact that we will no longer produce empty blocks and we might be able to keep the chain on a floppy disk for a while.

Pretty cool aeh?

Enhanced Privacy Features

If you’ve read through all that, you can see that the vast majority of the work for v2 has focused on reducing the chain size and making verifications faster to support making the chain faster to sync and allowing wallets to sync as fast as possible. This greatly improves the experience when working with the network which was on of the core goals for v2.

However, in focusing on improving the experience of using TurtleCoin® we picked up numerous privacy enhancements along the way. What we have in the oven now is something truly unique. The combination of enabling Amount Masking and Arcturus allow us to provide 100% privacy with ring sizes far larger (and thus much harder to trace) than other projects – all coupled together with PoS.

While we test, benchmark, and debate whether 256, 512, 1,024, or larger ring sizes make the most sense for the network, we know that any of those ring sizes far exceed the ring sizes used by other projects (including XMR) and provide people with a network that they can securely and easily transact on. Throw in the fact that the relaunch allows us to enable the use of massive ring sizes starting with block 0, the privacy offered by TurtleCoin® v2 will exceed that of practically every other privacy project out there.

No tainted outputs, no legacy spends, no small traceable rings, no messy output migrations. Just secure, confidential, and highly anonymized transactions on a small lightweight chain.

What’s Next?

Now that we have the core cryptography out of the way we can direct our focus back to finalizing block and transaction structures (90% complete) then start work on building up the blockchain storage subsystem, building the staking system, and wiring up the rest of the network node. From there, we’ll work on building out the new CLI wallet that will be designed from the ground up.

We hope you’re as excited as we are as we continue to build the next generation of the TurtleCoin® network from scratch using the latest and greatest technology available.

Feature Story

TurtleCoin­® v2 Overview

In the early days, at least two forevers ago, we blew the dust off a legacy Bytecoin codebase and launched a coin using just enough special sauce to call TurtleCoin our own, all on a whim. As a new network, there were the usual struggles, like when ASIC for CryptoNote emerged, or when we found a pretty serious RPC issue in Simplewallet.

As our team and their contributions grew, we eventually found ourselves in a new codebase, rock solid, but still carrying the scars of our past.

Fast forward to now, we are 3 million blocks wiser, our team is many lines of code more experienced, and as we have chiseled our way through, we made a list of a some areas where we can do better. Taking a step back, the last few years have shown us that we are reaching the limit of our current software, and the time is now for us to think radically different and put something new on the table. It is time to build something of our own.

With great respect and thanks to the CryptoNote family, Forknote, Bytecoin, and those who enabled us to get where we are now, we humbly begin our own path and embark on a new journey. What we produce next will be from scratch, written by us, exactly how we have always wanted it.

TurtleCoin v2 is the future, and we are excited to share it with you!

– RockSteady

The Goal

We aim to redesign TurtleCoin from the ground up to avoid the mistakes of the past while putting an eye to the future state of the network. This is accomplished by replacing traditional Proof of Work (PoW) based mechanisms with a round-based hybrid Proof of Stake (PoS)/PoW model. We’re going to be talking about some of the fundamentals required in this model so buckle your seat belt and be ready for a ride. Be warned, there’s a bit of math below.

Proof of Work

The traditional approach to cryptocurrency networks is to deploy a PoW model such that miners perform endless repetitive hashing of block data searching for a hash that meets a set difficulty. The miner is rewarded for burning fossil fuels via a specially constructed transaction (the “coinbase transaction”) that allows the miner to create new funds as a result of mining that block.

Proof of Stake

PoS deviates from the PoW consensus model in that PoW is typically no longer performed, instead passing the torch to block producers (the “producers”) whose work is then validated by the block validators (the “validators”). These parties are typically elected via users staking, or otherwise backing, their preferred candidates for those roles. Selection of producers and validators typically takes place via an election mechanism as part of the consensus rules.

Our Vision, Round Based Hybrid Delegated PoS w/ PoW

We are planning on combining the best of PoW with the stability and speed of PoS to create one kick ass network. We’ll use DPoS for managing the distributed ledger and PoW as part of the transaction construction and validation process.

Operational Overview

When a user wishes to send a transaction, they generate the transaction in the “normal” way. However, there is a nonce field included in the transaction that requires for the user to perform PoW for that singular transaction to meet a preset difficulty for transactions. The resulting transaction and the nonce is then forwarded to a node for broadcast to the network.

Every transaction will require a base amount of work (PoW) before it can be submitted to the network in addition to a fee-per-byte network transaction fee. However, if a user wishes to discount their transaction fee for a particular transaction on the network they may submit a PoW for the transaction that meets yet a higher tier of difficulty. While the discount tiers have yet to be defined, the maximum discount for the transaction fees will not exceed 50% of the fee-per-byte fee. There are no free rides.

Fusion transactions will no longer exist on the network. As a wise man once said, “ass, cash, or hash, no one rides for free”. Everyone pays their fair share for transacting on the network regardless of the reason for that transaction.

Once a transaction is received by a node, the node performs basic checks (i.e.. transaction construction, valid nonce, PoW meets required difficulty, verifies signatures, etc.). Once that node completes the basic verification, it forwards the transaction to the rest of the network including the producers. Producers hold the transactions in the global memory pool after performing their own validations of the transaction ensuring that it is indeed a valid transaction. At this point, users can presume some level of assurance that the transaction will be committed to a block solely because the producers have accepted the transaction into the pool.

Once enough PoW transactions have accumulated in the pool to satisfy the network difficulty, the then current producer creates a block that ratifies the selection of transactions necessary to meet (or exceed) the network difficulty requirement. When doing so, the producer creates a block reward equivalent to a 1 for 1 matching of the aggregate transaction fees included in the block.

This means that emission is directly tied to the actual use of the network as a transactional platform. We will no longer be emitting currency on a pre-defined schedule as a result of this change. The more the network is used, the more currency that will become available.

The block reward is distributed proportionately between the block producer, the validators, and a subset of the users who staked that producer. Upon completion of the block the block is signed by the producer and transmitted to the network.

The validators, upon receiving the block, validate (at minimum) that:

  • The producer was permitted to produce the block (their turn)
  • Enough PoW transactions have been included to meet network difficulty
  • Transaction hashes included in the block have been included such that the hashes are arranged in descending order
  • The block is properly signed by the producer
  • The transactions in the block meet all of the consensus rules of the network (no double spends, etc.); and
  • No unnecessary data is included in the block
  • That the producer claimed and paid out the proper block rewards.

A minimum of 51% of the validators must then sign the block and submit their signatures to the network thus ratifying the block itself.

After the block is ratified, the network difficulty is adjusted (if necessary) to account for things such as the number of transactions included, the PoW of transactions included, and any other metrics required to keep the network operating correctly.

No Empty Blocks Means Storage Saving Is Built In

One of the largest benefits in this scenario is that we no longer produce empty blocks and thus save tons of storage space. This makes the chain faster to sync, easier to store, and overall much easier to manage.

Tut, Tut: The Reward Lottery

Gone are the times when a single miner/pool received the entirety of a block’s reward. In this new model, the block reward is distributed to multiple recipients via the payments to the producer, a pseudo random validator, and a pseudo random subset of users who have staked the given producer and validator.

The Reward, Divided

We’re still playing with the numbers but there’s a pretty good chance that the block rewards will be divided as follows:

  • 20% to the producer of the block
  • 20% to the one of the validators of the block
  • 30% to the users who staked the producer
    • Maximum of 10 randomly selected stakers
  • 30% to the users who staked the validator
    • Maximum of 10 randomly selected stakers

Becoming a Block Producer / Validator

A user (“Alice”) wishing to operate a block producer or validator “announces” their intent for candidacy by staking their node(s) with a minimum stake of a yet to be determined amount of TRTL. Upon successfully staking their node, Alice’s node is now a candidate for either a producer or validator spot in a round. It is important to note that Alice simply staking her node as a candidate does not automatically make Alice a block producer or a validator.

To be a candidate for either role within the network, Alice must be “endorsed” by other users of the network via users staking their funds in support of Alice. Once Alice has at least 1 TRTL staking her, she is now a candidate in the running for a producer or validator spot.

The details of how these stakes are sent, recorded, recalled, etc. will be discussed in further articles and will undoubtedly involve a lot of math. Don’t worry, we’ll warn you ahead of time so that you can bring a protractor and a compass.

Electing Producers & Validators

Producers & Validators are elected for spans of blocks such that each producer is entrusted to create ten (10) new blocks in the round for which they are elected. How they are elected into these rounds takes place as follows.

In the event that a producer or validator fails to perform the work that was entrusted to them, their “trust” rating will fall for each block that they fail to producer and/or submit a validation result. If their trust rating falls below the lower threshold (TBD), the stake they put forth to submit their node as a candidate will be locked indefinitely (aka. burned).

First, we take the hashes of every block in the now closed round \{B_1, B_2, B_3, \dots\} and calculate the Merkle root for those hashes to establish M as the election seed for the next round.

We then take M and convert that to a scalar p:

p = H_s(M)

Then compute the public key P of p:

P = pG

We then tally T the individual bytes of P to determine if the result is odd or even.

T = \{P_1 + P_2 + \dots\} \mod 2

  • If T is odd (T \equiv 1) we collect public keys from the candidates list that are T \geq P.
  • If T is even (T \equiv 0), we collect public keys from the candidates list that are T \leq P.

Once the collection of public keys in the new defined range have been collected. We review the number of votes (stakes) received for each public key and construct a listing of candidates with their tally of active votes. The list is then sorted by vote count in ascending order and the top and bottom candidates in the results are discarded. The total votes submitted for the remaining candidates are then tallied to arrive at a total votes casted count (V).

The resulting candidates are then assigned ranges for which the selection algorithm must land for them to become a producer/validator.

If the remaining candidates consist of:

Candidate 1: 11,583 votes
Candidate 2: 25,749 votes
Candidate 3: 99,000 votes
Candidate 4: 127,342 votes

The the ranges for each node are as follows:

Candidate 1: 0 - 11583
Candidate 2: 11,584 - 25,749
Candidate 3: 25,750 - 99,000
Candidate 4: 99,001 - 127,342

We then perform the selection of the first producer via e_1 = p \mod V. The value of e_1 is compared against the node ranges thereby establishing that node as a producer.

On the next iteration of the election process, the previously selected node (e_n) is removed from the collection and V is recomputed before the selection algorithm runs again. Thereby guaranteeing that we do not elect the same producer/validator into more than one round slot.

The process is repeated until the required number of producers (more detail later) have been selected for the next round. At which point, the same process is performed for the candidates on the opposite side of P as T had dictated for producers until we have selected enough validators for the next round.

In the event that we are unable to select the necessary number of producers or validators from the pool of candidates as required for the round (i.e.. there are less candidates than there are required slots) the number of required producers/validators will be decreased until there are enough candidates to fulfill the request; however, at no point shall the number of producers and/or stakers for a round be an even number of spots.

There will always be a minimum of three (3) producers and/or validators required in a round. The number of required producers and/or validators for any given round will adjust dynamically (details to come later).

Pseudo Random Selection of Validator & Staker Selection for Block Rewards

When a block is produced, the producer must include relevants outputs to not only pay themselves but to also pay a deterministicially selected validator as well as stakers that staked the producer and that validator.

To select who receives the reward(s) we perform the same selection algorithm as we do for producers and validators with the exception that the prior block hash is used in place of the Merkle root for the previous round (M).

In the case of selecting which validator gets rewarded, the process is ran exactly once (1) for the set of validators for that round.

For determining the stakers to reward, the process is completed exactly ten (10) times for the set of stakers staking the winning producer/validator and the number of stakes the staker has submitted for the given candidate determine their “vote count”.

If, any time during the loop used in selecting stakers, the number of available stakers is exhausted (there are less than 10 stakers that backed that producer/validator), the process resumes as if all stakers are included in pool again and the iteration(s) continue until the necessary ten (10) stakers are identified for reward.

After completing the above, the producer then constructs a transaction for inclusion in the block that rewards the parties in the percentages necessary such that there are twenty-two (22) outputs in the miner transaction that is included in the block.

  • 1 for the producer
  • 1 for the selected validator
  • 1 each for the 10 stakers of producer
  • 1 each for the 10 stakers of validator

The entire process is designed with a sense of pseudo-randomness that can be recreated by every node on the network using the defined process. In essence, the whole reward structure is a bit of an election with an upper and lower house as well as a lottery for those that backed the elected producer/validator.

The Issues in a Nutshell


Problem: The current blockchain is very, very, very big, and growing every day whether transactions are included in blocks or not. There is also an insane amount of bloat in the chain including transactional spam (fusions anyone?), CantiPixels, and gobs of other useless data that is like walking around with cement shoes with two boat anchors tied chained to your ankles.

Solution: Relaunch the chain. Out with the old and in with the new. To facilitate this, we’re going to need to let the coins on the old network burn in a provable way to prevent errant inflation or other nefarious incidents. In addition, the old chain must be spun down in such a way that the chain officially ends at a certain block. Users need a way to transfer their funds from the old chain to the new chain and that means we’re going to need a…

Coin Swap

Problem: We have to efficiently move funds from the old chain to the new chain.

Solution: A coin swap window of opportunity. The coin swap window to the new chain will be 1,000,000 blocks (as measured by the old chain) during which time users will submit transactions on the old chain to a predetermined wallet address that will serve as a burn address whereby no one user can pick up the funds out of that address (this will be a multisig N:N wallet to make sure no one party controls it). An outside watcher server will watch for transactions on the old chain going to that wallet as instructed by the swap “service”, and release funds on the new chain to the address/keys provided by the user. The swap itself will be funded via a pre-mine on the new chain equivalent to the estimated circulating supply at the time of of the end of the old chain.

After the swap window completes, the remainder of pre-mine funds will be redistributed on chain.

Note: The redistribution of any unclaimed (whether through inaction or as “lost” wallets) via block rewards will be executed over a number of rounds on the new chain to attempt to ensure a somewhat even distribution of those funds to producers, validators, and stakers. Details on the exact schedule of distribution will come later as it will be highly dependent on how much TRTL will have to be dealt with.

In short, the swap mechanism will be a website that helps you transition from old coins to new coins. The technical mechanics of which will be discussed in later articles.

Wait… the chain is massive… we can’t just carry over everything from old to new we have to think about…

Swapping 107,198,508+ Outputs…

Problem: Swapping over 100M outputs to the new chain is… let’s put it simply, incredibly stupid. If we were to do that, yes, the new chain would not have the history of all of those outputs, but considering that we don’t know which outputs are still spendable, there is an unknown number of outputs that we have to create on the new chain as part of the swap process. That number is somewhere between 0 and 107,198,508 (as of the time of this writing). That’s just insane not only to think about but to also execute on.

Solution: During the relaunch of the network and required coin swap, we will be performing the equivalent of a 100,000:1 TRTL (or 10,000,000:100 atomic units) swap while maintaining two decimal places. Swaps of less than 1,000 TRTL will simply become dust and will not be swappable. Don’t worry though, the swap “service” will gladly take your unoptimized outputs and give you brand spanking new optimized outputs.

This swap ratio will eliminate the need to transfer more than ~81% (as of the time of this writing) of the outputs on the old chain thereby avoiding the pollution of the new chain with much of the problems that exist with the current chain.

A Note on Coin Swap Transaction Fees

The swap service will be set up such that as long as 100% of the funds in a transaction sent to the swap service are actually sent to the swap service (no change outputs) then all network transaction fees you pay to send those coins to the swap service will be included in the amount that you receive on the new chain. Furthermore, the swap service will have the ability to bypass the new chain transaction fee mechanics so that you receive the full value of your swapped funds at the ratio given (truncated to two decimals).

A Sustainable, Usage-Based Emission

Right now our blocks come out every 30 seconds, empty or not, and this keeps our emission at a steady pace toward the maximum of 1 Trillion TRTL some time over 100+ years from now. On the new network, there are no empty blocks, and block times won’t mean anything, so we cannot rely on that timing to release new coins into the supply.
Given that the converted supply is quite low (10 Million, two digits after decimal), and block time is now irregular, we have come up with a new way of keeping new coins entering into the system.
On TRTL v2, the network will match all base fees 1:1 with additional coins, making our emission tied to actual usage on chain. 10 Million would be a soft cap, and given enough usage to provide a demand for more coins, more coins will automatically become available via the fees produced by transaction volume.

Now What?

From here, we’re working at solidifying protocol level communications, working on designing the next generation p2p network itself, working on basic structures (transactions, blocks, etc.) and defining some of the inner workings of the actual consensus mechanisms that we’ll be introducing. We’ll provide additional details as they become available. Until then, keep chatting and don’t forget to let us know what you think at

Feature Story

TurtleCoin v1.0.0 Upgrade



Master Build Status

Build Status

Special Notes

Upgrade to this release is required

Network Upgrade at block 3,000,000

This release includes a mandatory network upgrade at block 3,000,000 that implements a change to the Proof of Work (PoW) algorithm for the network to Chukwa v2 (1 Thread, 1MB memory, 4 iterations). Pools, nodes, and services are required to upgrade to this new PoW to continue mining blocks at block 3,000,000 as blocks mined with the previous version of Chukwa will be rejected.

Daemon API Changes

The daemon API has changed significantly in this version. The vast majority of the API calls have been removed, migrated, or otherwise adjusted such that all services using such API require that you perform updates to your packages. The API calls have moved to a most RESTful approach and the endpoint routes have changed. Please see for information on what the new API looks like and update your packages accordingly.

Note: Please be mindful when updating your packages that the property names in the returned responses including their name, case, structure, and/or data type may have changed.

Client / Wallet Upgrades are Mandatory

The API changes indicated in the daemon require that you use the latest version of the core wallet software. If you use a wallet other than wallet-api or zedwallet++ that wallet software must be updated to support the new API. As such using older wallet software with public node(s) that have upgraded to this release will fail until your wallet software is upgraded.

End of Life (EOL) and End of Support (EOS) Notice

Please note that v0.28.3 was the last release to contain turtle-service. This release no longer contains the turtle-service binaries or source code and thus is no longer supported. You must convert to wallet-api to continue working with the network as it is the only service to be upgraded in conjunction with numerous daemon API changes. If you have not converted your wallet(s) and or services over to Proton, zedwallet, or wallet-api you are encouraged to do so now. Should you experience any issues working with wallet-api, please make sure that you open an issue so that the issue may be resolved as quickly as possible.

Legacy Wallet Support Removed

Support for legacy wallets (ie. those created with simplewallet and/or turtle-service) has been removed from the project. We highly suggest that you upgrade your wallet(s) using a prior version of the core suite via wallet-api or zedwallet++ or recreate your wallets from the recovery mnemonic or keys using zedwallet or wallet-api.

As always, make sure you have backed up your keys as that is the only foolproof way to restore your wallet in the event of an issue.

Release Notes

General Updates

  • Bump version to 1.0.0
  • Removed turtle-service
  • Removed NodeRpcProxy
  • Removed support for legacy wallet versions
  • Removed WalletUpgrader
  • Removed support for upgrading legacy wallets to new wallet format
  • Removed WalletGreen
  • Implemented consensus change at block 3,000,000 via major block v7 to Chukwa v2
  • Replaced all usage of nlohmann::json with rapidjson
  • Updated coverage of TX_EXTRA field parsing
  • Numerous CI/CD process changes in support of newer GH runners

TurtleCoind Updates

  • Required P2P minimum version bump to v11
  • Upgraded API endpoints to RESTful style calls (see.
  • Resolved a bug in the retrieval of headers such that the iterator was decrementing below 0 and thus trying to look for blocks that will not exist
  • Change the /indexes endpoint to be inclusive of the end height supplied
  • Added explorer property to the /info API call
  • Adjusted TX_EXTRA field ordering in block templates such that they are ordered by tag type (ascending)
  • Catch and handle segfaults when block is not found in some explorer methods

zedwallet++ Updates

  • Updated user expoded file path opening with error messages
  • Added --reset CLI flag
  • Added rewind to height CLI flag
  • Updated WalletBackend to rewind on subwallet import

wallet-api Updates

  • Updated WalletBackend to rewind on subwallet import
  • Added rewind endpoint (see documentation for more information)
  • Prevent the import of wallets that already exist in the wallet container
  • Update Regex matchers in API endpoints

miner Updates

  • Updated support for new daemon API
  • Updated support for Chukwa v2

cryptotest Updates

  • Inclusion of Chukwa v2 test hashes and verification

Known Issues

  • N/A

How To Sync Quickly

Visit the checkpoints how to use site for simple to follow directions on using checkpoints.

How To Compile

Please see the How To Compile section of the project README for instructions on how to compile this release on your system.


See the TurtleCoin Release page for the full change history.


Cryptonote Developers, Bytecoin Developers, Forknote Project, TurtleCoin Community

Feature Story

The TurtleCoin Journey: 2 Years and Counting…

Earlier this month, TurtleCoin celebrated its two year anniversary of starting the project. The community and project have come a long way in the last 24 months and we are all proud of what we, as a community, have accomplished during that time. That’s not to say that we didn’t have a few set backs, learning opportunities, and challenges to overcome that tried our patience at times and ultimately drove the community to make changes to how the network and core suite operates. From multiple PoW algorithm changes, difficulty calculation changes, and a move to static mixins, each change was evaluated and adopted by the community with excitement and hopes for the future health of the network.

We’ve heard the pleas of the community over the last two years and by far the majority of the requests revolved around the folowing:

  • What is the community doing about the chain storage size?
  • When can the community expect more stable daemon/node operation?
  • Is RockSteady Satoshi? (TBD)

These pleas have not fallen on deaf ears and the result of those requests include a culmination of upcoming changes to the network and software with the next release of the TurtleCoin core suite. We are very excited about these changes and believe they are important for everyone to understand.

zedwallet (Legacy Edition)

The application formerly known as simplewallet

Zedwallet Legacy: End of Life

We announced in the v0.20.0 release notes that the legacy version of zedwallet contained in that release would be the last and final release containing legacy zedwallet. This statement still holds true and the code for that old version of zedwallet has been removed from the project. The next release of the core suite replaces the binary named zedwallet with zedwallet++ which is a new, faster, stronger version of the CLI wallet software. The zedwallet binary released going forward will be powered by zedwallet++.

Zedwallet Legacy: End of Support

We also announced in the latest release, that support would end for legacy zedwallet December 31, 2019. Starting January 1, 2020 if you ask for help with legacy zedwallet issues, we will kindly insist (with a stick in hand) that you upgrade your wallet using the latest release of zedwalletwallet-upgrader, or wallet-api. Again, the old code has been removed, lost, buried, and forgotten about at this point.

But, Why?

Don’t be that guy, don’t say you didn’t know.

Simple: portability, maintainability, and scalability. Legacy zedwallet (also turtle-service) based on WalletGreen creates wallets using a very unfriendly internal wallet schema that makes it very difficult to work with in different languages, platforms, and etc.

The new hotness, WalletBackend, creates a friendly, easy to use, fully documented, and portable wallet schema that is a JSON object when decrypted. WalletBackend lowers the barrier of entry for other developers to work with data created by the core tools and thus makes it far easier to develop other cool portable projects like TonChan and many others.

Deterministic Subwallets

It’s pretty much like a choose your own adventure book

We’ve updated the code in WalletBackend to default to the deterministic creation of subwallet addresses and support the restoration of those addresses in a deterministic way. This change is designed to help services in being able to quickly restore subwallet in the event that they lose any subwallet keys.

Instead of generating new random spend keys for each new wallet created in a single container, new wallets in the same container are now derived from the primary wallet address. The details of the how we derive subsequent private spend keys for subwallets is detailed in Issue #831.

Making subwallet private spend key generation deterministic allows for the restoration of any subwallet by just maintaining its index (position) in the wallet container. No more need to store all those extra keys! This is a major improvement for the teams in the community that handle subwallet addresses and users who use subwallet for a variety of purposes.

TurtleCoind Threading

Threading solves everything


Zpalmtree has worked tirelessly to implement process threading into the core daemon for the RPC interface. This helps keep the RPC interface responsive during heavy load and greatly reduces the impact to the network when the transaction pool gets hit with an influx of transactions. This change will help minimize the effects of heavy load on the network and improve the overall stability of node operations.

Transaction Input Validation

Zpalmtree also added support for threading of the input validation routines for new transactions entering the network. This allows inputs to be validated in parallel and thus drops the transaction validation time considerably. In doing so, transactions enter the network, are propagated across the network, and are ultimately included in blocks faster.

Transaction Pool Changes

How the transaction pool is managed by the core software has been changed recently to help decrease the effects of transaction spam, chain bloating, and other less than helpful actions on the network. We quickly noticed some less than friendly transaction activity taking advantage of our 30 second block times, low network transaction fees, and our good nature as turtles to bloat the chain with low-cost and free transactions that consisted of only breaking apart their funds into shells and recombining them into whole TRTL over and over again.

Transaction Selection Process

We are not the sort to create our own sorting algorithm to sort our sortables

We’ve improved upon the transaction pool ordering and selection criteria for when a miner creates a new block. In short, we’ll always de-preference transactions that are fusions and low total amount transactions as the odds are considerably better that such transactions are “spam”. As always, miners will prefer transactions with higher fees, size, and other metrics to move transactions through the network faster.

Fusion Transaction Limits

We’ve employed additional changes to the transaction pool where each node’s copy of the transaction pool can no longer accept any more than 20 fusion transactions at a time. All other fusion transactions will be rejected until there is room in the transaction pool for more.

This may result in an extended number of fusion rounds for highly disorganized (non-optimized) wallets. If you haven’t fused your wallet in a while, you might want to do so soon.

The line for the Coinstar starts at the back…

Network Upgrade at Block 2,200,000

We have a few consensus changes coming at block 2,200,000 to help improve the stability of the network. These changes are designed to be as transparent as possible but some will reach out and hit you in the face.

Some of these changes are the result of previous discussions in a meta issue and a thorough review of where the network and software can improve the overall experience of the community while maintaining the goals of the project.

Events unfolding over the last few months solidified in our minds the fact that some people just want to see the world burn and as a community, we must take precautionary steps to ensure the longevity of the project.

Output Creation Limits

Starting at the next network upgrade, the network will no longer accept transactions that create more than 90 outputs per transaction. Why apply a maximum you may ask?

+3,500 new 0.01 TRTL outputs created… why do we need those?

There is no legitimate use case in which a transaction need ever create 3,500+ outputs. All this type of transaction traffic manages to do is bloat the blockchain at the expense of every community member. It also ultimately causes the reverse effect and bloats things even further by stuffing the transaction pool and chain full of fusion transactions. Such transaction cycles serve absolutely no purpose and degrade the experience of all users.

Oh yeah… that’s why we need those: fusion spam.

Fee Per Byte

The Backstory

While setting the minimum transaction fee to 0.10 TRTL at the project’s launch sounded like a good idea at the time, such a minimum has serious long term implications. Most importantly, it costs just 0.10 TRTL to send data (transactions) on the network and that data is stored indefinitely and processed by thousands of nodes across the globe thereby consuming a growing amount of resources.

Using such resources is not free and unfortunately, as the chain grows, the resources required to operate nodes grows. The more resources required to operate a node, the less people will be able and willing to commit the necessary resources. Simply speaking, 0.10 TRTL per transaction is not maintainable for the long haul operation of the network.

Okay, Great, Now What?

That math stuff you hoped you’d never need, well… I hate to tell you…

Keeping this in mind, with the network upgrade at block 2,200,000, the network will require a minimum fee for each transaction that is based on a calculation of 0.01953125 TRTL per byte of data of the transaction. This equates to 5.00 TRTL for every 256 bytes of data sent across the network.

Increasing the minimum network fee for transactions means that each transaction is required to pay for its existence and the consumption of network resources proportionate to its size in bytes.

This means that the if you send a transaction using a lot of inputs, or a lot of outputs, contains extra data in the transaction, payment IDs, or etc. (increasing the size of the transaction), you’ll be required to pay your fair share to use the network to transmit and store that data.

As the fees for each transaction are included in the miner block reward, miners will be rewarded with these higher fees for processing transactions. The vast majority of nodes on the network are operated by miners (and pools) so the increase in fees will help to offset the costs of operating those resources to run the network.

So… What Now?

What does this mean for the average user? You’ll see an automatic calculation of the minimum network fee when sending transactions. Depending on how optimized your wallet is, how much you’re sending, and what data you include in a transaction, you’ll see the minimum network fee climb from 0.10 TRTL to about 10.00 TRTL at a minimum.

Fusion transactions will remain free so we highly recommend that you keep your wallet optimized. As a miner, you’ll also benefit from raising your minimum payout with mining pools to higher thresholds as you’ll indirectly pay less in fees for the transactions that pay you for your mining efforts.

If your wallet is mostly composed of shells, you’ll want to optimize your wallet before this new fee structure kicks in. If you mine only on the biggest pool or make most of your TRTL through tips, you’ll definitely want to optimize your wallet immediately.

What’s The Catch?

Sending small transactions, when we needed more mixable outputs for fungibility purposes, helped provide the necessary data to make everything possible. This could be done at a relatively low, low, low cost of 0.10 TRTL; however, with this change, sending 1.00 TRTL to someone will now incur a cost of 10.00 TRTL. We’re sure you can do the math there and understand the sending small amounts (ie. tips) less than the network fee won’t make sense going forward.


Changes to the core software, including moving to fee-per-byte network fees, better transaction selection algorithms, and limits on fusion transactions will bring additional stability to the network, the operation of nodes, and help to address the concerns of the community.

Our work doesn’t stop with these changes and we’ll continue to work on enhancing the network, tools, and experience for all of the TurtleCoin community members.

You can do your part by spreading the word regarding these changes, showing your support, and voicing your opinion(s) in the chat.

As always, Pull Requests are your best avenue to shape the TurtleCoin experience.

Weekly Update

This Week In TurtleCoin® (September 24, 2019)

Developer Updates

This is a place where anybody in our community can submit a post about the TRTL project they’re working on. It’s a great way to attract helpers for your project and show people what to keep an eye out for. We encourage you to show works in progress as well as finished products, as we’re happy to see them all and it shows that we’re an active community. To submit your post, click this link

He said it was a “test” but we know he is really REAL_BITMAIN_NO1


If you read last weeks update, you’ll see I was pretty close to making a violetminer release. This release went out a few days ago, and in fact, i made another release just yesterday.

If you didn’t read last weeks update, the major feature is NVIDIA GPU support.

Please download it and give it a go, and let me know what you think. There are binaries for Windows, Linux, Mac OSX, and ARM.

I wrote a guide on how to use it here:

>tfw z writes a guide

The update I made just yesterday, adds SSL pool support. I kinda forgot about adding this earlier, the HashVault admin helpfully reminded me 🙂

If your pool offers SSL ports, you can now connect to them with violetminer – Just download v0.1.1 and set ssl to “true” in your config file.

I also added some better validation of your config file, so if you accidentally mess up your NVIDIA settings, you should get an informative error instead of a crash.

I have a few more quality of life features to add, then I’ll probably start trying to add AMD support.

– Zpalm


It’s been a fun week in the land of TurtleCoin-Utils this week. Forgetting how software you put together, refactored, etc works can drive any developer mad. It started with a simple thought, “I’m going to build out the documentation to make this easy for everyone to use.” Well, all good things start with good intentions, right?

Can it really be that simple?

I’ve added a number of features, most notably of which allows for packing up the utils into a single JS bundle that is super easy to import into web project. It packages up the necessary cryptography (both WASM and native JS) and auto-loads the fastest code. Talk about easy!

In short, I’ve gone through and refactored quite a bit of the code throughout the package including implementing the exposed libraries as classes. In addition, I’ve labored to add JSDoc documentation to the package that allows for building easy to read and follow developer documentation. This makes it a lot easier to work with the TurtleCoin-Utils package. The full documentation has also been published at

– IBurnMyCD

Sometimes, if you try hard enough, you get what you ask for.

TurtleCoin® Core Update

This happened a couple of weeks ago, but I don’t think anyone ever mentioned it. We recently merged a pull request from CapEtn which adds ZSTD compression to the daemon, and enables it by default.

ZSTD is much more performant than the LZ4 compression we had in place previously, and also has a minimal effect on daemon speed from our testing. If you want to take advantage of the database compression, you’ll need to compile the latest development code, or wait for a new release. Then, if you have an existing database, you’ll need to delete the DB folder, or resync your daemon.

You should find that your database folder has decreased to about 59GB from somewhere around 76GB. A quite nice saving!

You can of course disable this option if you want your daemon to be as snappy as possible.

– Core Development Team

TurtleCoin® Website –

yo dawg heard you like menus –

Thanks to The Judge#9063 from Discord who rightfully pointed out the misuse of the Windows 10 logo on While fixing this squeeze, it came to my attention that our own dang website does not only break the Microsoft guidelines but also our own. yikes! Luckily, it was not much of a hassle to fix it.

Meanwhile, I have started the development of a brand new version of Powered by nuxt.js, allowing serverless deployment it will follow a more streamlined design deployed already by our block explorer.

– Fexra

TurtlePay® Blockchain Cache

Quite a bit of performance based changes have taken place in the cache API over the last few weeks. I’ve added redis support to help with the speedy delivery of wallet sync data, started adding different data structures, looked at altering the database schema to squeeze more performance out and refactored quite a bit of code to make it easier to read.

My most recent scheme involves a few changes to the cache system (transparent to users) that will allow me to serve data via the CDN edges that will make wallet syncing much, much, much faster. There’s a few things to work out to get that going but I have it framed up in my mind and am ready to get going on it to see how well it performs.

– IBurnMyCd

TurtleCoin® Web Wallet

This week updated the styling of the web wallet according to TurtleCoin brand guidelines and completed validation on wallet creation. andrew | in the Discord chat was so kind to show me how to properly use Vuex store. Recently, I have decided to give nuxt.js a try, and decided to use this framework also for this web wallet, which currently only uses vue.js. nuxt.js extends vue.js by offering various presets to build progressive web apps that are SEO friendly and can be hosted in serverless environments.


These… you can actually help us with

Good First Issues

Good First Issues are tickets that are marked as ‘easy wins’ for new developers. If you want to be a TurtleCoin® Developer, these are great tasks to start with!

  • Use matches property in ApiDispatcher regex #862
    Some calls in the ApiDispatcher use a regex, for example, getTransactionDetails. They then extract the query parameters. We could instead extract hashStr using the matches property on the req object, by adding a capture group to the hash regex.
  • Remove no longer relevant asserts #811
    Since pretty much everyone runs the daemon in release mode, instead of debug mode, we’ve ended up where we have a number of asserts which constantly trigger, due to altered/moved/rewritten sections of code.
  • Daemon+WalletBackend timestamp adjustments #704
    The current /getwalletsyncdata rounds a timestamp to midnight. Depending on what time of the day you start a fresh wallet, you may have no blocks to grab (we need to roll back a bit more than we currently do with the timestamp adjustment), or too many (since it’s rounding to midnight which is quite far away).

Pay With TRTL

In Discord we have a channel called #Merchandise where people can post things you can buy with TRTL. To view items for sale, check the pinned posts in that channel. These are a few of the items from this week.

All items in our shop:

  • ‘Small NEOS Voyager Overshoes’ by Dustin Thewind |
    ID: #124437
  • ‘Xbox 360 120GB with 10 Games (+1 PS3 Game)’ by Dustin Thewind |
    ID: #196185
  • ‘Alan Wake Collector’s edition (Xbox 360)’ by Dustin Thewind |
    ID: #196847
  • ‘Diablo 3 + ROS Collectors edition’ by Dustin Thewind |
    ID: #362655
  • ‘Lot of Zombie Books (Walking Dead Mostly)’ by Dustin Thewind |
    ID: #654412
  • ‘Lot of 15 PC games (Most of them are redeemed on steam and will not be usable online)’ by Dustin Thewind |
    ID: #654681
  • ‘Lot of Xbox One Games (12 Games)’ by Dustin Thewind |
    ID: #702770
  • ‘eBook’ by DroppingThePacketsHard²#4751
    ID: #726088
  • ‘SC2 Collector Editions (Main Game + 2 Expansions)’ by Dustin Thewind |
    ID: #750847
  • ‘Gigabyte X570 AORUS MASTE’ by Elkim#7747
    ID: #753245
  • ‘Lot of BluRay discs (Movies, Series)’ by Dustin Thewind |
    ID: #858719
  • ‘ASUS X570 STRIX GAMING-F’ by Elkim#7747
    ID: #862191
  • ‘Final Fantasy XIII2 Collector’s Edition (PS3)’ by Dustin Thewind |
    ID: #867107
  • ‘Lot of 4 Nintendo Gamecub Games.’ by Dustin Thewind |
    ID: #957775
  • ‘ASUS X370 ROG CROSSHAIR VI EXTREME’ by Elkim#7747
    ID: #010771
  • ‘Sega Dreamcast with 3 original games’ by Dustin Thewind |
    ID: #081097
  • ‘Wacom Bamboo Tab MTE-450’ by Dustin Thewind |
    ID: #001659
  • ‘Halo Reach Collector Edition for Xbox 360’ by Dustin Thewind |
    ID: #032088
  • ‘Logitech MX Master 910-004337 5 Buttons 1 x Wheel USB Bluetooth Wireless 1600 dp’ by Dustin Thewind |
    ID: #027270

    Provided by fipsi#0789 and DroppingThePacketsHard²#4751
Feature Story

The Quest for Decentralized Proof-of-Work

In this article, we will look at the some of the goals of the TurtleCoin project, the concept of centralization, where the project stands, and what the project is doing to remain true to itself by maintaining its commitment to the community.

TurtleCoin Core Goals

Fun, Fast, and Easy

For those of you that have been to the TurtleCoin website, the goals below may seem repetitive. For those of you that do not know, TurtleCoin was born with a few goals in mind:

  1. Fast Transactions
  2. Privacy
  3. Easy to Use
  4. Easy to Mine
  5. Community
  6. Support

The community is reminded of these goals every time they interact with the network, participate in discussions, and help spread TurtleCoin around the globe. These core values drive everything that is done within the community from core development, documentation generation, learning opportunities, support, and community project management. We take these goals very seriously and will do whatever we can to make sure that TurtleCoin remains true to the initial vision.

Decentralization of Mining Resources

What is Decentralization?

Decentralization is, to put it plainly, the process by which planning, and decision making are shifted away from a central authority or group. The process can take many forms but in our case in the context of a Proof of Work (PoW), it means that no central authority or group controls most of the resources needed to complete the PoW.

Why Care About Decentralization?

When most of the necessary resources to satisfy the PoW requirements end up centralized, those that control those resources can, when motivated to do so, take control of the network away from the community. Such control can manifest itself in ways such as:

  • 51% attack where history can be rewritten which then typically results in the double-spending of currency that is made possible by off chain account balance tracking performed in traditional databases
  • Selfish Mining where miners remain ahead of the public chain and release just enough blocks to stay ahead of everyone else thereby reaping the majority of block rewards

Each of the above attack vectors result in a network that is no longer “Fun, Fast, and Easy”. These attacks are, in the eyes of many, fraud and in the very least theft. No one wants to use a network where their funds are constantly at risk.

In addition to the above sampling of on-chain attacks, centralization of mining resources also poses additional problems when those resources are controlled within, produced by, or otherwise restricted by one or two entities.

Where Does PoW Centralization Come From?

The most common forms of PoW centralization come from technologies designed to make PoW calculations more efficient, including:

ASICs and FPGAs are, to be fair, technologies that help secure PoW networks by increasing the overall hashrate of the network while drastically reducing the resources (electricity, physical space, management, monitoring, etc.) to do so. By increasing the efficiency of mining, others are encouraged to participate in the mining process. The more distributed hashrate a PoW network has, the harder it is to attack via the methods described above.

Supply Chain Centralization

Unfortunately, both ASICs and FPGAs are largely the product of a handful of special interest groups and organizations that create high barriers to entry and generally avoid transparency and accountability. This presents a problem in that a project that embraces these technologies today relies on just a few manufacturers to create the specialized ASICs and FPGAs needed to secure their blockchain.

While this may not sound like that big of a deal, all we have to do is think back to the countless instances in history where one group controlled the supply of a product or service.

Such centralization of manufacturing also presents a problem in that the production of ASICs and FPGAs for mining now falls under a limited number of jurisdictions. Governments could, and have, changed the legality of producing, owning, or operating such hardware on a moment’s notice. The fact that a single entity could control the hardware necessary for operating the network is in direct opposition of the goals of decentralization.

To prevent centralization of the manufacturing of the hardware there must be a multitude of manufacturers spread all over the globe. Only then is it possible to reduce the risk of a single group impacting the supply chain of ASICs and FPGAs.

Note: CPUs suffer from some of the same issues mentioned above; however, CPUs are general purpose integrated circuits that are commercially available in large quantities at affordable prices and their manufacturers are not solely focused on cryptocurrency mining activities.

TurtleCoin’s Commitment to Decentralization

The TurtleCoin community and core development team remains committed to the stance that TurtleCoin must be easy for all to mine, fair, open, and most importantly decentralized. We’ve posted numerous articles, videos, and GitHub threads reaffirming this commitment since the inception of the project. Notable examples of such include:

While others may deviate and split from their goals of decentralization, the TurtleCoin community remains fully committed to the vision that a decentralized PoW remains our best chance at long-term sustainability.

Upcoming Proof-of-Work Algorithm Change

The upgrade to CN Turtle at block 1,200,000 was a success; however, as mentioned in the Proof-of-Work Algorithm Change, we’ve had another algorithm change on the burner well before that upgrade. We always knew that CN Turtle would be a temporary step meant only to give us a bit of breathing room to test, what we hope to be, a PoW algorithm that will prevail in our quest for decentralization for longer than prior algorithms have allowed.

We have mentioned codename Chukwa in a few different places over the last few months. If you have not been following discussions in Discord or taken at look at the GitHub Chukwa Hashing Results thread, Chukwa is actually Argon2.

What is Argon2?

Argon2 is the memory hard winner of the 2015 Password Hashing Competition (PHC). Argon2 comes in three different versions; each with their own design goals.

  • Argon2d is designed to maximize resistance against GPU cracking attacks and accesses memory in a data dependent order. This means that the input data itself defines how the memory is accessed; however, it is susceptible to side-channel attacks
  • Argon2i is designed to minimize side-channel attacks and accesses memory in a data independent order
  • Argon2id is a hybrid between the two where Argon2i is used for the first pass over the memory and Argon2d is used for each pass after that

The Argon2 IETF RFC draft recommends the use of Argon2id.

Why Argon2?

Argon2 was selected for the following reasons (in no particular order):

  • Winner of the PHC that follows the same kind of processes as the NIST’s AES & SHA-3 competitions
  • Memory hard algorithm
  • Source code is GPL-3.0 compatible
  • Easily integrated into the core code, pools, etc
  • Only one known cryptocurrency project (Aquachain) uses Argon2id

Argon2 is also relatively unique in that it allows for a high-level of customisation in how the hashes are calculated including parameters such as:

  • The number of threads to use (parallelism)
  • Arbitrary resultant hash length
  • Memory requirements (memory hardness)
  • Number of iterations (time cost)
  • The use of salts

Argon2id Parameters

The various input parameters allow us to tune the implementation of Argon2 such that it makes sense for TurtleCoin.

Memory Requirement
  • Be large enough to fit an entire block so that all of the data can be shuffled
  • Not exceed common L2 CPU cache sizes to allow for the largest range of CPUs to participate in mining
  • Provide a higher base hashrate than previous algorithms to increase the mining efficiency
  • Take advantage of the multiple memory passes used in Argon2id (>2 iterations)
Parallelism (Threads)
  • Make the use of as many physical and logical cores as possible by using 1 thread per hashing operation
Benchmark Testing Results

We solicited single-core performance benchmarks from the community in the Chukwa Hashing Results issue thread on the main repository. The summary of those results are below.

Note: For brevity, we have truncated the summary table below to the algorithms we have used before and Argon2 parameters that meet the requirements above.

Chukwa Parameters

Given the above requirements and the testing results provided by the community we were left with 5 clear options. One option stands out and sits nicely in the middle among the group of options. It provides a healthy 2.5x increase in hashrate and meets the requirements above.

We’ve selected the following Argon2id parameters for the next PoW:

  • Threads: 1
  • Iterations: 3
  • Memory: 512kb

Note: You can play with different parameters with a simple Argon2 hash generator at

TurtleCoin’s Argon2 Implementation

Like other PoW algorithm changes, there is quite a bit of work to be done to ensure that this network upgrade is a success at block 1,800,000. We have adapted the Argon2 reference implementation for our use.


Miner Package Availability

At this time, we have found very few miner packages that support Argon2id. While the native CPU miner provided in the core project will happily support the algorithm for solo mining, we understand that the network and community requires the availability of mining pools. To help facilitate pooled mining, we are currently working on building pool support into the native CPU miner provided by the project.

GPU Mining Support

We have not currently been able to find any miner packages that support Argon2id GPU mining. While we are confident that the community at large will work towards having an Argon2id GPU miner available at some point, it is unlikely that a GPU miner will be available at the time of the upgrade. As a result, we fully expect a substanial drop in the network hashrate as a result of this upgrade. We are planning a difficulty reset to account for this drop at the time of the upgrade. This has a byproduct of making TurtleCoin a CPU only coin for the foreseeable future.



We have completed the necessary changes in the core project to implement Argon2id at block 1,800,000 that will activate with block major version 6. The changes can be found on the codename_chuckwa branch of the TurtleCoin repository. This code has not been pulled into the development tree or master as of the time of this writing.

Support Packages

The necessary changes have also been applied to the development branch of the turtlecoin-multi-hashing Node.js module that pools use to validate miner shares.

Pool Changes

The necessary changes to the turtle-pool software have been completed on the chukwa branch.

In Progress


We will also be launching multiple testnets to test the algorithm change including a difficulty reset to adjust for the anticipanted loss of GPU mining hashrate.

How You Can Help

We need help from the community to test this algorithm change to try to ensure that everything goes as smoothly as possible. The more people that are involved, the easier it is to spot issues and correct for them before the upgrade.

Community Reminder

As always, be mindful of TurtleCoin core releases. Watch or star the main TurtleCoin repo to help stay abreast of changes and updates. Join Discord and read the #announcements on a regular basis. Or, sign up for the @news role by typing *news in the chat and be alerted whenever a new announcement is posted in Discord.

Make sure you’re ready for the network upgrade as early as possible. As with any network upgrade, prior versions of the software will no longer be compatible with the rest of the network after upgrade completion.

Remember that you too can participate in discussions regarding the direction of the project via Discord and the TurtleCoin Meta Issues. Join the discussing regarding the PoW change via the Chukwa: The Argon2 PoW Algorithm discussion on GitHub.

Correction: The article above was corrected to reflect the intent of the writer as the original copy referred to the security of PoW networks based solely on the network hashrate and not the distribution of such. Thank you to @Taegus for pointing this out.