Feature Story

The TurtleCoin Journey: 2 Years and Counting…

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

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

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

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

zedwallet (Legacy Edition)

The application formerly known as simplewallet

Zedwallet Legacy: End of Life

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

Zedwallet Legacy: End of Support

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

But, Why?

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

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

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

Deterministic Subwallets

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

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

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

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

TurtleCoind Threading

Threading solves everything


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

Transaction Input Validation

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

Transaction Pool Changes

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

Transaction Selection Process

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

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

Fusion Transaction Limits

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

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

The line for the Coinstar starts at the back…

Network Upgrade at Block 2,200,000

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

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

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

Output Creation Limits

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

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

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

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

Fee Per Byte

The Backstory

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

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

Okay, Great, Now What?

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

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

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

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

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

So… What Now?

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

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

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

What’s The Catch?

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


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

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

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

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


From Newbie to Core Contributor w/ ExtraHash

Here, you can see the knuckles lifting gently off the ground as a user becomes a dev

It’s been a while since we’ve interviewed a member of the team and as we just added a new Core Contributor last week it just felt right to pick back up on the article series. Enjoy!

RS: ExtraHash, thanks for taking this interview! You’ve been in the TRTL community for a few years now, and over this time we’ve watched you grow from a normal user to the developer of our default GUI wallet, and now a core dev, in fact! At the end of this interview, I hope the readers get to know you and your projects as well as the rest of us have, and maybe if we’re lucky it will bring people a little bit closer to one of the people that makes the tools they use daily.

So to take it from the top, how did you find TRTL? Do you remember what brought you here initially?

EH: I found TRTL very early on, within the first month of launch, through a thread someone had posted (where else) on /biz/. It was my first foray into getting involved into a fledgling coin, and let’s just say I didn’t really know what I was getting into. In fact, at the time, I had very little background knowledge of blockchain in general. It was a great experience, and before long I was up to speed on alot of basic blockhain concepts due to the helpful and educational nature of the community.

RS: How long would you say you were a regular user before you got the idea you wanted to be a dev? What was it that made that change?

EH: I didn’t decide to take steps toward becoming a developer until I had already been in the community as a regular user for a bit over a year, sometime in February 2019. I’d say there were two major events that spurred my transformation:

The first event was a video that you actually posted in #general, a movie on open source software and Linux called Revolution OS. It really struck a chord with me. Watching that video made me realize what open source actually was: it’s more than just opening your source code for others to inspect, it’s a revolution and community movement based around allowing others to use and modify software and change it as they see fit. This understanding was eye opening for me, and gave me a bit of a different perspective on TurtleCoin and our community.

The second event was the event that actually spurred me to start writing code. Madk had a bot in the market server that was able to give statistics on the network and market: price, hashrate, and so on. He made some changes to the bot that I did not like. So, instead of asking madk to revert the changes, I set out to write my own bot to take its place. That bot became my first ever coding project, and is still running in the market server to this day.

RS: That’s cool, and I’m not sure many people knew that about you. What brought you from doing a chat bot to wanting to design the now default GUI wallet for TRTL?

EH: The chatbot was written in JavaScript, which I had some (but not much) experience with before, mostly simple scripts on web pages and things like that. I set out to learn as much about JavaScript as I could, thinking it would be best for me to at least become competent with one language before attempting to learn others. There were a few other projects in between which I used to further hone my JS skills, but soon I began to want to contribute back to the TurtleCoin community in a meaningful way.

At this point, I was also following TurtleCoin’s development very closely, and one thing really piqued my interest: walletbackend-js. Zpalm had written a really nicely done native JavaScript wallet backend implementation, but no-one was yet developing a new wallet with it. Also, the current GUI wallet was fairly clunky and seemed to be abandoned by the developer. I saw a good opportunity to actually start a project that could improve the end user’s experience with using the network, and from that came Proton, my baby and GUI wallet which i’ve crafted for the community.

RS: What does walletbackend-js do for you, or I guess, for Proton?

EH: Walletbackend-js provides a way to interface with a wallet and the network in native JavaScript, which allows you to do things like write a wallet application or turtle-powered web application. It can run in a lot of places, including directly in a browser. With the old electron-based GUI wallet, there was always some “lag” to the user experience because it was just a graphical front-end wrapping the turtle-service executable. Proton, however, is a 100% native JS application, with no messy child processes.

RS: Is there a vision behind what you’re trying to create? Has becoming the default GUI wallet changed how you feel about the trajectory of Proton?

