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)
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 zedwallet, wallet-upgrader, or wallet-api. Again, the old code has been removed, lost, buried, and forgotten about at this point.
But, Why?
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
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
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’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.
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?
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.
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?
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.
TurtleCoin Docs – 1000th commit! – Just wanted to say, the TurtleCoin Docs (docs.turtlecoin.wiki) just got it’s 1000th commit; it’s 1000th update, since its inception in around March of last year. Huge thank you and shout out to everyone who made this possible, and here’s to another year of more updates and information! – Sajo8
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:
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:
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.
The Argon2 IETF RFC draft recommends the use of Argon2id.
Why Argon2?
Argon2 was selected for the following reasons (in no particular order):
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:
Argon2id Parameters
The various input parameters allow us to tune the implementation of Argon2 such that it makes sense for TurtleCoin.
Memory Requirement
Iterations
Parallelism (Threads)
1thread per hashing operationBenchmark 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:
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.