Weekly Update

This Week In TurtleCoin (April 22, 2020)

Pictured above: a Monster Energy Drink molecule

This week we wrote code with our eyes closed and everything still compiled. Lightsabers are in the mail!

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.


This week I upgraded turtlecoin-wallet-backend to use the 2.0.0 rewrite of turtlecoin-utils. Along with providing a much improved TypeScript interface, this will prep turtlecoin-wallet-backend to be ready for any interaction with Karai, as turtlecoin-utils will provide an easy interface to parse out a Karai pointer from any transaction once we have finalized how we want to store it.

In the process, I also found and fixed a small bug where disabling auto optimization would not work correctly.


Karai Is Solving The Scalability Problem

For those of you that know the name but don’t quite know what it is, I’ll give you a quick pitch on what the Karai project is, and how it relates to TRTL:

Background: Karai started out as one of the early milestones we had with a goal of providing a sidechain to store Ethereum-like smart contracts for the TRTL Network. At the time the approach we were planning to take was all wrong, we were going to launch a single sidechain, with its own currency, using the same linear blockchain software as TRTL with the same inherent drawbacks compounded by the need for extra storage. The headaches were already stacking up and that was not even considering the work that would need to be done to allow people to program their own applications on this thing or be anywhere near up to par with Ethereum, which was a lofty goal at the time.

Fast forward: About 2 months ago, as our core software started reaching a point of relative stability we had a moment to step back and look at other initiatives to do some of the much-needed conceptual work we used to do with our free time. As luck would have it, conversations naturally resumed about a new way of implementing Karai that would address some of the concerns we had about our initial approach. Let’s summarize what some of those issues are:

  • A side chain only prolongs the bloat problem – If spam attacks have taught us anything it’s that if there’s a globally shared asset within easy reach of the masses, someone’s going to put a goatse on it. If you have to sync through the entirety of historic data on-chain from the birth of that particular blockchain just to sync to some data from last month, that’s a problem that gets worse every block whether there is a transaction in them for you or not. Any network with sufficiently fast blocks (like TRTL) and a singular linear chain of blocks will face a problem with scanning and storage eventually.
  • Yet Another Token Syndrome – Karai originally was intended to have its own native coin that was pegged to the value of TRTL to act as ‘gas’ for computation on the Karai sidechain network. The balance between the two plus the third element of relying on merge mined hashrate was a precarious balance and any ability to destabilizing any single element of that would spell disaster. Any sidechain with its own native currency will experience this issue. There is also the issue of token-fatigue which anybody not new to the scene can elaborate on.
  • Linear Blockchains are slow – Trying to use a linear blockchain for high transaction volume is a nightmare, because the shortest route between A and Z will always be touching every letter between along the way, A, B, C, D, E… Because of this, Bitcoin does less than 4 transactions a second, Ethereum does less than 20 transactions a second, and for comparison, the VISA network claims to do less than 2000 transactions per second..

While we are spelling out a list of our gripes trying to implement smart contracts on a sidechain using conventional means, we might as well address how the new plan solves them.
Diagram of Karai’s transaction graph
  • The Sidechain Problem – Karai transaction channels are numerous and not required to be part of a single sidechain. Another technology using this concept might be familiar to you is Lightning Network technology. In the case of Karai, a new user can connect to 1 channel or many channels, and only has to interact with the history of the swarm they’re connected to. Private and unknown Karai networks are possible by default, the main chain doesn’t have to know.
  • The TurtleCoin vs A 2nd Coin Problem – Maintaining a secondary asset would fracture the community’s trust and development capacity while also dividing the loyalty and demand between two assets. It’s also a rule of thumb that anything you assign monetary value to will be subject to manipulation and attack with a financial motive. The world does not need yet another token.
  • Linear Blockchains are slow – Karai is a directed acyclic graph, where there is no single line of blocks to traverse on the path from A to Z. Another network using a directed acyclic graph (or DAG) is IOTA which some of you may know as being particularly fast and unique in the structure in which it arranges blocks. First we should cover that Karai doesn’t have blocks holding the transactions because transactions are independent objects, and it also doesnt have a block interval where empty dust is being produced and recorded for no reason while waiting for transactions.
    A person connecting for the first time wouldn’t need to pass from A to Z in the transaction history by going through every node A, B, C, D, and so on but instead take only a few hops to scan to the tips of the graph.

With this in mind, last week when I started prototyping some of the code written for the transactional side of Karai, I made a boastful assumption that we could hit a target of 10,000 transactions per second.

I’ll admit that before I was able to write a benchmark or even write a transaction creation method for that many transactions I was already a bit skeptical if I’d just put my foot in my mouth.

