Categories
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 TurtleCoin Official Podcast

This week we bring you a development update, talk about the struggle of maintaining a large community, and bring in a new guest who found his way to TurtleTurtle.club and is helping out in a few places
  1. The Struggle Is Real
  2. Shell Shopped
  3. Shitcoin Forkers!
  4. My Blockchain Is Smaller Than Yours
  5. Proof of Waste

Or find the podcast via your favorite platform.

Categories
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.

Categories
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.

Categories
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 🙂

Categories
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.

Bulletproofs+

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

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.

Categories
Feature Story

TurtleCoin, My Problem Child

I recently came across a bounty in the TRTL Discord for an article about TurtleCoin. The requirements were loose, it was mainly just a length requirement, so I figured I’d brew up some coffee and give it a shot.

Thanks to Keda666 for reminding me to post this.

Starting a coin network is easy. Taking care of one, helping it grow, keeping it healthy, giving it good guidance – those are the hard parts. My name is RockSteady, and TurtleCoin is my problem child.

With an introduction like that, you might be thinking that I regret creating TurtleCoin or that it is a mistake in the sense that it was a failure, but quite the opposite as Bob Ross might say. TurtleCoin was created at the height of the crypto-boom of December 2017. At the time you could create literally anything, put “crypto” in the name, and sell it for millions, even if it didn’t exist (RIP BitConnect, never forget).

Out of the plethora of networks that were coming out, a little privacy category emerged. You had DASH and the masternode networks, you had Zcash with the optional privacy networks, then you had Bytecoin, Monero and the rest of the Cryptonote family with stealth addresses and fulltime privacy… and off standing in the corner, struggling for attention and trying to peer above the shoulders of the Cryptonote family is little TurtleCoin with a pizza stained shirt and light coating of Pabst Blue Ribbon.

As you may or may not know, TurtleCoin was a fork of Bytecoin. Incidentally, TurtleCoin and Monero for the first 3 years shared the same codebase, which came from an old retired version of Bytecoin. The way the privacy works in TurtleCoin and Monero is that if you think of every transaction as a handful of coins and dollars, each coin or dollar is matched up with a handful of others on the network and spent in a way that an observer can’t tell whose coins participated in the transaction, and nobody can scope out your transaction history or balance without being given keys to see it.

So, big deal, right? You fork some code, then change all the mentions to the old guys, throw in a little pizzaz, maybe some ninja turtle memes, and boom you’re off to the races, right? Shitcoin starter pack.

Unfortunately that is mostly true for some networks, at least to get the coin off the runway and into the sky. It takes almost zero work to fork code, change some variables and launch a network, but if the hundreds of projects people created based on our code are any indicator, it takes much much more than that to keep a network functioning and thriving.

Lets get to the problem child part.

A big reason why none of these forked networks exist anymore is that your network is like a little pot of gold, always out of reach, but for those smart enough you can find ways to make things easier as miner, or when all else fails, make things harder for everyone. Over the years, through the system of mining coins alone, we have seen it all with regards to the measures people will take to overcome the rules of the network to drive up their profit just a few points while having disastrous effects for the rest of us.

At times we have seen people forging timestamps for mined blocks, pulse mining the network to skew the difficulty enough so that many coins are produced in an hour, then when the difficulty climbs as a result, the miner leaves for another network with lower difficulty and leaves us to mine slow blocks for an hour before they return as the difficulty goes back to normal. Wash, rinse repeat. We even saw people so bold as to incorporate TurtleCoin as the payload of botnets, presumably to get more mining power.

Miners and their grubby little hands were the least of our troubles, along the way we noticed bugs that either got exploited and created a fire that we had to put out (like the fusion spam), or bugs that hadnt yet been exploited luckily (like the remote RPC bug). Sometimes when you fork code from others, this is the risk you take.

Maybe it is getting clearer why we don’t have as many TurtleCoin forks around anymore. If it isn’t so clear, here is an analogy – If you put a plane in the air, and stop refueling it, it will eventually touch the ground.

With all of these problems, TurtleCoin still prevails, and has not to this day had a single attack on the protocol that caused a loss of funds from any user, and with a pot of gold at the end of the rainbow as big as the remaining emission, nobody has exploited that either. (at the time of this writing, TurtleCoin still has 91% of the supply left to be mined)

