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 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 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 TRTL today, you will have 0 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 funds will be burned, and the excess funds left unclaimed will go out in staking rewards on the new chain.

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

Categories
Feature Story

Migrating from fixed fees to fee per byte – A developers guide

Welcome, developer!

As you may have seen, we are moving to utilising a minimum fee per byte at block 2,200,000. For more information on the reasons behind this decision, please check out this article from the core team: https://blog.turtlecoin.lol/archives/the-turtlecoin-journey-2-years-and-counting/

What do I have to do?

If you have an application which sends transactions on the TurtleCoin network, you will likely have to update your code to work correctly with fee per byte.

Step one is ensuring you have the latest code. This is currently only available in the development branch on GitHub, but will become a published release once fully tested.

Once you are running version 0.22.0 of the software, you will need to update your code to work with it correctly.

The lazy, expensive way

Since we charge a fee per byte of 5.00 TRTL (Or 500 atomic units) per 256 bytes of transaction, and transactions are limited at 124400 bytes if you’re using the core software, you can just set a fixed fee of 2430 TRTL, or 243000 atomic units.

This fee will always be large enough to cover the biggest transactions, so you can just update your fee parameter in your sendTransaction JSON, for turtle-service, and with wallet-api, update your /send/transaction/advanced fee parameter and you’re done. If you’re currently using /send/transaction/basic with wallet-api, you will either want to migrate to using /send/transaction/advanced, or read on for a method that works with /send/transaction/basic.

However, this is not the cheapest way. In addition, if the minimum fee per byte is increased in a later fork, you will have to update your code again. Booooo!

Read on if you want to make your users like you more. Don’t worry, it’s not hard!

The cheaper way

If you just want to use the minimum fee per byte allowed, all you have to do is not specify the fee parameter in your sendTransaction or /send/transaction/advanced JSON. The wallet application, be it turtle-service, or wallet-api, will then automatically calculate the minimum fee for the transaction. If you are currently using /send/transaction/basic, it does not have a fee parameter, so this is the default behaviour.

Once the transaction is sent, the actual fee paid will be returned along with the transaction hash. This way you can update your database, display the fee to the user, and so on, as needed.

“Hang On!” – I hear you shout. How do you know how much the fee will be before sending the transaction? Not to fear – we’ve thought of that.

turtle-service

With turtle-service, instead of using sendTransaction, you can use createDelayedTransaction. This method works exactly the same as sendTransaction, except it does not relay the transaction to the network – so no funds are sent. It will return the transaction hash, and the fee of the transaction.

If the fee is fine, and you want to send the transaction, you can use the sendDelayedTransaction method.

If you’re not happy with the fee, or want to cancel the transaction for some other reason, use the deleteDelayedTransaction method to cancel the transaction. If you do not delete the delayed transaction, the funds will remain unspendable, so don’t forget this step!

wallet-api

With wallet-api, the process is very similar. Instead of using /transactions/send/basic or /transactions/send/advanced, you can use /transactions/prepare/basic or /transactions/prepare/advanced.

As will turtle-service, these methods are identical to the standard ones, and take all the same parameters.

Again, like turtle-service, these methods will return the fee of the prepared transaction, and the transaction hash.

You can then use /transactions/send/prepared to send your prepared transaction if you are happy with the fee. If you want to cancel a prepared transaction, use the /transactions/prepared/{transaction hash}/ DELETE method.

Unlike turtle-service, a prepared transaction does not lock your funds for spending, and therefore cancelling a prepared transaction is not mandatory. It will, however, save a little bit of RAM usage from not having to store the transaction data.

Due to the funds not being locked, this can result in a previously prepared transaction no longer being possible to be sent – If you sent another transaction meanwhile, it could include inputs that the prepared transaction also included.

Finally, due to a deterministic input selection algorithm, even if your prepared transaction is no longer valid, the fee for sending the same transaction again is likely to be very similar. This means you can essentially use the prepare transaction methods as a means to estimate the fee of a subsequent transaction with the same data.

Specifying the fee per byte

If you desire to pay a higher than minimum fee per byte, we have you covered. Simply include the feePerByte argument in your transaction JSON, in replacement of the fee parameter. This value can be a floating point value, and should be greater or equal to the minimum fee per byte of 1.953125.

Examples

turtle-service example

