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 (July 2, 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

Chukwa’s Labyrinth

Chukwa’s Labyrinth

I started making a new TurtleCoin-themed game, “Chukwa’s Labyrinth”! You’ll have to go through a series of mazes in order to reach the prize at the end! So far I’ve gotten player movement, a turtlecoin powerup and basic levels designed. I’m currently working on refining my tilesets and how I approach tilemaps. I’m using Godot Engine – a free, cross-platform, open source engine. It’s extremely powerful, 2D and 3D, and is licensed under the MIT license(!). No royalties, no strings attached.

My game will be released under the GPLv3 license, you can check out the code at the GitHub repo. Big shoutout to @oiboo for making all my art for me, you rock. Also for his amazing artpacks! And also thanks to @GT3000, for helping me get started and giving a great starter resource


Proton Wallet – A TurtleCoin Wallet

Proton Wallet – A TurtleCoin Wallet

Hey everybody, as some of you may have heard, I’m developing a GUI wallet using the new and very capable wallet backend. The new backend was written by everyone’s favorite developer, the handsome @zpalmtree. It’s a really huge improvement over the old turtle-service based wallet applications as the wallet interaction is all done in pure javascript with no need for laggy RPC connections or mucking about running other processes, which leads to less lagginess and overall a better user experience.
Down the road I’m planning on implementing some more advanced multi-address wallet features, and I’d also like to see it become a full-fledged multi currency wallet. I think many users are tired of having so many different wallets installed on their computer: a really nice multi-currency wallet could really attract a lot of users.
Please test out the beta version which should be released in a few hours at and get back to me with your feedback.


TurtleCoin Added to Shrimpy App

TurtleCoin Added to Shrimpy App

I wanted to pass something along for the weekly update. TurtleCoin has been added as a supported coin on Shrimpy this week. It is a cryptocurrency rebalancing app. It will automatically rebalance your portfolio based on your long term strategy.


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!


Bounties are a great way to earn TRTL for doing small tasks, and also a good way of getting things done if you want something made and have some TRTL to spend.

  • 20,000 TRTL Get TonChan ( added to the TurtleCoin website, by making a PR to and having it merged. It should fit in with the rest of the website, so there should be an ‘Android’ entry added to the existing Apple, Windows, and Linux options.
  • 100k TRTLMerchandise bot that will keep price for listed items in #merchandise updated in $TRTL according to actual fiat exchange rate without mentioning the fiat in the listing. @Elkim | 100k TRTL

Pay With TRTL

In the 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.



199k TRTL free shipping anywhere in the US, 299k TRTL shipped anywhere else in the world.
Red, black, grey and cream are available currently


Shoutouts & Thanks

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

Safari, y u do us like this

Shouts out this week to TurtleMax for pointing out a crazy CSS error on the main site when you view it in Safari. This one’s actually an old bug that we thought had been fixed, but it looks like safari didn’t get fixed at the same time. Good eye! – Rock

Big thanks to the lads who were able to make it last week for DnD, it was really fun and I can’t wait to see what happens this week – Rock

Also Thanks to xiaomogwai for this TRTL wallpaper 😀

All Feature Story

How a transaction is born, and how wallet syncing works

Well, when a coinbase transaction and a fusion transaction love each other very much…

Just kidding. Grab a drink, this is a long, and confusing read.

Lets start by looking at where the money for a transaction comes from in the first place. All money originates in the network from mining – which creates new coins, via a coinbase transaction.

A coinbase transaction is a special kind of transaction that is rewarded to the person who mines a block. The money ‘magically’ appears, and is not sent to the miner by anyone.

Each block has a well defined reward it can claim
Each block has a well defined reward it can claim

This might make you think that miners can print as much money as they want. However, the coinbase transaction cannot be more than the current ‘reward’ – if it is, the other pools and daemons will reject the block containing it. The current reward is calculated by looking at the emission curve, and the total amount of coins in the network.

Lets say Bob decides to do some solo mining, and gets lucky one day. Maybe he mined block 900,000.

Bob's lucky day
Bob’s lucky day

Bob got 29,013.99 TRTL from mining this block. As you can see, this transaction has no inputs, because it is a coinbase transaction. The bit we’re interested in here are the outputs. Interestingly, Bob does not just receive a big chunk of 29,013.99 TRTL. Instead, he receives 6 outputs, of varying amounts, which add up to the full 29,013.99 TRTL.

Whenever a transaction is sent, it must be split into denominations. This is quite simple to do – it’s just splitting into units, such as thousands, hundreds, tens, etc.

The reason for this is due to how the mixin / privacy features work. When we form a transaction, we need to match the amounts we use with other ones other people have sent. If we didn’t split our outputs into these standardized amounts, we would need other people to have made transactions of exactly 29,013.99 TRTL before, which is pretty unlikely. Think of these standard amounts as building blocks to make any transaction amount.

So, Bob has got an amount of TRTL now, comprised of a few separate outputs. How does he spend them?

Finding which transaction outputs belong to us

First, Bob needs to work out if this transaction belongs to him. Since CryptoNote coins are private, we can’t tell what address a transaction was sent to without owning the private keys belonging to that address.

Now we’re going to have to get a bit nerdy and talk through some code. I’ll try and keep it simple. If you want to follow the code, check it out here.

Each transaction has a transaction public key which comes with it. We start by taking this public key, and our private view key, and performing some magic crypto operations, we can generate a key derivation.

Hey bro, you dropped your transaction
Hey bro, you dropped your transaction

Next, we loop through each output in the transaction, so in this case we’d start with the 0.09 TRTL output.

For each output in the transaction, we take our key derivation, the output index (This is simply the ordering of the outputs in the transaction), and the output key (That’s the long hex string which looks like a hash in the image)

We do some more magic crypto operations, and we get out a public spend key. This is the public spend key that the transaction was sent to.

If you weren’t aware, a TurtleCoin address (and any CryptoNote address, actually) is just a ‘nicer’ representation of the public spend key and the public view key.

For example, the address:


corresponds to the public spend key:


and the public view key:


So, we’ve got out the public spend key this transaction was sent to. What’s next? We just need to checkout if that public spend key is the same as the public spend key our wallet uses.

If it is the same as the public spend key our wallet uses, this transaction output belongs to us!

By the way – if the transaction doesn’t belong to us, we won’t get out the actual spend key the transaction was sent to – we’ll just get some meaningless garbage. So, your privacy is intact 😉

We then repeat this process for every output in the transaction. We can’t automatically assume because one output belongs to us, they all do. Remember, you can send a transaction to more than one person at once.

Once we’ve added up the outputs that belong to us, we’ve worked out how much we’ve been sent in this transaction. In Bob’s case, that’s 29,013.99 TRTL. Good work, Bob!

Storing the magic stuff which lets us send transactions

Bob’s got his wallet all synced. He wants to buy a TurtleCoin t-shirt from Alice. How does he send his money?

Cool shirt, Bob
Cool shirt, Bob

If we find that a transaction output belongs to us, we can then create a transaction input from that, using our private spend key. We can then spend those inputs, creating new outputs, for someone else to repeat the cycle with. A little bit confusing.

There are a few bits of information we need to store that comprise our new input. We need:

  • The transaction public key – This is included in the transaction.
  • The output index – This is the output index previously mentioned.
  • The amount – We can take this from the output data.
  • The key – This is the output key we used before.

We also need the global output index. This is part of the output data. This is used to keep track of all the output keys. Each different amount has a different global output index store. So, the first ‘1’ amount that was ever used in a transaction gets a global output index of 0. The second ‘1’ amount gets an index of 1, and so on. If someone then sends a ‘2’ amount, this gets an index of 0, since the indexes for different amounts are not related.

That’s a bit confusing, but if you don’t understand it, don’t worry – It doesn’t really matter.

Finally, we need to generate this inputs key image. To do this, we need to take the key derivation from before (remember that?), and our private spend key. We then perform yet again some magic crypto operations, and we are left with the key image.

Because we need to generate a key image to spend our funds, and we need a private spend key to do so, this allows us to create ‘view only’ wallets, which can only find incoming transactions, and cannot spend them, since it has no private spend key.

If you’re feeling utterly baffled by the previous explanation, the following diagram might help. Or, it might confuse you more. Sorry!

Arrows, so many arrows
Arrows, so many arrows

Spending our transaction inputs

Bob has got his transaction inputs all ready in his wallet. Surely he’s able to make a transaction by now?? Good news Bob. Let me explain the steps he needs to take.

Selecting the inputs

Link to the code here.

To start with, we need to find enough inputs to cover the amount Bob wants to send. Alice is sending her t-shirts for 25,000 TRTL, so we need at least that much. He also needs at least 0.1 TRTL for the network fee.

Inputs are selected randomly, to make it harder to detect any patterns in spending. We just keep taking inputs whilst we don’t have enough funds to cover the transaction.

Lets say that the inputs that get randomly selected are 3 TRTL, 0.09 TRTL, 20,000 TRTL, and 9000 TRTL. That sums up to 29003.09 TRTL, so we’ve got enough to cover the transaction.

Since Bob only wants to send Alice 25,000 TRTL, but he doesn’t have the exact amount to send, he instead sends the ‘change’ back to himself. In this case he wants to send 25000 TRTL + 0.1 TRTL (for the network fee) and he’s got 29003.09 TRTL in the inputs, so he needs to send 4002.99 TRTL back to himself.

Bob's spare change
Bob’s spare change

Preparing the destinations

Link to the code here.

Now we need to split this 29,003.09 into separate atomic amounts, and indicate who we’re actually sending each bit to.

Alice has given Bob her address, which we extract the public spend and view key from. We then split the 25,000 TRTL we’re sending her up into units, which is simply 20,000 TRTL + 5000 TRTL. These will eventually become two outputs for Alice to scan, just like we did at the beginning of this article.

Next, we need to setup the destinations that Bob is sending to himself. We take our address, split it into a public spend and view key, and again split up the amount into units. This will give us 4,000 TRTL + 2 TRTL + 0.9 TRTL + 0.09 TRTL.

So, the transaction will have 6 outputs – 2 belonging to Alice, and 4 belonging to Bob.

Outputs = 20000 TRTL + 5000 TRTL + 4000 TRTL + 2 TRTL + 0.9 TRTL + 0.09 TRTL

Preparing the Transaction Inputs

Link to the code here.

Next we need to hide our real inputs among other inputs, to obscure which inputs are really used to create the transaction. We ask the daemon for as many fake outputs as our mixin value, and we need this many for each amount we are sending. If we are using a mixin of 3, we need 3 fake outputs for 20,000 TRTL, 3 for 9,000 TRTL, and so on.

Next, we loop through each real input, and the fake outputs. We generate a key image using the real input transaction public key, our private view key, and our private spend key. This also gives us a temporary key pair for each transaction input, which we’ll need later for our ring signatures.

Now we can finally make a transaction input, which consists of the amount, the key image we just generated, and the global output indexes of both the fake outputs and our real input. Gah, confusing.

We end up with 6 transaction inputs, with each one having 3 fake global output indexes, and one real global output index. No-one but us can tell which is the real index.

Yay, pretty gifs
Yay, pretty gifs

Preparing the Outputs

Link to the code here.

Now we can make the outputs of the transaction. We start by generating a random key pair. This is used so multiple transactions to the same address cannot be linked together.

Next, we loop through the destinations we prepared earlier. We generate the output key by taking the receivers public view key, the private key from the random key pair we just generated, and the receivers public spend key.

Then, we create our output, which is just comprised of the output key we just generated, and the amount the output is worth.

We store the public key from the random key pair we generated – this becomes the transaction public key later.

Assembling the transaction

Link to the code here.

Putting the pieces together
Putting the pieces together

We’ve done most of the work now, we can start putting this transaction together. We start by creating the tx_extra – This has a few bits of data in, but most importantly is the transaction public key. If we’re using a payment ID, we also add that in here.

Then, we copy over the inputs and outputs we prepared earlier, and add a few extra bits like the transaction version, and the unlock time if you want your transaction to not be spendable instantly.

Finally, we hash this data to give us the transaction prefix hash.

Generating the Ring Signatures

Link to the code here.

Finally, we generate the transaction ring signatures. These are used to verify that we own all the funds being spent. We generate signatures for each transaction input, using the private key of the temporary key pair we created for each input earlier, the transaction prefix hash, the public key that each fake transaction output has (including our real input), and each transaction input key image. This again, uses some cryptography magic.

Ring signatures indicate that one person of a group signed a message with their private key, but it cannot be determined which person signed the message. This proves we are able to spend the amounts in the transaction, but our identity is kept hidden.

Sending the transaction

Finally, we’re done! We send our transaction off to a daemon, and if it verifies the transaction is legitimate, Alice will get her funds shortly. There’s one thing we missed when I explained this – detecting when you have spent funds, rather than just when you have received funds.

Bob's transaction flies across the network
Bob’s transaction flies across the network

Finding which transaction inputs belong to us

Fortunately, this bit is pretty simple. Remember when we generated a key image, when we found a transaction that belonged to us? Because that key image is used in a transaction when we send it, we simply look at each transaction input, and if it uses a key image which we created, then we sent it.

Thus, when Bob scans the transaction he sent to Alice, he will see the 4 inputs we used to create the transaction, and find that they use key images he previously created. He will mark these key images as spent, so he doesn’t accidentaly use them in another transaction. This would cause an attempted double spend, which would fail, as a key image can only ever be used once.

When Bob sums the transaction inputs, he would get 3 TRTL, 0.09 TRTL, 20,000 TRTL, and 9000 TRTL – The exact amount he sent. He should then scan the transaction outputs, and find 4 outputs that belong to him – 4000 TRTL + 2 TRTL + 0.9 TRTL + 0.09 TRTL – The change that he sent back to himself.

With this, Bob can work out the total amount he spent on the transaction – inputs – outputs = 25000.1 TRTL.

You may remember that Bob decided to pay a network fee of 0.1 TRTL, but we never gave an address to send this to. The network fee is simply the difference between the sum of the inputs, and the sum of the outputs – the miner who includes this transaction in a block is allowed to add this amount to the coinbase transaction as a reward.


In summary, a transaction is comprised of inputs, outputs, and ring signatures.

  • Transaction inputs are money we have previously received, combined with some data to generate the keys. They are also hidden among other people’s inputs.
  • Transaction outputs are money that the receiver(s) get. This may include some change which returns to the sender.
  • Ring signatures prove the transaction is valid and we own the corresponding private keys. This is an example of a zero knowledge proof: A third party can prove the signatures are legitimate, but it gives them no information about who the sender is, or who the receiver is, just that the transaction is legitimate.
  • If a transaction input has the same key image as one we generated, that is an outgoing transaction by us.
  • If a transaction output has the same public spend key as ours when decrypted, that is an incoming transaction for us.

I’m sorry if you didn’t understand this. It’s quite confusing, and quite hard to explain. I have to say, the whole inputs, outputs, fake outputs + real input thing confuses me as well.

Thanks for reading.
Thanks for reading.

Thanks for reading – hopefully you learnt something!