Three years later, TurtleCoin still receives new code every day, new features, improvements, fixes – and still has users transacting despite the price being the lowest it has ever been in history. During these three years, as a team we have seen hundreds of networks spawn from the TurtleCoin code. These networks may have been other peoples hopes and dreams, Id imagine.

“Finally this will be the one” some of the forkers might say, before they sell off their entire premine and start the next project.

Today I can think of two networks that forked us that are still functioning, and of those two, when I think of how many receive software updates, Id have to say it is maybe one that is still actively developed.

As we round our way into the second era of TurtleCoin, the one where we scrap all code and write something new from scratch, I hope some of this funny business in the markets changes, and I do hope that all the forkers out there get their act together, however irrational they may be. TurtleCoin is our hopes and dreams, our pot of gold, our problem child. TurtleCoin is actively developed and every bit as serious of a project as others, it just has a funny name.

Accept no imitations, TurtleCoin is here to stay. When you think privacy, utility, and low cost transactions without showing the world your balance, think TurtleCoin. When you think about TurtleCoin, think about us, your captains, and a team that wont let you down no matter what the price.

Thanks for listening, I hope you all stick with us for TRTL v2.. its a game changer in the works. No more mining, even better privacy, everything new. Get some while you can, don’t say we didn’t warn you.

Categories
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

Relaunch

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 http://chat.turtlecoin.lol

Categories
Feature Story

TRTL v2

Have a seat, pour a cup of whatever drink you celebrate with, and think about where you left those old TRTL wallet keys. Whether you like what we say next or not, you’re going to need them, soon..

My friends, it is time for us to say goodbye.

Today we hit block 3,000,000. We upgraded our network and our proof of work algorithm for the last time. By block 4,000,000 or in about 1 year from today, the TurtleCoin network as we know it will begin on a path of its own destruction.

A short time after block 5 million, the chain will be dead, and completely gone, unable to produce more blocks.

Don’t panic, we have a plan. I said this would be celebrating 🙂

Sometimes you have to know when it is time to move on, and for us the time is now. Starting today we will be freezing the main core software repository. In the year that follows we will be writing code, documentation, and testing the new software we are already building for TRTL v2.

The next iteration of the software will work best with a blank slate to allow us to improve the network based on the things we learned in our current software. The main changes are:

  • Chain relaunch near December 2021
  • Coin swap w/ reverse split
  • Fair proof of stake
  • New core software

Let’s look into each one of those points and explain what is happening from a high level.

Chain Relaunch

Launching with a fresh chain on new software will enable us to be more flexible in the things we can make the new network do. If we have to operate with the constraints of backward compatibility, we will have to write a lot of code twice and basically build another version of what we have now, instead of something completely new.

Coin Swap w/ Split

Despite having a low emission atomically, our transactions average a large number of inputs. A lot of these smaller inputs now become smaller than the cost of handling them, so we call them “dust”. Think of how many handfuls of pennies you would need to pay for lunch.

To cut down on this dust, we will be reducing our supply by 100,000:1.

If you currently have 10,000,000.00 TRTL on the old chain, on the new chain you will have 100.00 TRTL. If you have 1,000,000.00 on the old chain, on the new chain you will have 10.00 TRTL. We will be keeping the 2 digits after the decimal point and will be keeping the TRTL ticker and wallet prefix.

The above examples of the coin swap amounts were updated after publication to reflect the proper swap math in atomic units.

IBMCD

The new total supply of TRTL will go from 1 Trillion (1,000,000,000,000.00 TRTL) to 10 Million (10,000,000.00 TRTL).

If you have <1,000.00 TRTL today, you will have 0.00 TRTL on the new chain.

The swap will be organized via a website that takes your new wallet address and helps move your coins to the v2 chain. When the swap is complete and the old TRTL chain is dead the old funds will be burned never to exist again.

Proof of Stake

We don’t have a fancy name for it yet, but we have designed a system that could kind of be compared to proof of stake, but it still has a little proof of work sprinkled on top.