Request before fee per byte
{
   "jsonrpc":"2.0",
   "id":1,
   "password":"passw0rd",
   "method":"sendTransaction",
   "params":{
      "transfers":[
         {
            "address":"TRTLxxxx...",
            "amount":5000
         }
      ]
   },
   "fee": 10
}
Response before fee per byte
{
  "id":1,
  "jsonrpc":"2.0",
  "result":{
    "transactionHash":"ae57e..."
  }
}
Above: Before, Below: After
Request after fee per byte
{
   "jsonrpc":"2.0",
   "id":1,
   "password":"passw0rd",
   "method":"sendTransaction",
   "params":{
      "transfers":[
         {
            "address":"TRTLxxxx...",
            "amount":5000
         }
      ]
   },
}
Response
{
  "id":1,
  "jsonrpc":"2.0",
  "result":{
    "transactionHash":"ae57e...",
    "fee": 4500
  }
}

wallet-api example

Before fee per byte

Request before fee per byte
{
  "destinations": {
    "address": "TRTLv2Fyavy8CXG8BPEbNeCHFZ1fuDCYCZ3vW5H5LXN4K2M2MHUpTENip9bbavpHvvPwb4NDkBWrNgURAd5DB38FHXWZyoBh4wW",
    "amount": 1234
  },
  "fee": 10,
  "sourceAddresses": "TRTLv2Fyavy8CXG8BPEbNeCHFZ1fuDCYCZ3vW5H5LXN4K2M2MHUpTENip9bbavpHvvPwb4NDkBWrNgURAd5DB38FHXWZyoBh4wW"
}
Response before fee per byte
{
  "transactionHash": "396e2a782c9ce9993982c6f93e305b05306d0e5794f57157fbac78581443c55f"
}

After fee per byte

Request after fee per byte
{
  "destinations": {
    "address": "TRTLv2Fyavy8CXG8BPEbNeCHFZ1fuDCYCZ3vW5H5LXN4K2M2MHUpTENip9bbavpHvvPwb4NDkBWrNgURAd5DB38FHXWZyoBh4wW",
    "amount": 1234
  },
  "sourceAddresses": "TRTLv2Fyavy8CXG8BPEbNeCHFZ1fuDCYCZ3vW5H5LXN4K2M2MHUpTENip9bbavpHvvPwb4NDkBWrNgURAd5DB38FHXWZyoBh4wW"
}
Response after fee per byte
{
  "transactionHash": "396e2a782c9ce9993982c6f93e305b05306d0e5794f57157fbac78581443c55f",
  "fee": 1000,
  "relayedToNetwork": true
}

Suggestions

There are a few things you can do as a service operator to decrease the fees you pay.

The first is sending round number outputs. For example, sending a transaction of 20000 TRTL will result in a single output, while sending a transaction of 22222 TRTL will result in 5 outputs. Outputs are not the only thing that make a transaction bigger, but this is one of the variables that you can easily control.

The second is increasing default payouts. Instead of creating 10 transactions of 1000 TRTL, and thus creating 10 outputs, you can instead create 1 transaction of 10000 TRTL, which will only create a single output.

Applying these changes will result in you paying less fees, and will also mean your users pay less fees when they come to spend their funds – they will have less resulting inputs in their wallet, so will create smaller, cheaper, transactions.

Closing remarks

Confused? Want some more help?

Start by checking out the documentation of the API you are using.

Finally, if you just can’t get the hang of it, or want some clarification on how it all works, stop by the #dev_learning or #dev_general channels in our discord, and we’ll happily help you out. If you’re not in discord already, you can find the invite at chat.turtlecoin.lol.

Happy Hacking!

Categories
Feature Story

The TurtleCoin Journey: 2 Years and Counting…

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

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

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

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

zedwallet (Legacy Edition)

The application formerly known as simplewallet

Zedwallet Legacy: End of Life

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

Zedwallet Legacy: End of Support

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

But, Why?

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

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

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

Deterministic Subwallets

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

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

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

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

TurtleCoind Threading

Threading solves everything

RPC

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

Transaction Input Validation

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

Transaction Pool Changes

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

Transaction Selection Process

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

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

Fusion Transaction Limits

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

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

The line for the Coinstar starts at the back…

Network Upgrade at Block 2,200,000

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

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

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

Output Creation Limits

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

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

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

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

Fee Per Byte

The Backstory

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

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

Okay, Great, Now What?

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

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

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

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

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

So… What Now?

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

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

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

What’s The Catch?

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

TL;DR

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

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

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

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

Categories
Feature Story

Oh shit, I think it’s dead

For 27 minutes the TurtleCoin blockchain was dead on the table. We shouted at it, poked it with sticks, it was muerto.. Difficulty went from a healthy 2 Billion-ish area to 1, not 1 Billion, but 1, a single digit.