EH: Well, to be honest, the intention was always to become the default GUI wallet. Eventually I’d like to add multi-coin support for some of the other bigger coins, I think it’d be neat to have a fully open source client-side multi-coin wallet. However, for now, I’m just focused on improving Proton and making it the best possible experience for users on the TurtleCoin network. If anyone would like to see specific features implemented, please feel free to make an issue on the GitHub page with the feature request.

Shows you node fee info too, which is handy

RS: What are some features you’re working on currently that we will be seeing soon that maybe some aspiring developers reading this can help with? Do you have any Good First Issues?

EH: I’m currently working on a search function to search any information locally in the wallet. It’ll match contacts in the new address-book that will be releasing next version, as well as hashes stored within the wallet such as tx hashes and payment IDs.

The issue list is looking rather slim at the moment, but I am having one issue with a module called react-select I’m using on the send page for the address input: you can’t access the context menu to paste via mouse click because the real input width seems to automatically resize based on input size. This would probably be a good one to try and tackle.

RS: For anybody who’s reading this who may want to help, can you touch briefly on the different parts of the tech stack that Proton makes use of? It uses nodejs, what else?

EH: Sure. At its root, yes, it’s a nodejs application. It’s also making use of electron, a framework for developing with web-based technologies on the desktop, and react, a front-end framework for web applications. It’s also making use of redux, react router, and webpack on the web-application side. We’re using bulma for the CSS. Of course as we’ve already mentioned, the TurtleCoin network interaction is powered by wallet-backend-js. I’m also using several tools to make up the development environment like eslint and prettier for code linting and formatting, and react-hot-loader for hot refresh in dev mode.

RS: With a list of technologies like that you’re bound to snag someone’s attention! Extra, thanks for this interview. Is there something we didn’t cover that you want to share with everyone?

EH: Thanks for having me! I’d just like to say thanks again to the TurtleCoin community and especially the developers that have helped me along my path to becoming a dev; particularly zpalm, ibmcd, mary, rock, fexra, and anybody else that’s helped me out along the way. Because of you all I’ve discovered something new that I’m really passionate about and I see myself doing for the rest of my life. I also look forward to getting more actively involved in core development and leaving my own mark on the core TurtleCoin codebase.

Check out ExtraHash’s handywork in the latest release of Proton GUI Wallet at

If you’re a beginner developer or want to learn more and help out, check here for some good first issues to get started with

Weekly Update

This Week In TurtleCoin® (September 24, 2019)

Developer Updates

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

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


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

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

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

I wrote a guide on how to use it here:

>tfw z writes a guide

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

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

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

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

– Zpalm


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

Can it really be that simple?

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

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

– IBurnMyCD

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

TurtleCoin® Core Update

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

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

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

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

– Core Development Team

TurtleCoin® Website –

yo dawg heard you like menus –

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

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

– Fexra

TurtlePay® Blockchain Cache

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

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

– IBurnMyCd

TurtleCoin® Web Wallet

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


These… you can actually help us with

Good First Issues

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

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

Pay With TRTL

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

All items in our shop:

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

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

Interview w/ SoreGums from TRTL Core Team

A while back we used to do an interview series called Out Of The Shell. This was a series of interviews done by an actual journalist, Gigantomachia, who would pull aside members of the community for an article, and when it was over the person being interviewed would pick another member to be next. The series was great, but sometimes life gets in the way, and this interview with SoreGums sat on the shelf for a few months.

I never want good content to go to waste, and I’m sure you guys would love to read it, so here’s the interview with a member of our core team, SoreGums.

This will be the last “Out of the Shell”, but it is far from the last interview, enjoy!

How’d you first learn about TurtleCoin?

I first learned about it via the Kevin Rose podcast BlockZero: #003 – TurtleCoin – The next Dogecoin?.

What was it about the coin that drew you in. Why are you involved in TurtleCoin as opposed to the other coins out there?

I listened to that episode during the 1st week of Feb 2018, then joined Discord. For the first 48hrs checked out everything and sat in #help and assisted others finding their way. Poked around the dev channels and ended up with contributor access to the Meta repo to help with issues there and got a dev-role tag as well. This level/kind of openness in projects is uncommon. I was also involved in discussions and liked the atmosphere and am now here for good. Other projects in this field pretty much have an agenda, and the dev teams don’t encourage outside involvement. I don’t like writing code; I can, I’m not great at it (as measured by speed and regurgitating things from memory – like on a whiteboard). My skill set is figuring things out (know how to find what is needed, be it tools, utilities, platforms, etc. and then put them together) and providing a way forward. I also like writing documentation. I very much enjoy supporting teams rather than being the star or leader.