Initially when I wrote the benchmark, it was fairly unoptimized, and the way I was creating the transactions and timing the execution of them was a little computationally wasteful, so my first benchmark indicated I was doing 10,000 transactions in a little over 2 seconds. It was disappointing but also inspiring to have a goal to aspire to. It didn’t take long, but with the suggestions of IBMCD and Z, we were able to make some significant improvements in a single night.

We’ll just come out and say it. We hit 1 million (1,000,000) transactions created, processed and recorded to HDD in under 1 second. This was with a single threaded benchmark using a Ryzen 1800.

As a disclaimer, It’s important to note that in this benchmark we’re not sending any of these transactions over the network, they’re all transactions being created from and processed on the channel coordinator and saved to spinning disk. It’s likely that when we introduce network latency we will incur some slowdown to this number. That being said, these are impressive numbers. Let’s talk about how we derive those numbers.

The process, For each of the million transactions, constructed an object consisting of the transaction type, the current hash, the ancestor’s hash, and a JSON object containing the transaction’s own graph position in it. This is a fairly small transaction, but not empty.
Each transaction generates a separate JSON file on disk containing the Tx data we just covered. The hard drive it was stored on was the same hard drive it was run from, a Western Digital Red 8TB drive. All of this Tx data is then hashed with SHA256 and the process repeats for the next 999,999 transactions.

Interesting details, In the process of doing the first benchmark of 10,000 transactions, we noticed that while using the terminal screencapping tool “Asciinema” we were running into the framebuffer becoming our bottleneck with the transaction finishing in 5% of the time it took to render the output to the screen. This was one detail that initially skewed the benchmark readings significantly. Another interesting tidbit we learned is that if you suddenly generate 1 million files into the same folder, two things happen: Git will display a notice that your project can no longer be tracked because it has exceeded the number of files it can watch, and you’ll no longer be able to rm Tx*.json the files you just created because the list of files to be fed into the rm command will be too big.
Other things that crashed were my file manager, the game I paused for the benchmark, the YouTube video I was watching, and Winamp.

I think Winamp just wanted to crash for old time’s sake and should be treated as unrelated.
Extras pointer collection service

Also, we figured out how the pointers work from TRTL Network to a Karai transaction channel, and stored a few of them on the TRTL blockchain already, you can check them out on the official Karai Explorer which Extrahash has been making to scan and track all of the Karai channel pointers he can find in the TRTL blockchain and catalog them with some basic data. It’s really cool, you should check it out.

I’m making progress on cleaning up the code base to get it ready to share on Git, it’s written in Go if anybody is looking for something new to learn and want to help out. My current goal is putting the DAG tip selection algorithm into code prototype stage, which shouldn’t be that bad given the speed of current development.

See you next week!

Join us in #Dev_Karai in the Discord if you have any questions.

RockSteady (TRTL)

Moving Up!

It’s always good to be recognized! These are the people who gained new roles in the community this week!

Karai Dev Role – Extrahash, RockSteady, Zpalm, Ibmcd

Shoutouts & Thanks

This is the place to mention someone in the community who has done something nice or deserves recognition.

  • Madk Shoutouts to – the unofficial Minecraft server of turtlecoin.
  • greywolf thanks much to zerouan and brätövenhürt for the lively DJ talk show while hosting karaoke
  • zerouan thanks yall for supporting vision street wear, lilly meraviglia and not eat any pineapple pizzas
  • rock thanks to everyone helping me out with karai, the website, and any of the other irons in the fire we got goin right now

All Feature Story

SoreGums on Distributed Compute [Karai]

Image result for beowulf cluster

I think I need to listen the to the Kevin Rose TRTL podcast again – the only reason I really ended up in TurtleCoin in the first place is that of the core concept of a “network” with “applications” and “TRTL is just the currency one”. There was a bunch of other details that I liked as well technically, hence probably warrants a relisten.

Cause if we want “other” applications it seems like it mostly comes down to messaging. As in information needs to get around to the apps on everyone’s devices. Right now we have the daemon which then feeds wallets. The wallets keep balances by reading the messages in the blockchain. Blockchain works cause of PoW. Nice.

How do we get other applications then?