What went wrong? What does this mean?

First, you’re reading this because we’re back online and working. Rest assured everything is fine. We were down for less than half an hour and stayed in touch with services the entire way. Had this gone any worse, you’d be reading this story from the back of a milk carton.

The difficulty with difficulty

Difficulty is the part of mining that makes sure that whether there’s 1 person mining, or 100 million people mining, that blocks stay difficult enough for a miner to solve so that we crack one every 30 seconds. Sometimes it can be 15 seconds, sometimes it can be 45, but as long as it averages 30 seconds over a few day’s worth of blocks, everything is fine.

Our difficulty algorithm is LWMA2, by Zawy12. This algorithm is suitable for networks of our size to keep our block difficulty smooth of spikes in the graph. It uses a moving average based on the blocks that came before the current one being mined to keep a constant adjustment of this difficulty factor so that no matter how many miners join us, all blocks come out as close to 30 seconds as possible.

Normally our difficulty algorithm works just fine, however during fork upgrades, especially ones that will radically change our hashrate, we have to make a best guess ahead of time of where we’ll be before, during and after fork hashrate wise. In this case, our test scenarios told us the difficulty adjustment we chose was good, but as with all things, running in production was a different story.

You can see the actual shit hitting the fan right here.

7:51 PM We first knew something was up, the first 11 blocks on the new algorithm came immediately, and difficulty immediately dropped to 1.

7:56 PM We had formed a plan and had an upgrade in the works when we realized what had happened. At this time we notified in #announcements on discord that there was a momentary delay and to stay tuned for a patch. Major exchanges and block producers were also notified.

Only a single exchange responded to our advisory. Their response time was 3 minutes.

8:03 PM We began tweeting the situation live after a mad scramble to find the login credentials. Not a single complaint was received during the delay, which was absolutely wonderful.

8:12 PM A patch is submitted and being built by CI on github to produce binaries. The source is released as 0.18.1 for others to build on their own while CI builds.

Wait a minute… did he merge without waiting for CI/CD tests to finish?!

8:14 PM Patch seems to work, we begin passing it on via Twitter and Discord to users. To bring some light to the situation we adopt the hashtag #BorkedFork

8:15 PM At this time we’ve received no complaints and only a single exchange responded to our message, which they responded in 3 minutes (Thanks TO, you’re a real one). We hold our breath and wait for the block producing (read: really big) pools to pass enough blocks to make it official.

8:33 PM Things have been going smooth enough at this point that we feel we can say we’ve revived the network and things are currently humming along at a blistering 159MH.

Well done everyone. You all helped each other to relay the correct information regarding the patch and we all made it through this small stumble.

This likely won’t be the last time we’ll go through this but a lesson learned is a lesson earned and we won’t be letting go of what we were taught tonight for quite some time. Thanks everyone who participated, especially IBMCD for providing the patch like a champ in just minutes. Bravo, all of you.

TurtleCoin®  Core Team

Categories
Feature Story

Reminder to upgrade your software tonight!

With the upgrade taking effect in less than 24 hours, we felt it was important to remind everyone to upgrade your software before you turn into a pumpkin!

Before we begin, go here and start the appropriate download for your system: http://latest.turtlecoin.lol

Who?

Chukwa, it’s the name of our new hashing algorithm. To make it brief, it’s Argon2id based, loves CPU miners, and is the first significant departure away from the Cryptonote family of hashing algorithms. Read more here >>

What?

This upgrade mainly concerns people who run mining pools, web wallets, asset exchanges, and other services that rely on the core software for their connection to the network to provide services to you. If you’re just a user, you’ll still want to upgrade, but just be sure to do it before the next time you want to access your funds.

When?

As with all of our network upgrades, you can track them with our handy countdown on the official block explorer. Click here >>

We do these types of upgrades several times per year as part of our commitment to a fair mining environment.

Where?

You can always get the latest software you should be running at this URL: latest.turtlecoin.lol

Why?

We believe mining should be fair for as many people as possible, and that means no ASIC on the network until everyone can have that advantage, which means there needs to be more than a handful of competitive ASIC manufacturers and it needs to be a decision the entire community comes to before we can allow it.

Thanks for reading and being a part of this evolution of the TRTL Network 🙂 if you started downloading the new software when you started reading this, it should be done now.

We thank you for choosing TurtleCoin for your services!

Categories
Feature Story

TurtleCoin Roles and Achievements