Also, TurtleCoin is very much a currency application which runs on the TRTL Network. This distinction is relatively new (June 2018), however, has been in the roadmap from the start, see the Karai milestone. The appeal here then for me is getting in amongst it at a level that requires a fundamental understanding of how this all works. Primarily a learning opportunity, I am a believer in continued learning/development is essential for avoiding depression and being “happy” (to put it in simple terms).

How long have you been interested in crypto?

First got into it April 2011, bought 3x AMD GPUs to start mining Bitcoin. It seemed like it would be a thing. Would have been great if I believed that with conviction, haha.

So you gave up early?

About HODL. Always been following. Been moving around a lot, electricity vs reward at the time etc. I’m a member of the “if only” club of 2017 (BTC price surge etc.). I traded in 40BTC for an Amazon gift card to buy eBooks etc. Still worth it, however, in hindsight, 40*20k is a large number, that would have been nice. Now, 7yrs later it’s visible traditional central banking will be impacted. Blockchain genie is free, an energy-efficient application of it will need to be figured out long-term though.

Have you been involved in any other crypto project before TurtleCoin?

Not like with TurtleCoin. On BitcoinTalk, I was pretty vocal in the Coino Coin project, which died due to the core dev team being two people and real life got in the way. It was also a fast block project, ran into problems with that and the size of the blockchain database. It is funny, Dash, Digibyte, Coino all started around the same time. The core idea of fast blocks and what that enables is why I am so interested in TurtleCoin.

I’m as involved in TurtleCoin as I am because of how the project works and the people attracted to this way of working. I’ve been able to engage in discussions and contribute some value, that is accepted. Then the reason this is a thing is that the project has a focus on the platform as a tool, rather than a way to get rich quick (funny how incentives dictate actions/behaviour). Which leads to the people, we seem to be evenly distributed across the globe teaming up as it were on common end-goal objectives. Everyone I’m actively involved with comes at the work via the collaborative, open, straightforward, humble, mindset.

You’ve mentioned being interested in fast block times a few times. What about fast block times interests you and what do they enable?

Everyday transactions, the only way any cryptocurrency is going to become “the way everyday transactions are conducted” is if they are instant or close enough. In Australia/New Zealand they have self-service checkouts at the supermarket, NZ has self-service petrol pumps, a financial transaction needs occur to complete the sale as it were. So fast block times matter, no one is going to adopt a new way that requires them to stand around for more than 5secs before they can go. Thus immediate responses from the network are essential (fundamentally there doesn’t need to be fast block times, however as a building block it is a logical place to work from/at). Bitcoin is getting instant transactions via technology like lighting network, which briefly means people between the purchaser and seller guarantee amounts are moving from purchaser to seller instead of the network directly (over-simplified, general idea).

So practically how all this works is like this. A transaction broadcast to the network is the equivalent of authorisation in the current visa/card networks. This authorisation is saying “these funds have been allocated FROM this account TO this other account”, allocated means on the way to the destination, (privacy coins, of which TurtleCoin is one, only the sender and receiver know the FROM and TO parties) and is instant. In the visa/card networks at this point the sale is, and everyone moves on, the purchaser has their items, and the seller is confident they’ll receive the funds/the transaction will settle (funds show up in the clear in their account, arrived at destination), eventually as guaranteed by legal contracts etc. In the blockchain world, this is a little bit tricky as there is no guarantee by anyone that these broadcasted transactions will ever be settled/confirmed.

Settlement in blockchain tech comes in the form of included transactions in blocks, fast block times mean these blocks, and thus transactions being confirmed happens fast. Each time a block is produced from when the transaction was first included in the blockchain is an additional confirmation that the funds moved from one account to another. For TurtleCoin the target time for block production is 30 seconds. This means within 20 minutes a seller can be confident they will have the funds (technically they have the funds within 30 seconds). Contrast this to the Visa/card networks the seller needs to be cautious because the funds could be taken back up 90 days or even more depending on the card network and agreements etc., for various reasons. It is challenging in the blockchain world for a purchaser to take back the amounts they have sent as the confirmations continue to accumulate, there is no authority to turn to mediate on their behalf.

That is a super long answer however it is not often explained in detail for everyday people to make the connection between block times and how Visa/card networks operate. TRTL Network has attracted a lot of regular people due to how the community and project members interact with each other, so perhaps someone will find the above details useful.

Having code that enables fast block times isn’t the only factor that would lead to actual real-world adoption of TurtleCoin. What do you think needs to happen beyond the code for this to take off?

Utility. It is the answer to all blockchain adoption. TurtleCoin has it as a premise, however, in practice, it is still in the infancy stages. Once the TRTL Network Spec is defined, it’ll allow anyone to write any code that speaks to all nodes in the network. Said another way, the current TurtleCoind daemon can be replaced by some system that works perfectly for the people writing the code, and they will be able to interact with the TRTL Network just fine.