The current thinking is a smart contract platform, aka Karai, something like Ethereum – however, we’ve identified issues with it that we don’t want to adopt. So breaking down things to first principles any app we can think of is doable the traditional way (racks and go – racks is the catch-all phrase for anything that combines compute/storage), depending on what it is that can be expensive to maintain or difficult to launch in the amount of time needed to set up various parts.  Racks are also susceptible to adversaries be they Governments or script kiddies. Thus the natural jump is to a peer-2-peer model, aka de-centralisation. Once Filecoin becomes a real thing storage via IPFS is handled, what isn’t handled is the compute side of things. Ethereum does it by being the compute, the daemon has a virtual machine that accepts scripts which when invoked produces results that are then committed to the blockchain and chicken dinners for all! As we can see they are having scaling issues and personally I don’t believe that is the best way to go about this in the first place. The thing is whatever is in the blockchain is never actually used as is, apps written to run client-side are also needed to interact with any of this data.


How about we simply augment the TurtleCoin blockchain to support the various kinds of messages needed to power these client-side devices? Maybe it needs Karai to help with that, not sure. Thinking about this it is difficult to define Karai as a smart contract platform like Ethereum as the only way you get Ethereum is if you do Ethereum and all that isn’t what I believe is actually needed to get to “TurtleCoin Network” powers distributed applications.


Gods Unchained

Having non-fungible-tokens is something that should exist. This trading card game is a practical example of how being able to say I own a thing and it is a unique thing, like printing out a piece of paper and it being unique, is useful. Keep in mind that representing physical items in the digital realm is different, yes someone could chop up a block of land into 1,000 pieces and say that whoever has those 1,000 digital tokens owns the land, but really the person whose name is on the land title at the local land titles registry is the landowner… Then the game actually takes place off-chain and requires a client. The rules are published and the smart contracts are in place and the tokens exist – with all of these components in place ANYONE can create a client to play this game or any other kind of application where those tokens fit. No one can actually take the tokens away from anyone cause blockchain. The tokens don’t rely on the game devs being around in the future, the tokens now exist, their value and significance is open source and committed to digital permanence as long as Ethereum exists, even then if Ethereum dies they can still be sucked up into a new thing as all of Ethereum up to the stop point exits…


This is a platform to handle identity verification without usernames/passwords by using PKI. In practice it works like this, the bank calls you and says “so give me all your personal details and I can verify I’m speaking with the correct person” and you’re like “dafuq? you’re not my bank, scammer!” and hang up.

Instead, the bank calls you and sends a signal on their side of the app conversation with some info they told you on the phone, you open your app and confirm you are you and the bank also sees the confirmation, you know you are talking to the bank and the bank knows they are talking to their customer, no more “so ahh give me all your details so I can steal your identity”.  It works by sending messages and apps responding to those messages as needed. This is like our currency application. The difference here is 95% of the messages don’t need to be recorded as they are only useful for the moment they are read. Committing all these messages to a blockchain is really only useful for auditing purposes in the future to see what happened previously. Really dedicated apps can take care of that if needed. These messages are small however if the application was adopted by millions the message volume would explode the storage requirements of the network (~25KB/msg, 10k msg, 91GB/yr for ONE app…) and make it unsustainable. Thus it seems like some kind of ephemeral messaging ability is needed. See discussion in #dev_general for more on ephemeral messages.


These are my thoughts on what TurtleCoin network needs to help us address, non-fungible-tokens / ephemeral messages. Maybe Karai is our non-fungible-token platform and ephemeral messages go into TurtleCoind. Outright compute in a distributed VM, I don’t know about that maybe? an example would be great!

Your Thoughts?

join me and others in the #dev_karai chat on Discord: Jumping off point for when this conversation might have started, link

Feature Story

Interview w/ Turtley McTurtleton McDrizzle from

forkmaps logo

RockSteady (TRTL)

@Turtley McTurtleton McDrizzle Thanks for doing the interview. I wanted to talk today about ForkMaps, and what forking means to the community, and why it’s worth tracking.

Turtley McTurtleton McDrizzle

The story goes something like this… A couple of months ago, RockSteady said he wished someone would make an updated version of the fork timeline on the CryptoNote Wikipedia page. Turtley McTurtleton looked around a bit, didn’t find anything that was being maintained, and had only one response… “Hold my beer.” “I’m on it.” The timing was just right. I was evaluating frontend JS frameworks for an upcoming work project, and rather than writing some contrived “hello world” sample, I used forkmaps as an opportunity to test a handful of frameworks in a real-life scenario.

RockSteady (TRTL)

That’s really cool. While making forkmaps is there anything that surprised you about all these forks?

Turtley McTurtleton McDrizzle

I found the general friendliness by the CryptoNote community a little surprising. I’ve ventured into many discord servers either looking for project details, or advising someone to restore license headers, and I almost always receive a warm greeting.

RockSteady (TRTL)

Tell us a bit about the tech behind the project and how it all works. I noticed the front end got noticeably faster to load recently. Can you talk about that a bit for some of our nerdier readers?

Turtley McTurtleton McDrizzle