TL;DR – There will be staking. There will be no more proof of work for mining.

We have developed an algorithm in-house that involves staking and uses a fair system for selecting block producers where whales have a hard time dominating production without significant cost. To cut down on spam and wasteful transactions, we are using proof of work to derive a proof of importance for each transaction, offering a user the option to compute more rounds of work to lower the fee, or pay a higher fee to send more rapid transactions.

The end result is a block chain that consumes less resources, is less centralized, and incentivizes good peers to stay online and provide good network throughput as we grow in volume. On the new network, there are no empty blocks, either.

New Core

We have already started specifying and building the new core protocols. It made sense to keep the modular approach of daemon+wallet, so starting with the daemon, we are writing it all from scratch. While this means we will no longer be a CryptoNote project, we will still have privacy the way we do now, and with the added bonus of not being a fork of anything, as that seems to bother some people.

Part of focusing all our efforts on the new core suite is to stop slapping duct tape on the old code base. From this point forward, there will be no new features, enhancements, or active development on the current repository. We will, however, review and address any critical issues and bug fixes that are required to keep the network in stable operation. In due time, you will find the current repository archived and read only once we are ready to nail the coffin closed via a consensus mechanism that brings the current chain to its final resting place.

We hope to be able to testnet the new network daemon soon, and I am sure we will need testers when we are ready, so if you have Discord, pop on by the TurtleCoin Discord and let us know so we can put you on a list of testers for when the time comes.

Until then, take care, we look forward to another 3 years with you all 🙂

TurtleCoin® Core Team

Categories
Feature Story

TurtleCoin v1.0.0 Upgrade

image

v1.0.0

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 https://meta.turtlecoin.dev/proposals/daemon-api/ 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. https://meta.turtlecoin.dev/proposals/daemon-api/).
  • 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.

Changelog

See the TurtleCoin Release page for the full change history.

Thanks

Cryptonote Developers, Bytecoin Developers, Forknote Project, TurtleCoin Community

Categories
Feature Story

The Return Of Market Talk

Why? Because it’s fun to do bad things.

For those of you who paid attention during the last roundup, we mentioned that some discussions were happening at the old sandwich cart about a few potential changes around the chat. Turns out we were discussing whether or not the time was right to give a shot at letting market talkers have their own channel in the server.

If you go to the chat right now, there is a room called turtle-traders. If you are surprised, so are we. Keep reading though..

In the beginning…

When the TRTL discord first launched, it was during crypto December and what seemed like the entire world was in the chat talking about all topics under the sun. This had the positive effect of attracting a lot of otherwise unoccupied bright minds… along with a few shitheads, as can be expected with a sample size that large.

We hit 10k chatters almost instantly.

In our price history if you look back far enough when total emission was very low, and sell orders were very thin, we had an early investor who meant well end up purchasing and entire BTC worth of TRTL from the one exchange we were listed on at the time, which caused an instant spike to something in the low 30 Satoshi range.

We have been living that down ever since. Naturally that spike sent what I would say in hindsight are the wrong signals, and buyers poured into the chat with hands on hips, demanding ridiculous things of brand new devs who had just signed, clapping at the nerds while telling them to work harder for their investment and basically justify their commitment to their new crypto-tradegod overlords.

I do not remember how long this went on but we quickly lost a few great devs who were really pushing things forward at the time in interesting directions, because they didn’t sign on for that, they just wanted to be devs, and the rapidly declining price didn’t make that any easier. People I knew personally even left the project. Things were getting bad and something had to be done.

Right when things were coming to a tense crescendo between traders and devs, the SEC began alluding to pending legislation on cryptoasset networks like us, and to pre-emptively get our little Turtle nuts out of the fire, we made the decision to push the traders out of the chat.

It was not a difficult decision.

The first market server

Naturally the traders had to go somewhere. We had two rooms named General in the main server and the lines of chat would move so fast you could not get a word across at all, just type something and send it into the fray while praying for the best. Needless to say there were a troupe of people who needed somewhere to go, and we were just sliding them out the door.

A developer contributor by the name of Madk stepped up and formed his own Discord, which was convenient since he was not closely linked to core at the time, and was not an American, so risk of being hassled by the SEC was very low for him.