As for specific things that could promote real-world adoption, supplement all transactions that happen via cash with TurtleCoin transactions. It is going to take business relationships of the community to make that happen. One thing that will help any of those conversations is the access to reliable APIs, so the barrier to entry is as low as possible. I am talking about web wallets or platforms that act like web wallets. Just so happens that one such platform is under development by Fexra (GitHub/Discord). Fexra is building out a web wallet platform that enables merchants to integrate with the TRTL Network without having run, own and operate independent infrastructure and at least in the beginning, and this is needed. As the TRTL Network project progresses and standard tools are developed and released under the “Turtle Pay” heading, being able to find TurtleCoin and then be offering it the next day as a way to exchange value, this is what encourages adoption: ease of use; security; etc.

What do you do IRL? Career? Student?

I’ve been in IT since leaving high school in 2002. My predominant occupation is taking care of my son; he’s 1yr old. So am blazing my path doing different things here and there, IT related.

What are you doing in Vietnam?

I’m supporting a tourism company to attract foreigners, via native English website. They are a successful Vietnamese domestic tourism company.

What’s your favorite pizza?

Italian, from Italy; a bit of sauce, some fresh cheese, something green. Loved visiting there a few years ago, missed it immediately when we crossed the border to France. French delis are amazing, eating out of a deli all the time while possible, would not be ideal.

Any particular projects or initiatives you’re working on right now where you’re seeking community input?

I’m an analyst and details focused type of person that can also zoom out to verify the big picture as well. As such infrastructure and breaking down how things work has me focused on developing the project Krang. It is a Blockchain Automation Testing Suite, which means standing up infrastructure automatically and running tests on it, measuring results and creating reports. Said in plain language, turning on multiple computers, installing all the needed software for the blockchain network to function and checking how things run and writing about/reporting on it.

Krang will work for TRTL Network first, then move onto other blockchain projects. There are a bunch of goals that get covered by the above being real. It means we can automatically test releases before pushing them out. We can check for regressions in performance or even benchmark to figure out where we could make performance improvements. It enables us to test the theoretical parts with ease. It allows us to test different network attack scenarios with ease and assist in developing mitigations.

It is considered a massive project regarding what it enables. There will be a fair amount of code created to package all the standard tools and even more documentation written to allow others to use Krang or further extend it. The actual work to be done though is standard practice in organisations that prefer measured/ correct results, rather than guesses.

So if the above appeals to you, ping me on Discord. One other fellow in Australia is also involved and enjoys working on the infrastructure puzzle.

Now that TurtleCoin has been listed with CoinMarketCap what do you think that increased exposure might mean for TRTL.

I think it mostly signals a validation of the work being done. The group of contributors to the project is expanding each week. For them to be seeing that the project is getting positive attention will help with the positive feedback loop. For the users of the network and future users, it is also a positive signal.

There is a dark side to CoinMarketCap in that their timing on information updates has been shown to be self-serving and would encourage people to seek alternative data points instead of relying solely on CMC. One such site is, since TurtleCoin’s inception, the project has climbed up the developer ranking there and now (2018-09) TRTL is ranked 26. Slow and steady is the TurtleCoin motto, we’re here for the long term. The openness of TurtleCoin in terms of accepting contributions is great and wide, the project might be viewed at first glance as being a bit of a lark with its meme coin start, however, it is serious about the technology and the utility it is seeking to enable.

One of the projects primary objectives is to educate anyone interested in blockchain technology, either as a user or as a developer. As such the more exposure we get the more people we’ll be able to impact and give people a real handle on what this technology is all about so they can feel empowered and be an active participant in this new world. Like how the internet has connected everybody on the planet, it was the realm of the nerds when it started, blockchain technology needs to have some of the nerd transformed and made accessible for everyone.

Also…When you’re not working or hanging out in the TurtleCoin discord, what do you like to do for fun?

Go to the movies, went to see Deadpool 2 the other week. The first one was best, the second was good fun and entertaining as well, it is based on a comic series though, and well, it’s a bit hard to “out original” the original.

Travelling, reading, learning, visiting family, going out for the day, playing chess with my wife are some other things.

Feature Story

The Quest for Lightning Block Propagation

Here we see a Turtle having a bright idea.

TurtleCoin has 30 second block time which makes transactions on the network faster than other projects; however, it poses some challenges in making sure that new blocks propagate across the entire network as quickly as possible to prevent the creation of unnecessary network forks. While increasing the number of nodes on the network helps to achieve this goal, reducing the size of the blocks that are transmitted between nodes allows us to propagate a block so fast it’s almost as if they were transmitted by lightning.

