---
# System prepended metadata

title: 'The TurtleCoin Journey: 2 Years and counting...'

---

# 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 ultimiately 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](https://cryptobellum.com/2018/06/04/searching-for-satoshi-nakamoto-is-turtle-coin-creator-rocksteady-also-the-pseudonymous-creator-of-bitcoin/))

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)

### End of Life

We announced in the v0.20.0 [release notes](https://github.com/turtlecoin/turtlecoin/releases/tag/v0.20.0) 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++`.

### 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 with the using the latest release of `zedwallet`, `wallet-upgrader`, or `wallet-api`. Again, the code has been removed and 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 hottness, WalletBackend, creates a friendly, easy to use, fully documented, and portable [wallet schema](https://github.com/turtlecoin/wallet-file-interaction) 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](https://play.google.com/store/apps/details?id=com.tonchan&hl=en_US) and many others.

## Deterministic SubWallets

We've updated the code in WalletBackend to default to the [determinisic](https://en.wikipedia.org/wiki/Deterministic_algorithm) 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 SubWallets 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](https://github.com/turtlecoin/turtlecoin/issues/831).

Making SubWallet private spend key generation deterministic allows for the restoration of any SubWallet by just maintaining it's 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 SubWallets for a variety of purposes.

## TurtleCoind Threading

### RPC

Zpalmtree has worked hard 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 on the 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

### 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 depreference 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 whereby 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**.

![](https://i.imgur.com/I0Tq3Tb.gif)
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](https://github.com/turtlecoin/meta/issues/146) 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?

![](https://i.imgur.com/zWNOmaZ.png)

There is no legitimate use case in which a transaction need ever create 3500+ 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.

![](https://i.imgur.com/inNlnzk.png)

### Fee Per Byte

#### A Bit of 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. 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 it's 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.

#### Okay, so...

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.

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

## In Summary...

We believe that these changes, among many others in the works, 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.