know your roles!

Colored chat names, so hot right now

You may have noticed in our weekly roundups that we have a new section for recognizing those who’ve gained new roles in the past week. We get asked a lot about the colored names and ‘roles’ in our Discord chat, and whether people just want the colored name or actively want to contribute to the community, we’re always glad to see someone wanting to involve themselves with TurtleCoin.

This article will be an explainer for each role and what it means to us, and the way to gain them. If you have questions, just ask us!

Let’s start at the top of the list, and work our way down, from what an admin sees when they log in to TRTL discord.

Green names, some say they aren’t even real people

Green names are Ninja, these are founders of TurtleCoin. This is a closed role, there is no way to earn it, it doesn’t even have any extra privileges other than having a green name. There are a few people with a green name, however this is the most chat-inactive role group on the server.

The first troop of goons to step foot off the Mayflower

Footclan is the role that was created when we were just a few weeks old. TurtleCoin started out with a bang, and we worked around the clock for about a month before taking a break. A few of us took vacations with our families and on our return two weeks later, we found the community still ready for more. We made a decision to move forward with the project in earnest that day, and to remember those who were present and helping, we created the footclan role. Footclan, like ninja is a role that is just a color, and has no functional role advantages on the server.

The exalted pink names. Rumor has it they control the media.

Developer is the first of the roles we’ll discuss that can be attained by anybody, and has some merit attached to it. The one requirement to be a developer is to have code you contributed merged into our repositories. Typos don’t count necessarily but if you submit a patch or a fix for something, or if you maintain your own project in our GitHub organization, you get the hot pink Developer role. This role has functions on the server such as managing messages and access to dev-bridge feeds to IRC for other organizations (IPFS, Monero, currently). A good way to get this role is to check out our Good First Issues which are easy, low hanging fruit objectives.

Do you have a liberal arts degree? We’ve got a job for you!

Some folks want to help with stuff like writing guides, fixing typos, creating branding material. We needed a way to acknowledge people who share non-code contributions with us, and this seemed like a good way to do it. Obviously this one is pretty easy to attain, so to maintain some degree of exclusivity, we require that you register an account and Pull Request your contribution yourself. We’ll help, we just want you to be a well-rounded contributor, otherwise we’d have to give this role to every pedant who points out a spelling error, and that’s no fun!

Nobody knows about this role

Core contributor is a Developer who has had code merged into our core software. If you complete a Good First Issue on the core repo, you’ll get Core Contributor and Developer all in one shot. Nobody really asks for this role so we just apply it to people we know have contributed code to the core software as we notice them. No clue why. Also just a color role.

These are the music makers

Service Operator is a role given to people who operate public nodes, pools, web-wallets, tipbot, exchange, and any other application that integrates with our daemon and has an interest in knowing when things are screwy on the network. This role came out of a need of a way to address all of our service providers when we had patch fixes, network advisories, or critical consensus updates. This role gives you access to a private water-cooler type room that gets used about once a month when a large service optimizes their wallets and fills the TX pool with 1000 fusion transactions.

This role is cursed

PR Guerilla originally was a role we gave to people who made heroic acts of recruitment. The first person to get this role, GT3000, recruited over 500 people in a single week. These were active users that flooded the chat due to his efforts, many of them stayed and became contributors. This role is cursed, however, because every person who’s ever achieved it has disappeared immediately after.

Guest Dev is the title for well known core developers of other well known networks. This role was created so TRTL Developers can easily identify core contributors from other well known networks and talk shop with them. If you’re from a TRTL sized network and you’re reasonably active in our chat, you probably already have this role.

Educators have written classes or course materials for the TurtleEDU platform. What’s TurtleEDU you ask? It’s an e-learning platform we made to turn crypto-newbies into knowledgeable users, and take curious knowledgeable users and turn them into contributing developers. If you’d like to be an educator, we’d currently love to have someone write a course on interacting with REST API’s via a class on interacting with Wallet-API. (hint hint, aspiring educators!)

PSSST! Hey kid, you wanna buy a Nintendo? *opens coat*

These guys are basically moderators of the #Merchandise channel in Discord, where anybody can list an item when the bot is working that describes an item and a price in TRTL to sell it for. We’ve got a weekly column for this in the weekly roundup. Technically one could gain this role, but with the new merchandise bot it may be useless as the bot handles most of this stuff. This role came from an era when the merchandise channel was just for posting a single listing per line and not using it as a conversational channel. As things go, nobody, and I mean none of you fuckers can follow a single damn rule and it quickly devolved into conversations so we just opened it up and told people to pin their listings instead. When it works, the merchandise bot is a great thing to have.