I don’t remember exactly how long this server lasted but it filled up quick, and attracted all types. There were many friendships formed there, and a few horror stories as well.

Eventually Madk decided he wanted to take his mod hat off and unceremoniously nuked the server one night. There are a lot of details I am deliberately leaving out here, but you will just have to ask someone who was there to tell you if you are that interested.

Personally, it is my opinion that those who endured those years were better for it as a result, but I am also aware that my opinions aren’t always great.

Except Madk.

The guys might say he was always this way, but I don’t think Madk was ever the same after that.

The next market server

Again, being cast out of their native home land, a group of lads still claiming to be traders along with their pet bots were not ready to let the party die, so a new market server guy emerged from the crowd ready to lead the charge. His name was Buggles.

Buggles created the second market server for those of you around long enough to remember the switch. It was a natural fit and easy transition for many of the people there. Buggles had been part of the community for quite some time at this point, and everyone just moved over.

Ironically this market server did not have much trade discussion. It mainly consisted of the aforementioned lads doing lad things, and being nice, then over in the corner, a few people being berated by the ‘cool kids’ for their support of TRTL. There were accusations of us being a shitcoin, the name ToiletCoin gained popularity in some circles (Xaz still has the username TRTL = ToiletCoin to this day in fact) and though the good times mostly outweighed the bad, that type of stuff is just bad for the image and morale of the users of the network and disrespects those who continue to contribute code and documentation to it. It wasn’t Buggles fault, these problems just seem to dog us since our early history, I don’t think it would be any different if we were another network.

Until that time we had always referred users to a read-only room called Market Talk in the main server where a direct link to whichever market server we were using at the time would be for easy access. It is not that we did not want people to ever talk market topics, we just wanted to keep the main server for support and development so it seemed natural to at least help folks find their way out of the server to keep market talk where it belonged.

As the price dipped further and people got worse and worse views and opinions of parts of our community, I kinda got tired of how users were treated by the traders and removed the link to the market server one day, a decision which even Alien our TurtleCoin CEO said was a good idea.

What followed, I would say, was just unworkable. Probably not my finest moment.

How to kill a crypto discord

After removing the link to the 2nd market server, I was at wits end with having to explain to people who had just agreed while entering the server not to market talk and that yes it was indeed a serious rule, and it started to feel like a chore to exile people. We just want to write code, and all this market talk stuff was distracting us from that.

I made a critical mistake.

If you are not already shouting at me through the screen, I made a critical mistake at the time. I removed the link to an alternative market chat, giving traders nowhere to go. And even if they did get the link, the first impression would be poor when they arrived at the market server, and when they inevitably look for a place to talk shop in the main server, we would send them to the origami chain gang.

This was an unworkable solution obviously.

While everyone was being sent home for COVID and signing on to our discord, I was busy with a broom chasing them out of the chat for trying to blow off steam and shoot the shit with their friends about market stuff.

Soon, less and less people were chatting daily, and while it was the most productive time of my own time at TRTL, pushing code to what I felt was the most impactful project I had contributed to so far, I was frustrated that we were still sinking slowly. I felt like every day was treading water, but it was my own fault.

Market talk & other things we never thought would happen in 2020

A few days went by when maybe only 20 people or so were active in the discord chat, and while these were some of our most productive and dedicated members, I could feel morale draining and just had one of those Fuck it moments.

Fuck it. What is the worst that happens?

I figured, you know, right now is the time when we need eyes on us.. There is no way we are putting all this work into a brand redesign for 2020, we finally have a stable core suite, we are working on completing Karai, one of our biggest milestones this year, and still trying to pump life and fresh memes into a dead discord all day and the chat was still dying.

I am not sure if a market discussion channel will breathe some life into a once very lively server, but we have never been a team to sit around doing the same shit that does not work, or even worse, doing nothing.

We are giving this a shot, we hope you guys make the most of it, and most of all, I hope this brings more adoption for TRTL and its users for 2020 and beyond. We still push code to multiple projects every day, and still see new faces, so while we give ourselves this second chance we hope you guys join us and shoot the shit in the new market room.

Have a good night 🙂

RockSteady TRTL