One of the things that has been most requested of us is a mobile wallet. In the past we've always pointed mobile users to our web wallets, but a brave turtle came forward and put together a cool android wallet and we're pretty stoked about that, so here's an interview with the creator!
TRTLfarm is one of the first web-based games build on top of TurtleCoin, utilizing TRTL.Services. Players deposit TurtleCoin on their account, allowing them to purchase virtual farm animals. These farm animals generate produce, which in turn can be sold for TurtleCoin at a price which is determined by the total balance of the game at that moment.
Hey Boris. Thanks for agreeing to do this interview with me. As some already know, you are the developer behind the web-based game TRTLfarm built on top of TRTL.Services. I want to congratulate you with the early success, it has gotten a lot of attention the past few days in the Turtle community. I thought it would be a good idea to interview you as so that our readers can get a better understanding of the game mechanics and purpose; your motivations and future plans ahead. So without further ado let’s get started!
What led you to make this game? When talking to you a few days ago, you mentioned that you played a similar game like this on the TRON network; was that your inspiration?
Yeah, that was it. I played a lot of DAPPS on TRON network. That being said I wanted to do some kind of game on TurtleCoin network so the TRTL becomes a utility token for the game. Since we all like farming games I decided to go in that direction. I also loved the API from TRTL.Services, and decided to put it to use for this project. All started with a simple design and one thing lead to another and now I’m trying to keep up with the request for additional things.
I can imagine. I have been watching your progress and been myself also involved in the game. It’s simple, but quite fun to play! How did you go about designing the game? Could you maybe, in a few words, explain what the purpose and goal of the game is?
To be honest about everything, I was at first only interested about it as a sole project and maybe invite some friends to play with. The design was done just as one thing on another. I was not planning anything prior starting developing it. The main purpose of the game is just to have fun with it, compete with other players and to just use shells as a utility so they float around. I have heard a lot that the game is “Ponzi” scheme and/or exit scam. I can just tell you as I told many others, I’m not planning anything like that, as I’m learning from developing it further and take knowledge from it all. There is a simple calculation behind it and I must say that some users will get ROI and some never will. There is no additional funds in the game, just what users bring in.
I have seen that you developed it using .NET Core. Was there any particular reason for that choose or is that a language you feel comfortable with?
Yeah it’s developed in .NET Core. I decided to use it, because I want to strengthen my skills in it.
On the topic of the ROI you mentioned, can we get more into that? I assume you’re pointing at this part of the code:
Ah, the ROI thing again The function above calculates the current unit price. The total balance is divided by the players total productions, and divided by 60 which is hard-coded. Why 60? No particular reason behind that; the game could not end in one day.
Gotcha. Moving on, how can a player improve their ROI and how can they prevent from losing. In other words, what is the secret!
How can user improve a ROI? That’s a hard one, haven’t thought too much about that. I think the secret is to watch when someone joins and sell only then, because you get more per unit. Still, it’s up to anyone, so I can’t clearly answer that.
I guess we’ll leave that to the players to figure out. I see that you have been very busy, and even during this interview you released a leaderboard page as a new addition to the game. I must say, I’m impressed! So what is next? Are there any plans on adding new animals or perhaps additional items or functionality to the game?
Yeah there are plans yes. I’ll say there will be special animals, not to go in too much detail at the moment. Also you will be able to buy your nickname on a leaderboard instead of payment ID pretty soon (has been added by the time of this publication).
Cool! I can’t wait. The other day I know you were busy for over six hours patching a critical bug our friend SoreGums from the core TurtleCoin team discovered. I can imagine upon hearing about the exploit you must have gotten at the very least some sweaty palms. You followed the correct protocol, disabled the withdraws, and quickly patched the bug. As this is a common exploit that led to the emptying of a few cryptocurrency exchanges, I think our readers would be interested in learning more about this. Would you be so kind to explain what the problem was and how it was resolved?
Ow boy, I was excited and devastated at the same time. That just goes to show SoreGums’s honesty and helpfulness, and I’m glad he got in contact with me. I’ll briefly explain it now. There is a delay while contacting TRTL.Services API (time that goes by while calling and waiting for a response ) and getting the balance deducted in the game so people could execute multiple withdrawals at the same time from different browser tabs for example.
From what I understand the issue did not lay with TRTL.Services but with you not saving the balance first after modifying it but waiting until the end, creating a time delay which gave the attacker the opportunity to execute multiple requests.
Correct. The game balance did get deducted after the call, now it’s deducted before and instantly saved to database. Before it only executed changes to the database at the end, and during that time frame there could have been millions of requests that would go through, check the balance, and proceed to withdraw.
Boris, do you have anything else to add to this interview, or shall we wrap it up? I suppose we will be hearing updates from you in the weekly roundups when something new is out. Where can people reach you best?
That would be it. Best to reach to me in Discord. Thanks for everything!
A lot of you out there have questions about how pools work and what goes into running a successful one. Today we’re checking out an interview with FunkyPenguin who runs probably one of the coolest setups I’ve seen so far with all of the pools I’ve seen. Maybe I’m just a nerd, but I have a big appreciation for the way he’s doing things.
You’re gonna love this one!
Thanks again for agreeing to the interview. The purpose of this interview is for us to highlight smaller pools that have unique things about them. Giving exposure to smaller pools is important in diversifying the hashrate. I hope today to hear about you, your pool, your history in mining and what a user might find unique about your pool.
Your pool is a cool one, and I think the miners as well as developers will appreciate the unique qualities to it. You first came on my radar with some of the interesting infrastructure work you were doing behind the scenes. I’d like to get in to that soon, but first, tell us how you got involved in TurtleCoin, and what led to you running a pool.
(I’ve documented this here: https://www.funkypenguin.co.nz/opinion/what-is-turtlecoin-and-why-do-i-care/), but here’s the off-the-cuff version
I was opportunistically looking for coins to mine after the Monero Cryptonight v7 fork, so I spent some time on cryptunit.com. Every so often, I’d see “TurtleCoin”, and laugh at what a silly name it was, and how ridiculous the crypto space had become.
Somewhere (maybe Reddit) I saw the headline for the BlockZero (Kevin Rose) podcast featuring TurtleCoin, and the name triggered some brand recognition. The level of respect that Kevin had for the project, and the way “community” was highlighted, changed my initial skeptical opinion, and I jumped into the Discord
I felt that I wanted to be more than another opportunistic miner, and that a “baby” cryptocurrency was a good place to start learning. (There was no NZ mining pool)
I’d already spent 6-8 months building my Geek’s Cookbook (a collection of self-hosted apps running within Docker Swarm), and wondered whether I could build a TurtleCoin mining pool. I figured I should start with a testnet, so I started asking some questions in #dev_general, and @SoreGums pointed me in the right direction. I ended up submitting a PR for a testnet Docker instance of the TurtleCoin daemon which could be used to create a testnet in total isolation from mainnet.
Having built a testnet, I started working on the mining pool, learning about wallet/daemon/redis/pool, and how they interrelate. I wrote up the Docker Swarm design (a bit outdated now).
There were some interesting challenges re how the pool components talked to each other, some of which lined up very well with the “one-process-per-container” model of Docker. I sort of fell into it from there, started mining in my pool, discovered that I could advertise in #mining , posted my pool to r/TRTL a few times, and enjoyed the process of mining “together” with other geeky crypto enthusiasts
It’s great that you’ve documented your journey the whole way, and as a microservice nerd in my own life, I feel a personal respect for what you’ve done.
(To be honest, I also want to profit from crypto, and I figured I’d leverage my systems experience to build pools to amass some coins, rather than strictly mining-and-selling-and-hodling)
You’ve got a cool frontend on your pool, and as I remember, you were one of the first to have the new-style interface. What are some of the unique qualities of your pool that would be interesting to a miner looking to diversify their hashrate some?
I polled my miners on this question, asking “what features does a miner really care about?”. The best response was from @slashatello, who said “miners care about.. BLOCKS”. I was interested in the telegram/email notifications from https://github.com/dvandal/cryptonote-nodejs-pool, which remain my favourite feature. Here’s an example:
That looks cool, break it down for me- what’s going on in that pic?
11:57 : The pool restarted (I’m running turtlecoind-ha, that’s another story), my rig connected
12:04 : The same again (this happens when the daemon gets stuck, it sometimes takes a few goes to restore stability)
12:07 : One of the miners finds a block. Yay! Now we wait 20 min to confirm it’s not an orphan
12:11 : Yes, daemon restarts again
12:29 : Block is not orphaned, now is the first time (based on these notifications) we see what our effort was (43%). Unlike the original turtle-pool software, lower % is better, so we “found” this block in 43% of the time we’d statistically expect to (we were lucky)
<by this time, the wallet has received the block reward. Redis calculates how much each miner is due, and payments are prepared>
12:31 : The pool sends the miners their portions of the block reward (minus my 0.0987654321% fee), everyone is happy
(the fee is a funny story actually – when I first setup the pool, I looked at the list of pools and saw someone else’s pool listed as 0.0987..%. I thought it was a clever attention-grabbing move, so I adopted it for myself. I think I read later that it was just a math bug!)
That’s pretty funny, actually! Thanks for giving us the play by play. That’s a pretty intricate setup. So you’ve made a pool, and you’ve written guides and Dockerfiles for us, what don’t you do?! You’re awesome! What do you have planned for the future, and what are you interested in learning right now?
Thank you Well, this daemon restarting thing is a bit of a PITA, and the original platform I ran my swarm on was heavily contended at times, so I’ve just finished migrating the pool to a Google Kubernetes Engine (GKE) cluster. I still have the occasional daemon issue (as evidenced above), but we seem to recover from a stalled daemon with a few quick restarts.
I overspeced the GKE cluster when I built it (I’m only using 22% of my resources for Turtle/Moneytips pools), so I’m currently playing with autoscaling the cluster, as well as using a “tainted” nodepool running (cheap) pre-emptive node instances for doing CPU-heaving stuff like syncing new coins blockchains. The fact that they’re pre-emptive means that Google could turn them off at any time, but the GKE engine would just spin me up a new one in a few min, and for the purposes of an initial blockchain sync, I don’t need to maintain any sort of availability
So I’m enjoying learning more about the world of Kubernetes / Terraform. I’m also continuing to build the Geek’s Cookbook community, the Discord gets quite busy at times, and there’s now enough geeks on board that I don’t end up answer every question myself, which is great to see.
I’ve dabbled with “livestreaming”/”livecoding” – last night I had an audience of 4 geeks watching me configure Lidarr with NZBHydra – thrilling stuff!
Oh, and my new darling, Prometheus/Grafana – I’ve been building on the “swarmprom” stack , adding prometheus exporters for nvidia GPU stats, Emby, Nginx, etc
I’m planning on doing Geek’s Cookbook Vol II – The Kubernetes Edition, although how I combine this all into the same content structure is YTBD.
One of the challenges with either Swarm or Kubernetes is that it’s very hard to have the original source IP of the miner visible to your pool, because of all the layers of load balancing and NAT that applied. This means that you can no longer ban bad/misconfigured miners by IP address (because you don’t have their IP address). I haven’t found a failsafe solution for this yet, but I have an open bounty for providing a way to ban miners based on TRTL address, rather than IP address. I also had to add a workaround to the pool software to bypass the IP-address-check which you’d normally have to pass, in order to enable/disable email notifications.
If you had to make an appeal to miners out there wanting to spread out the hashrate some, what would be an advantage of choosing your pool?
While I originally tried to “corner the market” on an NZ / AU pool, truth is that the latency to NZ has no impact on blocks found, in real world observation. 90% of our pool hash (@Slash-atello) is from the US. So I’d appeal to TRTL miners (worldwide) who are also into microservices / homelab / self-hosting (and LEGO, high-fiving @bruceleon) to not just mine with us but come and “geek out” with us in Discord at http://chat.funkypenguin.co.nz
I think I’ve got everything we need, is there anything you wanted to add that I may have missed?
Probably yet (yet another) acknowledgement that the “secret sauce” in TRTL, which stands out from other coins, is the focus on community and fun. Thanks for welcoming me
Thanks for being a part of this experience!
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 CoinGecko.com, 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.
With all the commotion about the next fork upgrade, and the debut of our new hashing algo, CN Turtle, I wanted to make sure everyone has the run down about the fork upgrade before it arrives in a few weeks. Today, I got with IBurnMyCD who has been the lead on this algo and got a short interview about what is CN Turtle and what does it mean to me, both as a miner and a user.
If you’re a miner, a user, or a fan of fine rewritable optical media, I think you’ll enjoy this article. It was a fun interview. If you have any questions, just click this link and join us in the chat, we’re all here waiting on you.
@iburnmycd thanks for taking the time to do this interview. I wanted to get with you to discuss the upcoming fork upgrade in simple terms so our users know what’s in store for them.
First, what is the deal with this fork upgrade and why are we doing this?
Thanks for having me @RockSteady (TRTL). It’s always an honour to help let the community that isn’t in the Discord all the time to catch the latest and greatest news. A while back, the project made the commitment to the community that the project would do its best to remain mineable for as many users as possible. Part of holding to that commitment is investigating, testing, implementing, and upgrading the Proof of Work used by the project. We’ve done this with experimenting with CN Soft Shell that a few forks of TurtleCoin have implemented and again with CN Turtle that we’re forking to at block 1,200,000. This upgrade is designed to help keep the project mineable for everyone by reducing the resource requirements necessary to mine. As a result, everyone will see higher hash rates which also means that there is a higher chance of solving a block as each miner will be producing hashes noticeably faster. However, there will be more hashes required (on average) to find a block. Our hope is that in the larger scope of things, this works out to be a win for the the littlest miners.
You mentioned our miners will be mining faster, what does that translate to for someone who has 100H/s of CPU power or another person who has 100H/s of GPU power?
Based on testing, we estimate that miners will see on average an increase of anywhere between 3.0x and 4.0x for CPUs and 2.0x to 3.0x on GPUs. Personally, on my hardware I’ve observed a 3.8x increase on my CPU (AMD 1950x) and 2.8x on my GPU (AMD Vega64). However, not every CPU and GPU performs the same so the increase may be more or less than what we’ve observed. Variations in drivers, the mining software used, etc may result in higher or lower increases; however, what we can all agree on is that miners will see an increase in hashrate, no matter how small, due to the lower resource requirement and iteration count. On average a miner who was seeing 100H/s on CPU may see approximately 350H/s and a miner seeing 100H/s on GPU may see approximately 250H/s after the upgrade takes effect.
That’s great news. Let’s say you’re a miner, what do you need to do to be ready? Are most major miners already ready to work? And what if you’re just a user, do you have to do anything?
That depends on how you mine 🙂 If you’re a solo miner and you use the miner binary distributed with the project, you’ll need only upgrade to v0.12.0 once it’s released. The miner software will automatically switch to the new PoW algorithm when it’s time. If you’re mining with a pool, you’ll need to contact the pool operator or check their website to verify that they have upgraded their pool software for the upgrade. If they haven’t, you might want to give them a gentle reminder that they need to do so. In addition, you’ll want to make sure that you have the latest release of your favorite mining software. For instance, we’ve released the necessary updates for xmr-stak via trtl-stak (https://github.com/turtlecoin/trtl-stak/releases/latest) that has the updated algorithm available as cryptonight_turtle. In the coming weeks, we’ll submit a pull request to the main xmr-stak repo to support the change. We’re still working the kinks out of the automatic algorithm switch in the package but in the event we don’t work that in, a miner need only manually switch the algorithm, delete their CPU & GPU configs, and let the software do the rest. We’re still working on adding support into XMRig and hope to have that completed before the network upgrade. We’ve also received information that SRBminer has also implemented the algorithm. Users of that mining software will need to switch the algorithm over when it’s time. Everyone, miners or not, need to keep their eyes out for the v0.12.0 release of the project. Service Operators, home users, pool operators, and other services will need to upgrade to v0.12.0 well ahead of block 1,200,000 to be ready for the upgrade. For most users, this upgrade will be like any other upgrade that we’ve done where you drop the new version in and you’re good to go.
Whats the best way to see how long we have before the upgrade takes effect?
The quickest and fastest way is to head on over to the official block explorer at https://explorer.turtlecoin.lol/ In the Network Stats area, you’ll see an area that says Next Network Upgrade In (est.) with the approximate number of days, hours, minutes, and seconds until the next network upgrade.
Thanks for taking a second to tell us about the fork upgrade, is there anything else you wanted to add?
If you’re reading this and you are not on Discord, you should be. We’d love to have you. It’s the only way to get a real feel for the project and meet all the different personalities. If you want to help out, there’s plenty of different areas to check out from development, education, marketing, international groups, and everything in between. Discord is the best place to meet other cryptocurrency developers who share a passion for the technology and their projects. Besides, where else can you learn about codename Chukwa?
Some time ago we began a series of interviews with pool owners who operated mining pools with unique flair about them, or who had ventured off the beaten path in what they offer their miners. The goal was to help decentralize the network’s mining power, which we actually accomplished. We still want to interview our service operators though, both because it’s fun and it helps you guys get to know those in your local community.
Speaking of local communities, today we have a special interview for those of you in our Spanish speaking community- an interview with CryptoHispano who operates a pool for our Spanish speaking miners. We’re very thankful to get to speak with them and happy to introduce you!
Thank you for taking the time to do this interview with the community, CryptoHispano. Your pool is special to us because you are one of the few who cater to a regional community, in this case, the Spanish-speaking community. How did you get started in mining, and if you don’t mind, tell us a bit about the Spanish-speaking mining community you’ve created.
Hi, thank you for this opportunity to explain about the Cryptohispano project. I started with a friend riding a rig and good investigating a bit of how it worked all that rig, the riser and all those strange words that I hear in this world. We started mining Eth until we reached the goal of two, in that period of learning, I met people for chats and with some I made good friendships in particular with Jorge who was a Dev from a company and commented why not set up our popio pool. I told him that I would help him as much as I can since I’m not a programmer and I do not know how to program. We said we are going to open a pool for the Hispanic community and from there cryptohispano.net was born a pool that is born to bring the cryptos closer to people who have problems with the language barrier, as I Carlos (bytecanarias) do not speak English nor what I write and I saw that it cost a lot to get information, that they explained how this was going, where it started, etc. I told Jorge we had the pool but everything will be in Spanish, to reach all those people who do not understand English very much or even do not master anything. So he got down to work and we set up a BCN pool with the bad luck that the ASISC went into BCN in the weekend and we had to leave or die, one of the members of the channel, a restless Raul, was always saying look at this model look at the other and in one of those named Turtlecoin, because we started looking at it and we lived with many people behind working on it and responding in time to doubts, Jorge said that these people are serious on GitHub all well ordered , explained step by step, a very clean code “This coin will be very good” so we lasso for the turtles.
After a month, due to work issues, Jorge left the project and I saw myself alone, so I started to investigate and ask and bother all those who were in the channel, in the end I found people who helped me with all the problems and I am very grateful that there are people who want to help. I help in what I can to all within my limitations since not knowing about programming I can only help with what I have learned. I also want to tell since I have the opportunity to ask me why the pool has the 1% fee and there are pools that are at 0% is something that I also wonder, because with the work that costs to keep the pool in operation, the rental of hosting and the hours of dedication that this requires I do not understand either. Thank the entire community that supports us and those who continue to do so. We will continue to strive to be a great community.
Cryptohispano, you’ve been a very good gift to the Spanish-speaking miner community. What do you think TurtleCoin can do to engage the international community more effectively?
Well, from my point of view I honestly would not know what to say, on the part of the miners, what I always hear them is that they would like the currency to rise or that there would be less suppley for it to rise in value more quickly. I think that for a coin to take value you need to use, understand both physical and online. For example, I accept crypts for the hiring of vps I think that if many were like this we would achieve that the cryptos had a real use and not of expectation.
What Turtlecoin could do or try is to find a way to use it so that it takes form and value. Supermarkets, neighborhood stores go looking for people who are willing to accept them like me.
CryptoHispano, it has been a pleasure to interview you, and I hope our Spanish speakers will find a comfortable community mining with you!
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.
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
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.
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?”
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
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.
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.
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.
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!
The core development team has observed the fact that the network hash rate has climbed substantially over the last few weeks. Luckily, the hashrate has remained rather decentralized and balanced over the large number of pools that the community operates. However, the significant increase in hashrate has made it more difficult for the project to meet one of its core goals. To remain mineable for everyone. After careful consideration, we believe it’s once again time to perform a soft fork to a new Proof-of-Work (PoW) algorithm.
Such a change is not taken lightly, and we’ve given considerable thought to where the project should go in this regard. We’ve seen a few networks using CryptoNight Soft Shell variants with success. Although considerable work has been done to support Soft Shell pools and the like we’re not quite ready to move over to Soft Shell just yet.
You’re probably asking yourself, “So what’s the plan?”
Supported PoW Algorithms
If you’ve read through the TurtleCoin fork guide, forked TurtleCoin yourself, or have read through the code, the next few statements are going to come to no surprise to you.
We like to collect PoW algorithms like they are pogs. The more you have, the more fun you’re having with your friends.
Keeping this in mind, TurtleCoin currently has built-in support for no less than twelve (12) different PoW algorithms. Yes, you read that right, twelve.
They are, in no particular order:
- CryptoNight v0
- CryptoNight v1
- CryptoNight v2
- CryptoNight Lite v0
- CryptoNight Lite v1
- CryptoNight Lite v2
- CryptoNight Turtle v0
- CryptoNight Turtle v1
- CryptoNight Turtle v2
- CryptoNight Soft Shell v0
- CryptoNight Soft Shell v1
- CryptoNight Soft Shell v2
Woah, Wait, What’s CryptoNight Turtle?
To put it mildly, CryptoNight Turtle is a tweak to the standard CryptoNight family that significantly increases the speed at which hashes can be computed. This is accomplished in two ways.
We’re dropping the iteration count in fourth as well. From 524,288 iterations to 131,072 iterations. This will result in the base hashrate increasing for every miner.
Scratch Pad Change
We’re dropping the scratch pad size in fouth. From 1MB (CN Lite) to 256KB. Why? because we want to make everything go faster and when we’re dropping the iteration count, we need to make sure that the scratchpad is used effectively to prevent some interesting attack vectors.
Faster? Doesn’t That Mean an Even Higher Network Hash Rate?
It sure does! There’s a reason for what appears to be chaos and we’re just getting to the good part.
TurtleCoin Major Block v5
As you’re likely thinking, “This doesn’t sound better, no, no, these guys are crazy…”
Block Major version 5 is planned to activate CryptoNight Turtle v2. That’s right, variant 2. Those of you following other projects using v2 likely know that there is a performance penalty incurred by variant 2 hashing. We’ve personally seen a performance hit of anywhere from 12% to 45% on some hardware. We think that’s unacceptable; however, we do like the premise behind variant 2.
To balance the performance impact of variant 2 out, we’re going to hash faster with CryptoNight Turtle. The two effectively cancel each other out and we gain the benefit of soft forking away from potential ASIC/FPGA/etc. miners. As a matter of fact, you’ll see a hashrate increase on your miner(s) because of the move to CryptoNight Turtle.
The move to variant 2 will help strengthen TurtleCoin’s ASIC/FPGA resistance. Future PoW changes will also be designed to further strengthen the project’s ASIC/FPGA resistance to try to keep TurtleCoin mineable for everyone.
Doing Your Part
We’re confident that we have the core code ready for the soft fork to CN Turtle tentatively scheduled for block 1,200,000. The main pool software has been updated to support it as well as the underlying Node.js Hashing Library and the Node.js Cryptonote Library have been updated.
There’s still work to be done and any community assistance is, as always, appreciated.
We’ll need help from the community to test this algorithm change to try to ensure that everything goes as smoothly as possible. The more people that are involved, the easier it is to spot issues.
We’re working on adding support to common miner projects to support this change including:
Miner software needs support added before we can fully test the update pool deployments. If you want to give us a hand in getting that support completed, join us on discord at http://chat.turtlecoin.lol in #dev_general.
The pool software changes need ported to the other pools that the community service operators use on a daily basis. If you are familiar with one of the following pools, your assistance is appreciated in this regard.
As always, be mindful of TurtleCoin core releases. Watch or star the main TurtleCoin repo to help stay abreast of changes and updates. Join Discord and read the #announcements on a regular basis. Or, sign up for the @news role by typing *news in the chat and be alerted whenever a new announcement is posted in Discord.
Make sure you’re ready for the soft fork as early as possible.
As with any soft fork, if and when the fork occurs, prior versions of the software will no longer be compatible with the rest of the network after soft fork completion.
We’re already putting thought into the next PoW algorithm change after v5. Those discussions will be a different article, so as always, stay tuned.
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.
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 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.
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?
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!
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.
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.
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.
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.
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 – hopefully you learnt something!