Network Propagation

Block Propagation at its finest

Understanding what information is propagated throughout the network is a requirement for making sense of what we’re trying to accomplish when we talk about speeding up propagation.

Each node that is connected to the network performs vital functions such as, but not limited to:

  • Verifies transactions (signatures, no double spending, structures, etc.)
  • Verifies blocks (makes sure that they meet the difficulty requirements, are valid in the chain, contain valid transactions, etc.)
  • Maintains a transaction pool (transactions that have been submitted to the network but not included in a block)
  • Relays transactions & blocks to peer nodes (those the node is connected to)

Each time that a new transaction, in its entirety, is submitted to a node for processing by a user, that transaction is added to the node’s transaction pool and then relayed to all its connected peers who relay it to their peers until everyone on the network has those transactions.

Mining a Block

We know you crave finding those blocks

Once a transaction is in the transaction pool, it’s hash is then included in the block template that is passed to miners via pools or directly from the node if solo mining.

When a miner (or pool) finds a block the block, with all its glory, it is submitted to the node, it is validated, added to the chain, and then the full block containing every transaction including its inputs, outputs, signatures, etc. is relayed to all the node’s peers. Those peers relay it to their peers after verifying it and adding it to their copy of the blockchain, and so on until everyone has the new block.

Block Propagation Payloads

The full blocks that are sent between nodes have the sizes as reported on the block explorers. Some blocks are small at only a few hundred bytes while others with many transactions or transactions with lots of inputs/outputs can climb to well over 100KB. 100KB does not seem like a lot of data, but when you need 100KB to propagate between >1,000 nodes, it takes considerable time. We need the elapsed time from block creation to full network propagation to be as little as possible to make sure that the nodes that are mined against always have the latest information about the chain.

But… Why?

You may be asking yourself, “If transactions are propagated around the network for the transaction pool and a node already has them, why are we sending them again, in their entirety, with every block that is propagated?”

Things don’t have to make sense to work, right?

To put it bluntly, we don’t need to send everything all the time if a node already has most of the information needed to verify a new block. Sending all of it again is just duplicating things it already has.

Lite Blocks to the Rescue

Block Propagation is like a game of cooperative Tetris

Enter the concept of Lite Blocks. Lite Blocks are a special kind of block created just for synchronization between nodes. A Lite Block is just like a full block except it only contains the transaction hashes not the full contents of the transactions (inputs, outputs, signatures, etc.).

When a node receives a Lite Block, it looks through the list of transaction hashes the block contains, checks its local transaction pool, and plucks the needed transactions from the pool. If it encounters a transaction that is not in its transaction pool (for any reason), it reaches out to its peers and requests just that transaction. Once the node has all the transactions the block contains, the block is verified, and added to the node’s local copy of the blockchain.

The node then starts the relaying process to propagate the new block to its peers. In going through the list of connected peers, it identifies which of its peers support Lite Blocks and which do not support Lite Blocks. It relays the appropriate block type (Full or Lite) to its peers as needed.

If you’re keen for additional reading on the underlying concept of Lite Blocks check out BTC’s BIP-0152 as well as Monero’s Fluffy Blocks.

TurtleCoin’s Implementation

Adding Lite Block functionality results in significantly smaller blocks propagating across the network. In testing, we’ve observed Lite Blocks as little as 1% of the full block size. Transferring 1KB versus 100KB is a momentous reduction in the amount of data transferred between nodes. This reduction helps to improve block propagation times in a massive way. TurtleCoin nodes will now prefer to send Lite Blocks whenever possible to reduce the size of the information exchanged between nodes. The node will fall back to Full Blocks only when necessary.

@rashedmyt has completed the work required to add Lite Blocks into the core TurtleCoin code. He’s built it in such a way that it does not require a fork of any kind as it relies on the P2P version that we use in a couple of different places. Our plans are to activate Lite Block capability with an upgrade to P2P Version 4. This P2P update will make it into the next release of the core TurtleCoin software.

The addition of Lite Blocks was listed as a TurtleCoin bounty and @rashedmyt will be picking up a 2.05M TRTL bounty for the efforts he’s put forth in getting Lite Blocks implemented in the core code. When you see him in Discord give him a high-five and a round of applause.

Weekly Update

This Week in TurtleCoin (Nov 12, 2018)

This week was one of the best yet! Between playing the games you guys made with your TurtleCities pages, and ones you wanted to watch on TwitchTurtle, I’m spent! Awesome community participation this week, and we’re really looking forward to next week!