Crash Test Turtles

This is a fearless brigade of self-appointed masochists who test all of our software before it is released. To give yourself this role, and a spiffy yellow name, type *tester in the chat and you’ll receive pings when we need testers for new software releases. This is what the report that testers fill out looks like [link]

To gain access to the EDU chat channels, type *student in the chat. This is for people who are in the TurtleEDU program that wish to receive updates about it. The TurtleEDU program is an e-learning platform we created to help people who are new to cryptoasset networks get more acquainted with their surroundings.

Datacenter nerds are the most socially disjointed kind of nerd you’ll ever meet.

These are people who can add and approve and delete or revoke records to the TRTL DNS system. If you’ve ever seen someone with a .trtl domain name, someone with the DNS role approved it. If you want to know more about .trtl domains, check this article out.

Stay away from these people.

We have a disciplinary area called Exile, and if you’ve seen someone with this role, they’re probably in Exile, with a jumpsuit on as evidenced by their name probably being something like Inmate #558929. These are people who you will have to walk down to #exile in the chat to speak to, because although they can read, they cannot reply anywhere else. You can shout at the inmates through the intercom by typing @exiled and whatever your message is. This role has so few privileges, you’re basically in timeout and only people who love you can come see you.

FNG’s

We use a bot some of you know that applies levels and points when people are active in chat. We use it to help identify new or inactive people to get you involved in the community. When you first enter the chat, you’re an Egg. When you’ve said hello or anything really, you become a hatchling. If you stick around even longer after that your name will turn green and you become a Turtle. After that, sky’s the limit, some say there are level upgrades all the way to 100…

These people want to know everything as it happens.

News is a self applied role you can get by typing *news in the chat. This will give you an alert every Tuesday when we post the weekly roundup. This role was Farhod’s idea, who wanted a better way to know when we’ve posted the weekly update.

You shouldn’t want this role.

We label a certain type of user as ‘spoonfed’, and though it could happen for various reasons, functionally it means you cannot post in dev-general, and it flags you as someone who’s likely to pester helpful devs. If you have this role, you should feel shame. People who get this role typically pop in our chats asking a seemingly basic question, then when someone helpful assists them, they latch onto your leg and won’t leave you the fuck alone because they don’t have any interest in learning anything, they just want someone to do it for them. Helping these types doesn’t help them, and it doesn’t help you, and it aids in all of our own abuse. If these people annoy you, stop hitting yourself. You’ll quickly notice every person with this role has a half-broken TRTL-forked shitcoin network that they’re eagerly waiting to dump on unsuspecting miners as soon as it hits market.

This is a role that we just added recently, it has something to do with basically being a moderator for our karaoke bot, Grandmaster Riddim Bot. Not sure what it does exactly as a role, but the bot required it to acknowledge admin commands or something.

Categories
Feature Story

The Teacup Files

There’s a person named Teacup on Discord who makes these delightful TurtleCoin pics we like to use in the chat and in the roundup. A day or two ago Teacup gave us this collection of pics amassed from an illustrious tenure as resident meme artist, so I figured it’d be best to put it somewhere that gets the respect it deserves, right here on our blog!

Also, imgur.com were being some busters about hosting this collection, so we’re hosting it right here. Please don’t melt this server downloading them all, and don’t forget to tip Teacup.

Thanks Teacup 😀 We hope to do a part 2 some day -Rock

Categories
Feature Story

The Quest for Decentralized Proof-of-Work

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

TurtleCoin Core Goals

Fun, Fast, and Easy

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

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

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

Decentralization of Mining Resources

What is Decentralization?

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

Why Care About Decentralization?

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

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

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

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

Where Does PoW Centralization Come From?

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

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

Supply Chain Centralization

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

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

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

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

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

TurtleCoin’s Commitment to Decentralization

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

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

Upcoming Proof-of-Work Algorithm Change

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

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

What is Argon2?

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

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

The Argon2 IETF RFC draft recommends the use of Argon2id.

Why Argon2?

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

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

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

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

Argon2id Parameters

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

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

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

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

Chukwa Parameters

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

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

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

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

TurtleCoin’s Argon2 Implementation

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

Caveats

Miner Package Availability

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

GPU Mining Support

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

Completed

Core

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

Support Packages

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

Pool Changes

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

In Progress

Testnet

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

How You Can Help

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

Community Reminder

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

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

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

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