I used Vue.js for the frontend. I wrote it using Vue first, then rewrote it using React, and then messed around with a handful of other frameworks/libraries. I’ve used AngularJS and React quite a bit in the past, and to me, Vue is the perfect marriage of the two.

The site has very few dependencies. I used three Vue packages (base, vue-router, vuex), axios for HTTP requests, and echarts. I didn’t use a CSS framework, so design took me forever, but taught me a lot.

Turtley McTurtleton McDrizzle

To tackle performance, I cleaned up a lot of my JS, replacing a lot of nested functions with array reducers. I added a few CSS transitions to smooth out navigation, added loading indicators (which you should almost never see), and threw in some other UX tricks. Other than the fork map page, my improvements were mostly about perceived performance. You can make something that’s actually very fast, feel slow through clunky UX, and that’s what I’d done with my first attempt.

On the map page, I switched from vis.js to echarts, which is much more UX-friendly.

That was a lot, and I promise I’m almost done.

On the data side, all of the CryptoNote coins live in a separate git repo, as individual coin files to make them easy to manage. Whenever there’s an update, I run a gulp task to combine them into a single json file, which pulls directly from GitHub. This way, it’s trivial to add additional coin families in the future.

RockSteady (TRTL)

That’s really cool, what do you plan to add to it next and what kind of helpers are you currently looking for?

Turtley McTurtleton McDrizzle

Next I’m working on a timeline representation similar to the example you initially showed me. Someone’s working on the 200k TRTL bounty for adding start/end dates to all of the coins as we speak. After that, I want to do max supply, emission curves, primary emission length, and possibly current supply. That one’s been requested a lot, and I think it’ll make an interesting chart. Most coins seem to have a primary emission measured in decades, while Nerva is only three years. I’m always happy to send TRTLs to anyone who contributes data or ideas.


RockSteady (TRTL)

That’s great that you’re including the community in this project, and even chipping in bounties for people who are helping out. With so much exposure to all of these different forks, surely you’ve come by some really interesting ones. If you don’t mind, let’s run through a few of the more memorable ones to you: Which fork has the best logo in your opinion – What is the most interesting fork – Which forks do you mine – What’s the worst fork name you’ve encountered – If you made a fantasy fork tomorrow, what would it be called and what would it do?

Turtley McTurtleton McDrizzle

I like logos that don’t look like a coin. Some of my favorites are Boolberry, Alloy, Athena, Lethean, Nerva, TurtleCoin, and Karai (not on my site yet, but the logo is solid). Right now, I think the most interesting fork is Nerva. I’m looking forward to seeing what happens when the supply is exhausted in like 2.5 years, and CPU-only mining is the shit. I only mine Nerva and TurtleCoin. I rent some of my miners on miningrigrentals, and I used that income to buy more TRTL. Worst fork name? How about all of those dumbass XMR forks that happened when Monero switched their PoW algorithm? Actually, Sadomi might be the worst. I really don’t think they thought that one through. A fantasy coin for me would be a TRTL fork so I’d always have a reliable codebase and community, and I’d implement a prime sieve PoW component similar to riecoin. I’d call it Turtimus Prime.

RockSteady (TRTL)

Haha that sounds fun. Whats up with Prime Sieve? tell me about that

Turtley McTurtleton McDrizzle

So basically, you have an algorithm for finding prime numbers, or prime number patterns. Many projects have chosen to do something “useful” as PoW, at the expense of cryptographic security. But why not both? Add a secondary PoW step that’s relatively easy to perform, does something interesting, and throws another wrench at potential ASICs.

RockSteady (TRTL)

That’s cool, I think we’ve about got it all covered, is there anything you want to add?

Turtley McTurtleton McDrizzle

I’m glad you asked! Years and years ago, before cryptocurrency was a thing, I had a closet full of crunchers (mining rigs nowadays) working hard on distributed computing projects like folding@home (Team 32!) and BOINC/SETI. Back then, there was no financial incentive to spend lots of money on hardware and electricity, but we did it anyway. Some did it for a cause, some for leaderboard points, but I think most did it for the knowledge and the community. I treat crypto projects the same way. At this point in my life, my time is far more valuable than any amount of hardware or hashrate, and there’s a big reason I spend so much of that time with my fellow turtles. And TurtleCoin is the only project I’ve found that really embodies that sense of teamwork and community that the distributed computing scene seems to have lost to crypto over the years. So to all my turtle-fam, keep up the good work, and stay turtley!

RockSteady (TRTL)

Jerme, I’m glad you did this interview, and I’m happy you’re a part of this community! Thanks for everything you do with ForkMaps and otherwise, and I look forward to what you come up with next!