Categories
Feature Story

TurtleCoin® v2 FAQ

The community sent in questions and we’re here to answer some of the most popular ones. We’ll try to keep the answers straight and to the point wherever possible. 

This article is living and breathing and additional topics may be added as they come in. This permalink is the best way to always link to the latest version of this article.

Note: Some questions may be paraphrased from the questions submitted by the community to help avoid ambiguity in duplicate questions.

Q) What is TurtleCoin® v2?

Put simply, v2 is the next generation of the the TurtleCoin® project. Out with the old and in with the new as they say. The v1 network served us well, but as time has passed we want to do more, and to do that best, we need a clean slate. By starting a new network from scratch, we are able to make much bigger improvements without worrying about being backwards compatible with previous history.

For more information, we suggest reading TRTL v2 and TurtleCoin® v2 Overview as well as other blog articles as they are produced.

Q) When will v2 be released?

We’re aiming for before block 4,000,000 of the v1 chain. The actual date is fuzzy at this time but as we get closer to a release date more information will be made available.

Q) Where is the v2 whitepaper?

We gave ourselves a short deadline to come up with v2 software, so for now we are focusing on writing that first, with a whitepaper coming soon after.

If you’re looking for write-ups on what we’re doing as we are doing it, check out the blog articles for the latest and greatest about TRTLv2.

Q) Are you planning to have an audit performed?

We very likely won’t pay for an audit like other projects and instead are working with volunteers in their respective areas to provide feedback and guidance on our implemenation of the cryptographic primitives used in v2. We are also keeping a close eye on the audits performed on other implemenations that may provide insight or changes in how we have implemented the cryptographic concepts.

We encourage everyone to take a look at the cryptographic code that’s being used in v2. It is currently available in the turtlecoin-crypto repository. If you have questions, comments, or suggestions, simply open an issue on that repo.

Q) What are the biggest enhancements or benefits of v2 that we can look forward to?

  • New Core software, written from scratch, in-house.
  • Delegated Proof of Stake
    • No more mining blocks which enables faster settlement of transactions that is backed by users staking nodes as producers and verifiers of transactions and blockchain data.
    • The delegated portion of this means that users vote for producers and validators by staking funds instead of all producers and validators being predetermined.
  • Staking
    • Enables every user who wishes to stake a chance to win block rewards by helping to secure the network
  • Bulletproofs+
    • Range proofs enabling masked amounts which reduces the occurence of dust on the chain.
  • Arcturus
    • Faster transaction signature verification with large anonymitity sets
  • Transaction Pruning
    • Less chain bloat means a smaller chain and lower storage requirements for operating a node
  • No Block Intervals
    • Blocks are only created when there are transactions to be processed, there will be no empty blocks.

All of these changes allow the network to be even more stable, fast, and easy to transact with. The chain will be smaller, faster, and easier to sync than v1. The network will move faster, transactions will move faster, and we’ll see significantly lower transaction fees.

For more information, we suggest reading TRTL v2 and TurtleCoin® v2 Overview as well as other blog articles as they are produced.

Q) Faster transactions and pruning? How might these changes apply to applications that are built on TRTL?

Due to the overzealous use of extra data in transactions in the past and a lack of the fee-per-byte structure we had to implement a maximum to the amount of arbitrary data you could put in each transaction. This was to prevent attacks on the network caused by the propagation of bloated data for the low low price of 0.10 TRTL (the network fee at the time).

The extra space had valid uses for things such as payment IDs, transaction public keys, and a few other pieces of necessary information. This same space could be used to load arbitrary data such as messages, files, and other bits into the transaction as well. However, with a maximum of 1,024 bytes (1KB) developers have to get very creative in how they store data on chain.

The significant reduction in transaction sizes in v2 coupled with the changes to transaction structures and a fee-per-byte model incorporated at chain launch will allow us to open up the maximum amount of space that can be used to carry arbitrary data on chain. This will enable developers to leverage the chain in new ways and we’re excited to see what people come up with.

Q) What will be the minimum amount required to stake?

We haven’t settled on the required amount to propose a new candidate node into the network just yet. While we want anyone to be able to run a candidate node in v2 we have to make sure that there is sufficient “skin in the game” to ensure the success of the network. You’ll be required to “lock up” your stake to be a candidate node for a minimum amount of time.

As for users staking (“voting”) for a candidate node, 1 TRTL = 1 vote. You’ll need to stake whole TRTL coins to cast a vote. Like the stakes for candidate nodes, you’ll be required to stake your funds for a minimum amount of time before they can be recalled.

In any event, you’ll want to vote for trustworthy nodes that do their job in securing the network otherwise it puts your funds at risk.

Q) Does DPoS mean that TRTL is becoming a governance token?

TRTL isn’t a token. It’s a currency, an asset, a network, not a token riding on another chain.

TRTL’s take on DPoS uses PoS as a facility to put skin in the game to produce and validate blocks and gives normal users a chance to get a portion of each block reward. It’s far less about governance in the sense of voting for protocols and more about maintaining consensus and keeping the chain moving in an agreeable way.

Q) Is TurtleCoin® v2 focused on privacy?

Privacy is a beneficial side effect of some of the technologies that will be used such as Arcturus, Bulletproofs+, and Pedersen Commitments though it isn’t a specific goal we had from the beginning. All of these technologies are being adopted to reduce transaction sizes, speed up transaction verifications, and reduce network overhead thereby allowing for a much high transaction volume through the network. Those improvements happen to come with the bonus of a high level of privacy. 

As technologies such as Arcturus allow us to have very small signature sizes and have lower verification times – why not crank it up to 11 and enable massive ring sizes. Sure, this increases privacy on the network but that’s enabled by the changes we’re making to make the chain smaller, faster, better, and stronger.

Q) Why is the total supply changing from 1,000,000,000,000.00?

Right now, to buy a sandwich, you’d spend almost a million TurtleCoin. 1,000,000 can be made up of a LOT of inputs, and in our current way of making transactions, each of those inputs has a lot of signatures attached to it, which means fat transactions and big fees. That can’t be realistic. This would mean TRTL is near useless as a currency if you can’t even buy lunch with it.

In a nutshell, we call this dust. There are over 100,000,000 outputs on the v1 chain right now and most of those are dust. Seriously, go check it out on the mixable amounts page of the explorer. Over 10% of the outputs on the network are worth 0.01 TRTL today. We need to avoid this like the plague in v2. Moving to pedersen commitments and amount masking helps a lot in v2 and saying “1 trillion TRTL” was fun and all – but we really don’t need this baggage going into the overhaul, do we?

Q) So the total supply will be 10,000,000 TRTL in v2?

Not quite. The relation to 10M TRTL in v2 was to give people an idea of what the reduction via the swap will look like. In actuality, there is no cap to the total supply in v2. Hold on, put down the pitchfork, we’ll explain.

Right now, we estimate that the circulating supply of TRTL v1 at block 5,000,000 (when the chain ends) will be around 120,000,000,000 TRTL when accounting for the ramp down of the v1 chain. At the swap ratio of 100,000:1, this means that approximately 1,200,000 TRTL will be pre-mined on the v2 chain to fund the swap process (details below).

After that pre-mine, emission mechanics will be driven by use of the network. Block rewards will be granted at a 1:1 ratio of the full value of the transactions contained in the block in a fee-per-byte manner. This means that if a block contains transactions with a total of 1,000 TRTL in transaction fees, the base block reward will be 1,000 TRTL and the total block reward will be 2,000 TRTL.

Blocks will only be created when there are transactions to process so emission will be tied directly to the use of the network with no upper limit. The more the network is used, the more that is released into the circulating supply.

Q) Why will v2 only have two decimals?

Two decimals works at this point and helps keep dust in check. More than two decimals is confusing in many ways and makes it very hard to understand how much you are really sending in a transaction.

Q) How will the v1 to v2 transition work exactly? What happens to my current coins?

The transition period will last 1,000,000 blocks (or about a year), during that time you will use a website to generate an address unique to you where you can send your old coins, and you’ll be able to specify your new wallet address to receive your new coins. If you do nothing, your coins will eventually be burned after the swap has concluded.

When the service sees that the funds were indeed sent on the v1 chain and enough confirmations have passed (TBD, but likely 120 blocks), the service will submit a transaction on the v2 network that will send you the proper number of v2 coins to the v2 wallet address you supply the site. As mentioned previously, the swap will be at a rate of 100,000:1 meaning for every 1,000 v1 TRTL you send in via the swap service, you will receive 0.01 v2 TRTL.

Yes, it’s really that simple. TurtlePay® makes this easy.

Q) Do I have to do anything with my wallet(s) right now?

Find your seed phrase, and write it down. The swap period won’t start until block 4,000,000 but when it happens you’ll want quick access to your coins, including any time to sync.

Sit tight for now and we’ll provide directions on how to interact with the swap service when it’s ready and the swap window is open.

Seriously, sit tight, keep your v1 wallet synced, and be ready when the announcement(s) for the swap go out.

Tip: If you absolutely want to be notified when the swap happens, go in the discord chat and type *news which should apply a role that gets a notification any time we post v2 updates.

Q) If I have 1,000,000 coins in v1, how many coins will I have in v2?

The swap will be at a rate of 100,000:1 meaning for every 1,000 v1 TRTL you send in via the swap service, you will receive 0.01 v2 TRTL.

1,000,000 / 100,000 = 10. You’ll have 10.00 coins in v2.

Q) Do I have to change to the GUI wallet?

Nope. The core suite software will always include a CLI software wallet implementation. Use of a GUI wallet is optional and up to you.

Q) I used to mine TRTL but now I cannot open my wallet. Did I miss the upgrade to v2?

No, you didn’t miss the upgrade to v2, but you very likely missed numerous releases upon the way to v1.0.0.

You’re going to need to grab yourself a copy of v0.28.3 and upgrade your wallet to the latest format.

Then you can open your wallet with the latest release and proceed with syncing your wallet. Backup your keys while you’re at it as you’re going to need them.

Q) What will be the ticker for TurtleCoin® v2?

v2 will completely replace the v1 chain and v1 will be retired. The ticker will remain TRTL.

Q) Are you going to get TRTL listed on more/bigger exchanges?

As developers, we focus on code and the reliability of the network. If the community finds an exchange that wants to list us, we are happy to assist them with engineering-level questions they may have about implementing TRTL, but other than that, we don’t go endorsing exchanges, engaging in partnerships, or paying for listings.

Q) I have v1 coins on “X” exchange and they are down for maintenance – can you advise when this will be fixed?

Ask that exchange why they haven’t jumped in the chat through matrix or discord and asked for help. We are happy to help with engineering questions, always.

As always, please remember, if your coins aren’t in a wallet with keys you control, they’re not your coins. This will be even more important as staking begins on the network, as you’d be forfeiting any ability to stake your own coins or get the benefits from doing so.

Q) Should I buy v1 coins before the swap?

Buy comfy sweatpants, ice cream, and maybe some whiteclaw. That’s the best advice we can give.

We aren’t investment advisors nor do we play one on the Internet. We can’t give you investment advice and never will. Your best bet is to do your own research, make your own decisions, and consult with a financial advisor on any financial decisions you may make.

Q) What are you doing about marketing efforts?

While we’re trying to be more active on social media platforms like Twitter, Reddit, and countless other mediums but it’s largely a volunteer driven effort with it’s focus on getting the word out about v2. If you’ve got an idea join the discussion and maybe others will help you drive an effort.

Keep in mind that we’re developers that are allergic to suits, PowerPoint presentations, and sunlight so our social skills aren’t aligned with marketing.

Q) Don’t remove PoW for the love of god.

Mistakes were made and we are fixing those mistakes by removing PoW from the mining of blocks. Also, that wasn’t a question.

Q) What is it good for? What is it’s utility?

TurtleCoin aims to be a fun, fast, and easy way to send funds between family, friends, and organizations. That’s the primary driving force behind the project – beyond that, it’s basically a choose your own adventure story. What do you want to use TurtleCoin for?

Categories
Feature Story

Ring Signature Performance Metrics

I wrote a bit about the differences in the resulting signature/proof sizes in the last article I posted (Bulletproofs+, Arcturus, Pruning, Massive Ring Sizes, Oh My!) and briefly mentioned some of the performance information for each of those methods. While signature size is important to the overall storage growth of the chain, verification time of those signatures (proofs) is very important to how quickly transactions are relayed throughout the network before being added to a block.

In this article, I’ll take you through the differences in the generation/proving time and the verification times of each of the signing schemes in a bit more detail and how these methods effect the different ways we interact with the blockchain.

Signature Generation

Every user initiated transaction on the network requires a signature that cryptographically proves that you have the knowledge of the private key that generates that signature. The signature is generated just once using that private key and is done (in most cases) only when you are sending a transaction. This work is performed on your device whether it is a PC, mobile phone, or otherwise. How long it takes to construct the signature is of no concern to the network as the network does not sign your transactions, You do.

While we don’t want signature generation to take forever as it negatively impacts the user experience as the time increases — the speed of signature generation is not a large determining factor when selecting a signing scheme.

Signature Verification

What we are very concerned with is signature verification time. This is due to the fact that unlike generating a signature, every node participating in network consensus must verify that a signature is valid (producers/validators).

Checking that signature occurs not once per transaction but twice at minimum:

  • It checks that a signature is valid as the transaction enters its memory pool to ensure that we are not injecting invalid transactions into that pool.
  • Transaction signatures are also checked as they are added to blocks for exactly the same reason.

Each transaction in the memory pool requires multiple iterations of the verification routine. Including transactions in a block has the same requirement. That means that to keep things moving quickly, we need the verification routine to take as little time as possible. Doing so allows the transactions to enter the memory pool faster, propagate across the network faster, and ultimately be committed to a block faster.

In the v1 blockchain, those signatures must also be verified during the node syncing process and only those already included in checkpoints are skipped. This is why syncing a node is slow.

We plan to mitigate this problem via the pruning mechanism that was mentioned in the last article which will allow for skipping this process while syncing a node.

It is also important to note that syncing your wallet does not require that signatures are verified. After all, a wallet does not maintain network consensus and maintain the chain, a node does.

Signature Generation Times

Let’s take a look at the signature generation times of the current v2 implementations of the ring signature signing schemes: Borromean, CLSAG (w/ commitments), and Arcturus.

The y-axis depicts the time in milliseconds (ms) and the x-axis depicts the number of ring participants. As a reminder, there’s 1,000ms in a second.

Note: These results were generated using an AMD 1950X, on Windows 10, using mingw-gcc-8. Actual performance results will vary by CPU, OS, compiler, etc.

But… but… but… you said CLSAG was faster than Borromean. You’re right, I did and that does hold true when the code is optimized; however, I didn’t optimize the hell out of the CLSAG implementation in the v2 crypto library because…

While CLSAG and Borromean generation times stay relatively steady — the Arcturus generation time climbs pretty quickly as the ring size explodes. This may seem concerning; however, as discussed in the previous article the benefit of this is that the signatures are significantly smaller at those massive ring sizes. In addition, we’re forgetting something very important here:

With Borromean & CLSAG sag, we have to have a separate signature for each input of a transactions. The same does not hold true for Arcturus which allows us to prove the knowledge of multiple keys in the same signature.

So, let’s graph those same values again assuming we have eight (8) inputs in our transaction.

Now that looks like a comparison that makes a bit more sense.

Here we can see that at the largest ring sizes, Arcturus generation time is, in essence on par with CLSAG generation times. Also, as expected, Borromean Ring Signatures are still faster at those ring sizes; however, as you may recall, Borromean Ring Signatures are significantly larger.

The clear winner in this case considering the resulting signature size is clearly Arcturus.

Signature Verification Times

Now that we’ve taken a quick look at the generation times, let’s wander on over to the verification side of the fence. After all, it’s a very important side of the fence, probably the best side of the fence ever, and no one will ever make their side of the fence look like our side of the fence…

Less time is better and the gray line clearly won.

Using just one input in the transaction, Arcturus is the clear winner coming in at about 2x the speed of a Borromean Ring Signature verification and almost 4x the speed of the CLSAG verification.

Seriously though, I know my CLSAG implementation in the crypto library is unoptimized (for now) and I don’t need to remind myself with pretty graphs.

Bill Gates, 1986 – Founder at Microsoft

What’s that mean to a transaction with eight (8) inputs? Let’s take a look.

The proof is in the pudding as they say

The difference between the proving schemes is much more apparent with multiple inputs. Arcturus performance during verification of large rings doesn’t even break the one (1) second barrier until 8,192 ring participants. Meanwhile Borromean and CLSAG blow past the one (1) second mark at 512 and 256 ring participants respectively.

For the largest ring sizes measured, Arcturus is 13x faster than Borromean and 25x faster than CLSAG for the same ring size.

I’ve beat the literal crap out of CLSAG in this article. That wasn’t my intent. An optimized implementation performs far better than as shown here but Arcturus still eats CLSAG’s lunch.

And the Winner is…

Considering the sheer speed of Arcturus at larger ring sizes and the significant space savings, it’s clear that putting in the leg work to get a working implement of Arcturus in C++ was well worth the time.

Doing so allows us to investigate and use the large ring sizes (or bigger) mentioned in the previous article while knowing that in doing so we are not negatively impacting the performance of the blockchain as we continue to work towards v2.

Anyone else as elated as I am for v2? Good, you should be 🙂

Categories
Weekly Update

This Week In TurtleCoin (February 1, 2020)

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

TRTL2 Crypto Development Update

As you all know, we have been working hard on TRTL v2, which changes literally everything about how the network works. Normally in this business you cant have private, fast, and cheap all at once, but our own core developer IBMCD has been hard at working putting together code that does just that! In our latest update IBMCD details from a code and equations angle what all the new crypto fuss is about in TRTL2 and why it has people so excited – to put it real simple for you, TRTL2 is the most private, fastest, and most scalable network hitting the block this year, including some top-100 names you might know. Check out the article, let us know what you think in the chat!

TurtleCoin, My Problem Child

Not many folks know about this, but we have a #Bounties channel in the chat where you can do odd jobs and people pay you in TRTL. Recently I came across an article that someone was going to pay to have written about TurtleCoin, so I figured Id give it a shot and pick up a few coins for the ole tipjar. What I ended up writing about was a story about the early days of TRTL and some of the trials that we’ve been through since launch. It’s not Pulitzer material, but I give it a solid 3 out of 4 shells. 5 minute read, 10 mins for the mouthbreathers.

Maxed out our discord boosts!

Congrats to everyone who has boosted the server, we are now sitting tall at 32/30 Discord server boosts, which is pretty crazy. So what does this get us? Well! Im happy you ask – it gets us hundreds of emoji slots, 100mb filesize upload, awesome quality in the voice chat, and best of all, our own customized Discord invite URL for you to share with your friends https://discord.gg/turtlecoin

TRTL Social Engagement

It’s always good to reach out to other segments of the TRTL community. Here are some posts from this past week that could use some love. Drop in and say hello, and maybe we can do some outreach to spread the word!

TurtleCoin Instagram

Follow us on Instagram or your wallet will delete itself in your sleep tonight. https://www.instagram.com/_turtlecoin/

Moving Up!

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

  • NEWS role: smokey, czar, sparky, name, budflick and spacewrangler.
  • Service Operator role: Sanich Newpool.pw
  • DJ role: Daniel Leedan

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!

turtlecoin/turtlecoin-wallet-backend-js

turtlecoin/turtlecoin-mobile-wallet

turtlecoin/violetminer

TRTL Dev Afterhours

The afterhours section is a new column we are trying out that aggregates all of the links from #Dev_OffTopic for the week so we can share them with you guys.

Eternal Terminal SSH on the go.
https://eternalterminal.dev/
Submitted by Crappyrules on Sun, 03 Jan 2021 01:42:37 GMT
SDF Public Access UNIX System – Free Shell Account and Shell Access
https://sdf.org/?tutorials/VPS_Plan9#bootcamp
Submitted by RockSteady (TRTL) on Sun, 03 Jan 2021 18:34:22 GMT
NixOS – NixOS Linux
https://nixos.org/
Submitted by RockSteady (TRTL) on Mon, 04 Jan 2021 17:03:11 GMT
GitHub – mit-plv/fiat-crypto: Cryptographic Primitive Code Generation by Fiat
Cryptographic Primitive Code Generation by Fiat. Contribute to mit-plv/fiat-crypto development by creating an account on GitHub.

https://github.com/mit-plv/fiat-crypto
Submitted by RockSteady (TRTL) on Mon, 04 Jan 2021 19:29:02 GMT
An Incomplete Guide to Rollups
https://vitalik.ca/general/2021/01/05/rollup.html
Submitted by RockSteady (TRTL) on Tue, 05 Jan 2021 14:51:22 GMT
Learn Go in ~5mins. GitHub Gist: instantly share code, notes, and snippets.
https://gist.github.com/prologic/5f6afe9c1b98016ca278f4d507e65510
Submitted by RockSteady (TRTL) on Tue, 05 Jan 2021 16:40:12 GMT
Standard mDNS service on Windows – Stack Overflow
Does Windows (some modern flavour) have an mDNS server installed and/or running by default? If so then how does one tell it, preferably dynamically, to start/stop advertising a new service?
https://stackoverflow.com/questions/23624525/standard-mdns-service-on-windows
Submitted by iburnmycd on Thu, 07 Jan 2021 04:59:05 GMT
Samsung 64GB class 10 micro SD card not working with rpi – Raspberry Pi Forums
https://www.raspberrypi.org/forums/viewtopic.php?t=71152
Submitted by l33d4n on Thu, 07 Jan 2021 05:41:16 GMT
Upgrade (Swap) Your Raspberry Pi 3 to a Raspberry Pi 4 Using the Same SD Card
https://seven1m.sdf.org/tutorials/upgrade_raspberry_pi_3_to_4_with_same_sd_card.html
Submitted by iburnmycd on Thu, 07 Jan 2021 12:56:58 GMT
USB 2.0 to TTL UART 6PIN Module Serial Converter CP2104 STC PRGMR Replace CP2102 – – Amazon.com
https://www.amazon.com/Module-Serial-Converter-CP2104-Replace/dp/B01NAC6PFR
Submitted by LeoCuve on Fri, 08 Jan 2021 03:08:05 GMT
What Micro SD Card is Best for a Raspberry Pi 4? | Raspberry Pi | Maker Pro
Need a micro SD card for your Raspberry Pi 4? Here, we offer some suggestions around cost, speed, and storage amounts.
https://maker.pro/raspberry-pi/tutorial/what-micro-sd-card-is-best-for-a-raspberry-pi-4
Submitted by LeoCuve on Mon, 11 Jan 2021 11:32:52 GMT
Bash-Oneliner | A collection of handy Bash One-Liners and terminal tricks for data processing and Linux system maintenance.
A collection of handy Bash One-Liners and terminal tricks for data processing and Linux system maintenance.
https://onceupon.github.io/Bash-Oneliner/
Submitted by RockSteady (TRTL) on Mon, 11 Jan 2021 17:48:28 GMT
A Proposal for Adding Generics to Go – The Go Blog
Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.
https://blog.golang.org/generics-proposal
Submitted by rashedmyt on Wed, 13 Jan 2021 14:23:07 GMT
My Thoughts Go Here Home
https://krruzic.xyz
Submitted by madk on Wed, 13 Jan 2021 23:46:31 GMT
GitHub – krruzic/blog: My personal blog
My personal blog. Contribute to krruzic/blog development by creating an account on GitHub.
https://github.com/krruzic/blog
Submitted by madk on Thu, 14 Jan 2021 04:48:42 GMT
State of JS 2020
The annual survey about the latest trends in the JavaScript ecosystem.
https://2020.stateofjs.com/en-us/
Submitted by RockSteady (TRTL) on Sat, 16 Jan 2021 00:08:09 GMT
Why Zig When There is Already C++, D, and Rust?
Zig Programming Language
https://ziglang.org/learn/why_zig_rust_d_cpp/
Submitted by RockSteady (TRTL) on Sat, 16 Jan 2021 00:29:47 GMT
Learn Python – Full Course for Beginners [Tutorial] – YouTube
This course will give you a full introduction into all of the core concepts in python. Follow along with the videos and you’ll be a python programmer in no t…
https://youtu.be/rfscVS0vtbw
Submitted by l33d4n on Sun, 17 Jan 2021 07:59:08 GMT
Buy a Raspberry Pi Pico Raspberry Pi
The new, flexible $4 microcontroller board from Raspberry Pi
https://www.raspberrypi.org/products/raspberry-pi-pico/
Submitted by l33d4n on Thu, 21 Jan 2021 08:45:38 GMT

Categories
Feature Story

Bulletproofs+, Arcturus, Pruning, Massive Ring Sizes, Oh My!

For the people who only read the headlines:

TurtleCoin v2 is 23x more private than Monero. We win.

For the rest of you nerds who like details, keep reading..

Cryptographic Methods

At the heart of every blockchain project is the code that makes the magic happen. The fundamental math that handles the calculations required to handle our good friend Elliptic Curve Cryptography (“ECC”). ECC serves as the method for how private keys and public keys are generated, how those points on the graph are related, and how those points are manipulated (added, subtracted, multiplied, etc.). The ability to manipulate the points in a secure way provides us with the foundational building tools to build the vast majority of blockchain networks.

TurtleCoin® is no different. Today, v1 relies on a slight variation of ED25519 using Curve25519. The implementation differs from ED25519 which relies on SHA-512 (SHA-2) by instead utilizing a non standards compliant implementation of Keccak (aka SHA-3) in the form of cn_fast_hash as well as encoding private keys slightly different than as defined in the RFCs.

For the nerds in the crowd, the implementation is non standard due to a use of a slightly different padding.

Those of you that have worked to create various implementations of wallet software, address generators, etc. have undoubtedly came across this variation a few times and said to yourself “wtf” when you try to use a standard SHA-3 or ED25519 library in the language of your choice.

When CryptoNote gives you lemons, throw them out and make orange juice.

Out With The Old, In With The New

The new crypto core is still built on Curve25519; however, instead of using non-standard Keccak, we’re moving to the SHA-3 standard. Every construction whether it be key derivations, output creation & scanning, signature construction, view key generation, etc. has been moved over to better support the use of standard hashing libraries. It’s not a huge change, but it does make a difference. The result of this is that if you were to restore a v2 wallet using a wallet seed generated by v1 software, you will get two totally different wallet addresses.

To be abundantly clear, v1 and v2 keys, seeds, and wallets will not be interoperable.

In addition to that change, considerable work has been done to make using the primitives a lot easier in downstream code. The framing around the cryptographic foundations has been rewritten to make using, reading, and understanding how those primitives work as easy as possible while still maintaining as much performance as we can. The end result is a generally easy to understand and read implementation of the framework required to build a blockchain project.

Turning code that looks like this:

Into this:

This not only makes the code about 1,000x easier to read and understand but greatly reduces the entry barrier required to get in there and start working with things. It also makes it a lot easier to build more advanced constructs including some of the additions that have been baked into the new cryptographic core.

Rock said he wanted smaller transactions… “I’ll show him smaller transactions” – IBMCD

Reducing Transaction Size

As we have discussed in previous updates, one of the foundational issues that the network has had in the past is the explosive growth of the chain in terms of storage requirements. While dropping junk in TX_EXTRA has been a large driver of that growth, the vast majority of the storage is driven by the input signatures attached to each transaction input. Today, these signatures amount to 512bytes (0.5KB) per input with a ring size of 4. It doesn’t seem like much, but when some transactions have 10s or hundreds of inputs that 512 bytes explodes at a very linear rate.

While the bulk of a transaction is the signatures of those inputs, the need for working with certain denominations of coins or “pretty amounts” (ie. 1, 2, 3, 10, 20, 30, 100, 200, 1000, etc.) also contributes to the bulk of a transaction size. The use of pretty amounts is what drives the need for fusion transactions whereby all of the smaller denominations (“dust”) are traded in for larger denomination outputs that can be spent later. The requirement that denominations exist and are used results in more dust, more transactions, and a larger chain overall.

To combat this issue, we’re doing away with the requirement to transact in denominations and changing the ways in which signatures are constructed.

Masked Amounts

To get rid of the requirement to transact in certain denominations v2 will utilize masked amounts and rely on Pedersen Commitments to denote both input and output values of the coins that are transacted without ever revealing to a third-party the actual value of the coins.

Pedersen Commitments have been heavily used in other blockchain projects such as Monero (XMR). A side benefit to this method includes the increased privacy of the transactions on the network.

Pedersen commitments have a nifty property in that they can be added and subtracted from each other much like regular numbers can be added and subtracted from each other and arrive at the same result.

For example, assuming our commitment generator is C:

C(a + b) = C(a) + C(b)

The commitments do not reveal the actual values of a and b and an outside party has no clue what those values are.

This is very handy for ensuring that the tally of output commitments is equal to the tally of input commitments – or put simply, that a transaction is in balance.

Range Proofs

The primary issue with using Pedersen Commitments for transacting on a network are that it is possible to construct output commitments that overflow the number space that ultimately results in the rampant creation of new coins without the authorization to do so.

For a quick example, let’s assume that we have an unsigned 8-bit number space available. We know that if we overflow the maximum value of that space (255), that the number overflows and comes back around to end up where it doesn’t make sense. We also know negative values stuffed into that same space results in a value that underflows and arrives at a place that doesn’t make sense.

Let’s take a quick look at this in practice and how this can be exploited.

Note: The values are shown below for explanation purposes, in practice, they are hidden by their commitments.

i_1 = 4
i_2 = 40
i = 4 + 4

Then we construct two (or more) outputs to arrive at the same value:

o_1 = 100
o_2 = 200
o = 100 + 200

We can clearly see that 300 \ne 44 However; in 8-bit math, the number rolls over the top such that 100 + 200 = 44 resulting in the tally of inputs and outputs matching. If you’re following along, you can see that we just minted coins (256 to be exact) out of thin air. Not cool.

The same trickery can be performed using negative values as well (ie. -100 + -120 = 44) because of the number bounds that turn that into 156 + 112 = 300 which wraps around again such that 156 + 112 = 44. Definitely not cool.

This is where Zero Knowledge Range Proofs come in to save the day. They allow us to prove to a third-party (ie. the network) that the values contained in the output commitments of a transaction are within a certain range without revealing the values they represent. In our case, the range is defined as 0 to 2^{64} - 1 otherwise known as what can fit within an unsigned 64-bit number space.

To simplify this a bit, think of a Pedersen Commitment like a cardboard box. Everyone on the network uses the same sized box (64-bits) and can stuff whatever they want into the box and ship it around the network. A range proof provides a cryptographically secure proof that what’s in the box fits inside the box and isn’t pulling a Dr. Who on us.

Bulletproofs+

We will be using Bulletproofs+ (“BPs+”) for our Zero Knowledge Range Proof in v2. To prove to a third-party (the network) that the values of the commitments in our transactions are within the bounds specified.

You may have noticed that we skipped right over Bulletproofs (“BPs”) and instead went straight for Bulletproofs+. The constructions are relatively similar with the resulting difference being that the cryptographic proof of the values of our commitments are within the defined range are smaller in terms of byte size and verify just a little bit faster than Bulletproofs.

Another huge benefit of BPs or BPs+ is that a proof can be batched meaning that we can prove the values of multiple commitments all within a singular proof. Instead of submitting one proof for each output commitment, we are able to submit a single proof for all of the output commitments in a single transaction. This greatly reduces the amount of storage required to transmit and/or store the transaction while still maintaining masked amounts. This results in smaller transactions and thus lower transaction fees.

For the sake of testing and benchmarking the new cryptographic core contains implementations of both Bulletproofs and Bulletproofs+. We’ll be relying on BPs+ until something better comes along.

Signature Construction

Borromean Ring Signatures

Today, v1 uses Borroeman Ring Signatures and each input in a transaction contains such signature whose size is proportional to the ring size. As the size of the ring grows, the size of the ring signature for each input grows as mentioned above. The growth is linear to the number of ring participants which is detrimental to the size of transactions and thus drives up transaction fees.

In this case, an upward trend is a bad thing

Adding commitments into the mix only further slows things down and causes massive chain bloat. At a ring size of 256 participants, the signature size is 16,384 bytes or 16KB without including the signing of the commitments. Yikes!

So, what are our options if we want to increase ring size as part of the change to v2?

Concise Linkable Ring Signatures (CLSAG)

You may recognize CLSAG from a recent XMR upgrade performed in October 2020. CLSAG greatly reduces the size of the signature of each input supplied for a transaction. While it still grows at a linear rate it grows quite a bit slower. It’s also a bit faster in the construction and verification routines as opposed to Borromean.

It’s like Borromean but smaller… and still traveling in the wrong direction.

At a ring size of 256 participants, the signature size is considerably smaller in our construction coming in at 8,259 bytes or ~8KB including commitments which is a drastic reduction in storage space.

Cutting the size of the signatures in about half results in our transactions costing significantly less. Woot!

Can we do better? Can we crank this thing up to 11? You’re damn right we can.

Arcturus

Arcturus is the new hotness put together by the Monero Research Lab (“MRL”) that significantly reduces the size of a “ring signature” while ensuring the that tally of input and output commitments match. Not only that, but it also works to prove the commitments to zero for those commitments (ie. proving that you know the real values of those commitments). If that were not enough, it also permits multi-index proving such that it’s possible to combine all of the attestations that we know the values of the commitments as well as have the private ephemeral for each real input being spent into a single proof.

I’m taking a bit of liberty here in calling Arcturus a ring signature as it’s not so much a ring signature as it is a cryptographic proof; however it is functionally equivalent to a ring signature for our purposes and helps keep the information relatable.

Comparatively speaking, verification times are, at times, about twice (2x) as fast (or more) as a CLSAG verification of the same ring size.

The multi-index capabilities of Arcturus have massive benefits to v2. Instead of having a signature for each input in a transaction, we are able to combine all of the inputs into a single signature (proof). This means that as we include more inputs in a transaction the signature does not grow linearly anymore thus reducing transaction size resulting in even lower transaction fees.

The downside is that the construction (generation) time is considerably longer for large rings. That’s okay though as signatures/proofs are only constructed when you use your wallet to create a new transaction.

Well, well, well, ring size explosion with a slow growth rate? That’s what we need!

As you can see, the size of the ring no longer grows linearly with the size of the ring. At a ring size of 256 participants, the signature size comes in at a panty dropping 1,294 bytes in our implementation. This means that our signature is not only ~16% the size of a CLSAG signature but is also ~8% of the size of a Borromean signature. Couple that with the fact that we can now bake multiple spends inside a single signature (proof) and we’ve potentially cut up to 99% (depending on the number of inputs) of the signature bulk off a transaction sent on the network. HELL YES!

What’s this mean for users? Very, very, very, very low transaction fees!

The Code

You can find C++ code for all of these signing mechanisms as well as the range proofs in this article in the turtlecoin-crypto repo on the development branch. In addition to the C++ code, this repo also builds the Node Native C++ Addon Module, Javascript (ASM.js), and WASM targets for use in other downstream projects.

Kind of reminds us of the v1 chain, amirite?

A Smaller Chain He Said…

Now that we have cut down the size of transactions so that they are a fraction of their previous size, we got to thinking… how else can we cut down on the storage requirements of the v2 chain and cut down on chain sync time. As we all know syncing the chain on a node is by far the best way to find the time to learn a new hobby. It’s not fast – even with checkpoints – it takes a while.

After mulling it over a bit, the thought came to us that we don’t need to carry around our range proofs and transaction signatures indefinitely… that they are in fact… immediately and forever prunable. Notice we said immediately prunable as in we don’t need to wait for a certain number of blocks to pass before pruning the signatures and range proofs from the transactions. Nor do we need to make this optional for node operators – it just is. Transactions can be pruned as soon as they are committed to the chain (included in a block).

Nodes will keep transactions in an alternate mempool for a certain number of blocks, in the rare event that a re-organization event does occur, they will be able to pluck the full details of the transaction from that alternate mempool. Once enough blocks have passed, transactions in the alternate mempool can be purged.

You may be scratching your head and wondering what we’re thinking as that information has to be there to verify a transaction during the sync process… right? No, it doesn’t.

In a traditional PoW network, such information has to be maintained to ensure that the blockchain is valid from start to the tip of the chain – verifying every bit along the way. This method also allows for handling chain re-organization events which are common in blockchain networks.

We already use checkpoints to short-circuit many of the checks normally performed by providing a list of trusted hashes for prior blocks. Checkpoints allow us to bypass the need to verify everything in that range of blocks (including the transactions and their signatures/proofs) and saves a lot of time.

In the v2 PoS scenario, we vote to trust that the block producers and validators have verified the signatures and range proofs for each transaction in a block before throwing their stamp of approval on the block (via a signature). Once the producers and validators sign a block, it’s solid, it’s not going anywhere. It is “in stone” as they say and while a chain re-organization is possible, it’s very unlikely. If they don’t properly verify signatures and range proofs well… that’s where they get penalized.

Producers and validators that don’t do there job will be dealt with swiftly and with extreme prejudice.

What this allows us to do is to define the structure of our transactions differently. Whereas today transaction hashes (and thus the hashes included in blocks) are generally constructed based upon the hash of every byte of a transaction (prefix || signature || range_proof), TurtleCoin® v2 transaction hashes will be computed based upon the hash of (prefix || H(signature) || H(range_proof)).

By constructing our transactions in this way, we are able to keep the full transaction (including the full signature and range proof) in the pending transaction mempool so that producers and validators can verify the signatures and range proofs. When the transaction is committed to the chain (included in the block), we can instantly drop the full signature and range proof from the data and swap the hashes of those structures into their place for long term storage which drastically reduces the storage required to operate a node.

While a signature + range proof may require 1,938 bytes in the mempool, once committed to disk, that same signature and range proof will only require 64 bytes of storage. This results in a reduction in transaction storage requirements of over 96%. Combine this with the fact that we will no longer produce empty blocks and we might be able to keep the chain on a floppy disk for a while.

Pretty cool aeh?

Enhanced Privacy Features

If you’ve read through all that, you can see that the vast majority of the work for v2 has focused on reducing the chain size and making verifications faster to support making the chain faster to sync and allowing wallets to sync as fast as possible. This greatly improves the experience when working with the network which was on of the core goals for v2.

However, in focusing on improving the experience of using TurtleCoin® we picked up numerous privacy enhancements along the way. What we have in the oven now is something truly unique. The combination of enabling Amount Masking and Arcturus allow us to provide 100% privacy with ring sizes far larger (and thus much harder to trace) than other projects – all coupled together with PoS.

While we test, benchmark, and debate whether 256, 512, 1,024, or larger ring sizes make the most sense for the network, we know that any of those ring sizes far exceed the ring sizes used by other projects (including XMR) and provide people with a network that they can securely and easily transact on. Throw in the fact that the relaunch allows us to enable the use of massive ring sizes starting with block 0, the privacy offered by TurtleCoin® v2 will exceed that of practically every other privacy project out there.

No tainted outputs, no legacy spends, no small traceable rings, no messy output migrations. Just secure, confidential, and highly anonymized transactions on a small lightweight chain.

What’s Next?

Now that we have the core cryptography out of the way we can direct our focus back to finalizing block and transaction structures (90% complete) then start work on building up the blockchain storage subsystem, building the staking system, and wiring up the rest of the network node. From there, we’ll work on building out the new CLI wallet that will be designed from the ground up.

We hope you’re as excited as we are as we continue to build the next generation of the TurtleCoin® network from scratch using the latest and greatest technology available.

Categories
Feature Story

TurtleCoin, My Problem Child

I recently came across a bounty in the TRTL Discord for an article about TurtleCoin. The requirements were loose, it was mainly just a length requirement, so I figured I’d brew up some coffee and give it a shot.

Thanks to Keda666 for reminding me to post this.

Starting a coin network is easy. Taking care of one, helping it grow, keeping it healthy, giving it good guidance – those are the hard parts. My name is RockSteady, and TurtleCoin is my problem child.

With an introduction like that, you might be thinking that I regret creating TurtleCoin or that it is a mistake in the sense that it was a failure, but quite the opposite as Bob Ross might say. TurtleCoin was created at the height of the crypto-boom of December 2017. At the time you could create literally anything, put “crypto” in the name, and sell it for millions, even if it didn’t exist (RIP BitConnect, never forget).

Out of the plethora of networks that were coming out, a little privacy category emerged. You had DASH and the masternode networks, you had Zcash with the optional privacy networks, then you had Bytecoin, Monero and the rest of the Cryptonote family with stealth addresses and fulltime privacy… and off standing in the corner, struggling for attention and trying to peer above the shoulders of the Cryptonote family is little TurtleCoin with a pizza stained shirt and light coating of Pabst Blue Ribbon.

As you may or may not know, TurtleCoin was a fork of Bytecoin. Incidentally, TurtleCoin and Monero for the first 3 years shared the same codebase, which came from an old retired version of Bytecoin. The way the privacy works in TurtleCoin and Monero is that if you think of every transaction as a handful of coins and dollars, each coin or dollar is matched up with a handful of others on the network and spent in a way that an observer can’t tell whose coins participated in the transaction, and nobody can scope out your transaction history or balance without being given keys to see it.

So, big deal, right? You fork some code, then change all the mentions to the old guys, throw in a little pizzaz, maybe some ninja turtle memes, and boom you’re off to the races, right? Shitcoin starter pack.

Unfortunately that is mostly true for some networks, at least to get the coin off the runway and into the sky. It takes almost zero work to fork code, change some variables and launch a network, but if the hundreds of projects people created based on our code are any indicator, it takes much much more than that to keep a network functioning and thriving.

Lets get to the problem child part.

A big reason why none of these forked networks exist anymore is that your network is like a little pot of gold, always out of reach, but for those smart enough you can find ways to make things easier as miner, or when all else fails, make things harder for everyone. Over the years, through the system of mining coins alone, we have seen it all with regards to the measures people will take to overcome the rules of the network to drive up their profit just a few points while having disastrous effects for the rest of us.

At times we have seen people forging timestamps for mined blocks, pulse mining the network to skew the difficulty enough so that many coins are produced in an hour, then when the difficulty climbs as a result, the miner leaves for another network with lower difficulty and leaves us to mine slow blocks for an hour before they return as the difficulty goes back to normal. Wash, rinse repeat. We even saw people so bold as to incorporate TurtleCoin as the payload of botnets, presumably to get more mining power.

Miners and their grubby little hands were the least of our troubles, along the way we noticed bugs that either got exploited and created a fire that we had to put out (like the fusion spam), or bugs that hadnt yet been exploited luckily (like the remote RPC bug). Sometimes when you fork code from others, this is the risk you take.

Maybe it is getting clearer why we don’t have as many TurtleCoin forks around anymore. If it isn’t so clear, here is an analogy – If you put a plane in the air, and stop refueling it, it will eventually touch the ground.

With all of these problems, TurtleCoin still prevails, and has not to this day had a single attack on the protocol that caused a loss of funds from any user, and with a pot of gold at the end of the rainbow as big as the remaining emission, nobody has exploited that either. (at the time of this writing, TurtleCoin still has 91% of the supply left to be mined)

Three years later, TurtleCoin still receives new code every day, new features, improvements, fixes – and still has users transacting despite the price being the lowest it has ever been in history. During these three years, as a team we have seen hundreds of networks spawn from the TurtleCoin code. These networks may have been other peoples hopes and dreams, Id imagine.

“Finally this will be the one” some of the forkers might say, before they sell off their entire premine and start the next project.

Today I can think of two networks that forked us that are still functioning, and of those two, when I think of how many receive software updates, Id have to say it is maybe one that is still actively developed.

As we round our way into the second era of TurtleCoin, the one where we scrap all code and write something new from scratch, I hope some of this funny business in the markets changes, and I do hope that all the forkers out there get their act together, however irrational they may be. TurtleCoin is our hopes and dreams, our pot of gold, our problem child. TurtleCoin is actively developed and every bit as serious of a project as others, it just has a funny name.

Accept no imitations, TurtleCoin is here to stay. When you think privacy, utility, and low cost transactions without showing the world your balance, think TurtleCoin. When you think about TurtleCoin, think about us, your captains, and a team that wont let you down no matter what the price.

Thanks for listening, I hope you all stick with us for TRTL v2.. its a game changer in the works. No more mining, even better privacy, everything new. Get some while you can, don’t say we didn’t warn you.

Categories
Feature Story

TurtleCoin­® v2 Overview

In the early days, at least two forevers ago, we blew the dust off a legacy Bytecoin codebase and launched a coin using just enough special sauce to call TurtleCoin our own, all on a whim. As a new network, there were the usual struggles, like when ASIC for CryptoNote emerged, or when we found a pretty serious RPC issue in Simplewallet.

As our team and their contributions grew, we eventually found ourselves in a new codebase, rock solid, but still carrying the scars of our past.

Fast forward to now, we are 3 million blocks wiser, our team is many lines of code more experienced, and as we have chiseled our way through, we made a list of a some areas where we can do better. Taking a step back, the last few years have shown us that we are reaching the limit of our current software, and the time is now for us to think radically different and put something new on the table. It is time to build something of our own.

With great respect and thanks to the CryptoNote family, Forknote, Bytecoin, and those who enabled us to get where we are now, we humbly begin our own path and embark on a new journey. What we produce next will be from scratch, written by us, exactly how we have always wanted it.

TurtleCoin v2 is the future, and we are excited to share it with you!

– RockSteady

The Goal

We aim to redesign TurtleCoin from the ground up to avoid the mistakes of the past while putting an eye to the future state of the network. This is accomplished by replacing traditional Proof of Work (PoW) based mechanisms with a round-based hybrid Proof of Stake (PoS)/PoW model. We’re going to be talking about some of the fundamentals required in this model so buckle your seat belt and be ready for a ride. Be warned, there’s a bit of math below.

Proof of Work

The traditional approach to cryptocurrency networks is to deploy a PoW model such that miners perform endless repetitive hashing of block data searching for a hash that meets a set difficulty. The miner is rewarded for burning fossil fuels via a specially constructed transaction (the “coinbase transaction”) that allows the miner to create new funds as a result of mining that block.

Proof of Stake

PoS deviates from the PoW consensus model in that PoW is typically no longer performed, instead passing the torch to block producers (the “producers”) whose work is then validated by the block validators (the “validators”). These parties are typically elected via users staking, or otherwise backing, their preferred candidates for those roles. Selection of producers and validators typically takes place via an election mechanism as part of the consensus rules.

Our Vision, Round Based Hybrid Delegated PoS w/ PoW

We are planning on combining the best of PoW with the stability and speed of PoS to create one kick ass network. We’ll use DPoS for managing the distributed ledger and PoW as part of the transaction construction and validation process.

Operational Overview

When a user wishes to send a transaction, they generate the transaction in the “normal” way. However, there is a nonce field included in the transaction that requires for the user to perform PoW for that singular transaction to meet a preset difficulty for transactions. The resulting transaction and the nonce is then forwarded to a node for broadcast to the network.

Every transaction will require a base amount of work (PoW) before it can be submitted to the network in addition to a fee-per-byte network transaction fee. However, if a user wishes to discount their transaction fee for a particular transaction on the network they may submit a PoW for the transaction that meets yet a higher tier of difficulty. While the discount tiers have yet to be defined, the maximum discount for the transaction fees will not exceed 50% of the fee-per-byte fee. There are no free rides.

Fusion transactions will no longer exist on the network. As a wise man once said, “ass, cash, or hash, no one rides for free”. Everyone pays their fair share for transacting on the network regardless of the reason for that transaction.

Once a transaction is received by a node, the node performs basic checks (i.e.. transaction construction, valid nonce, PoW meets required difficulty, verifies signatures, etc.). Once that node completes the basic verification, it forwards the transaction to the rest of the network including the producers. Producers hold the transactions in the global memory pool after performing their own validations of the transaction ensuring that it is indeed a valid transaction. At this point, users can presume some level of assurance that the transaction will be committed to a block solely because the producers have accepted the transaction into the pool.

Once enough PoW transactions have accumulated in the pool to satisfy the network difficulty, the then current producer creates a block that ratifies the selection of transactions necessary to meet (or exceed) the network difficulty requirement. When doing so, the producer creates a block reward equivalent to a 1 for 1 matching of the aggregate transaction fees included in the block.

This means that emission is directly tied to the actual use of the network as a transactional platform. We will no longer be emitting currency on a pre-defined schedule as a result of this change. The more the network is used, the more currency that will become available.

The block reward is distributed proportionately between the block producer, the validators, and a subset of the users who staked that producer. Upon completion of the block the block is signed by the producer and transmitted to the network.

The validators, upon receiving the block, validate (at minimum) that:

  • The producer was permitted to produce the block (their turn)
  • Enough PoW transactions have been included to meet network difficulty
  • Transaction hashes included in the block have been included such that the hashes are arranged in descending order
  • The block is properly signed by the producer
  • The transactions in the block meet all of the consensus rules of the network (no double spends, etc.); and
  • No unnecessary data is included in the block
  • That the producer claimed and paid out the proper block rewards.

A minimum of 51% of the validators must then sign the block and submit their signatures to the network thus ratifying the block itself.

After the block is ratified, the network difficulty is adjusted (if necessary) to account for things such as the number of transactions included, the PoW of transactions included, and any other metrics required to keep the network operating correctly.

No Empty Blocks Means Storage Saving Is Built In

One of the largest benefits in this scenario is that we no longer produce empty blocks and thus save tons of storage space. This makes the chain faster to sync, easier to store, and overall much easier to manage.

Tut, Tut: The Reward Lottery

Gone are the times when a single miner/pool received the entirety of a block’s reward. In this new model, the block reward is distributed to multiple recipients via the payments to the producer, a pseudo random validator, and a pseudo random subset of users who have staked the given producer and validator.

The Reward, Divided

We’re still playing with the numbers but there’s a pretty good chance that the block rewards will be divided as follows:

  • 20% to the producer of the block
  • 20% to the one of the validators of the block
  • 30% to the users who staked the producer
    • Maximum of 10 randomly selected stakers
  • 30% to the users who staked the validator
    • Maximum of 10 randomly selected stakers

Becoming a Block Producer / Validator

A user (“Alice”) wishing to operate a block producer or validator “announces” their intent for candidacy by staking their node(s) with a minimum stake of a yet to be determined amount of TRTL. Upon successfully staking their node, Alice’s node is now a candidate for either a producer or validator spot in a round. It is important to note that Alice simply staking her node as a candidate does not automatically make Alice a block producer or a validator.

To be a candidate for either role within the network, Alice must be “endorsed” by other users of the network via users staking their funds in support of Alice. Once Alice has at least 1 TRTL staking her, she is now a candidate in the running for a producer or validator spot.

The details of how these stakes are sent, recorded, recalled, etc. will be discussed in further articles and will undoubtedly involve a lot of math. Don’t worry, we’ll warn you ahead of time so that you can bring a protractor and a compass.

Electing Producers & Validators

Producers & Validators are elected for spans of blocks such that each producer is entrusted to create ten (10) new blocks in the round for which they are elected. How they are elected into these rounds takes place as follows.

In the event that a producer or validator fails to perform the work that was entrusted to them, their “trust” rating will fall for each block that they fail to producer and/or submit a validation result. If their trust rating falls below the lower threshold (TBD), the stake they put forth to submit their node as a candidate will be locked indefinitely (aka. burned).

First, we take the hashes of every block in the now closed round \{B_1, B_2, B_3, \dots\} and calculate the Merkle root for those hashes to establish M as the election seed for the next round.

We then take M and convert that to a scalar p:

p = H_s(M)

Then compute the public key P of p:

P = pG

We then tally T the individual bytes of S to determine if the result is odd or even.

T = \{S_1 + S_2 + \dots\} \mod 2

  • If T is odd (T \equiv 1) we collect public keys from the candidates list that are T \geq P.
  • If T is even (T \equiv 0), we collect public keys from the candidates list that are T \leq P.

Once the collection of public keys in the new defined range have been collected. We review the number of votes (stakes) received for each public key and construct a listing of candidates with their tally of active votes. The list is then sorted by vote count in ascending order and the top and bottom candidates in the results are discarded. The total votes submitted for the remaining candidates are then tallied to arrive at a total votes casted count (V).

The resulting candidates are then assigned ranges for which the selection algorithm must land for them to become a producer/validator.

If the remaining candidates consist of:

Candidate 1: 11,583 votes
Candidate 2: 25,749 votes
Candidate 3: 99,000 votes
Candidate 4: 127,342 votes

The the ranges for each node are as follows:

Candidate 1: 0 - 11583
Candidate 2: 11,584 - 25,749
Candidate 3: 25,750 - 99,000
Candidate 4: 99,001 - 127,342

We then perform the selection of the first producer via e_1 = p \mod V. The value of e_1 is compared against the node ranges thereby establishing that node as a producer.

On the next iteration of the election process, the previously selected node (e_n) is removed from the collection and V is recomputed before the selection algorithm runs again. Thereby guaranteeing that we do not elect the same producer/validator into more than one round slot.

The process is repeated until the required number of producers (more detail later) have been selected for the next round. At which point, the same process is performed for the candidates on the opposite side of P as T had dictated for producers until we have selected enough validators for the next round.

In the event that we are unable to select the necessary number of producers or validators from the pool of candidates as required for the round (i.e.. there are less candidates than there are required slots) the number of required producers/validators will be decreased until there are enough candidates to fulfill the request; however, at no point shall the number of producers and/or stakers for a round be an even number of spots.

There will always be a minimum of three (3) producers and/or validators required in a round. The number of required producers and/or validators for any given round will adjust dynamically (details to come later).

Pseudo Random Selection of Validator & Staker Selection for Block Rewards

When a block is produced, the producer must include relevants outputs to not only pay themselves but to also pay a deterministicially selected validator as well as stakers that staked the producer and that validator.

To select who receives the reward(s) we perform the same selection algorithm as we do for producers and validators with the exception that the prior block hash is used in place of the Merkle root for the previous round (M).

In the case of selecting which validator gets rewarded, the process is ran exactly once (1) for the set of validators for that round.

For determining the stakers to reward, the process is completed exactly ten (10) times for the set of stakers staking the winning producer/validator and the number of stakes the staker has submitted for the given candidate determine their “vote count”.

If, any time during the loop used in selecting stakers, the number of available stakers is exhausted (there are less than 10 stakers that backed that producer/validator), the process resumes as if all stakers are included in pool again and the iteration(s) continue until the necessary ten (10) stakers are identified for reward.

After completing the above, the producer then constructs a transaction for inclusion in the block that rewards the parties in the percentages necessary such that there are twenty-two (22) outputs in the miner transaction that is included in the block.

  • 1 for the producer
  • 1 for the selected validator
  • 1 each for the 10 stakers of producer
  • 1 each for the 10 stakers of validator

The entire process is designed with a sense of pseudo-randomness that can be recreated by every node on the network using the defined process. In essence, the whole reward structure is a bit of an election with an upper and lower house as well as a lottery for those that backed the elected producer/validator.

The Issues in a Nutshell

Relaunch

Problem: The current blockchain is very, very, very big, and growing every day whether transactions are included in blocks or not. There is also an insane amount of bloat in the chain including transactional spam (fusions anyone?), CantiPixels, and gobs of other useless data that is like walking around with cement shoes with two boat anchors tied chained to your ankles.

Solution: Relaunch the chain. Out with the old and in with the new. To facilitate this, we’re going to need to let the coins on the old network burn in a provable way to prevent errant inflation or other nefarious incidents. In addition, the old chain must be spun down in such a way that the chain officially ends at a certain block. Users need a way to transfer their funds from the old chain to the new chain and that means we’re going to need a…

Coin Swap

Problem: We have to efficiently move funds from the old chain to the new chain.

Solution: A coin swap window of opportunity. The coin swap window to the new chain will be 1,000,000 blocks (as measured by the old chain) during which time users will submit transactions on the old chain to a predetermined wallet address that will serve as a burn address whereby no one user can pick up the funds out of that address (this will be a multisig N:N wallet to make sure no one party controls it). An outside watcher server will watch for transactions on the old chain going to that wallet as instructed by the swap “service”, and release funds on the new chain to the address/keys provided by the user. The swap itself will be funded via a pre-mine on the new chain equivalent to the estimated circulating supply at the time of of the end of the old chain.

After the swap window completes, the remainder of pre-mine funds will be redistributed on chain.

Note: The redistribution of any unclaimed (whether through inaction or as “lost” wallets) via block rewards will be executed over a number of rounds on the new chain to attempt to ensure a somewhat even distribution of those funds to producers, validators, and stakers. Details on the exact schedule of distribution will come later as it will be highly dependent on how much TRTL will have to be dealt with.

In short, the swap mechanism will be a website that helps you transition from old coins to new coins. The technical mechanics of which will be discussed in later articles.

Wait… the chain is massive… we can’t just carry over everything from old to new we have to think about…

Swapping 107,198,508+ Outputs…

Problem: Swapping over 100M outputs to the new chain is… let’s put it simply, incredibly stupid. If we were to do that, yes, the new chain would not have the history of all of those outputs, but considering that we don’t know which outputs are still spendable, there is an unknown number of outputs that we have to create on the new chain as part of the swap process. That number is somewhere between 0 and 107,198,508 (as of the time of this writing). That’s just insane not only to think about but to also execute on.

Solution: During the relaunch of the network and required coin swap, we will be performing the equivalent of a 100,000:1 TRTL (or 10,000,000:100 atomic units) swap while maintaining two decimal places. Swaps of less than 1,000 TRTL will simply become dust and will not be swappable. Don’t worry though, the swap “service” will gladly take your unoptimized outputs and give you brand spanking new optimized outputs.

This swap ratio will eliminate the need to transfer more than ~81% (as of the time of this writing) of the outputs on the old chain thereby avoiding the pollution of the new chain with much of the problems that exist with the current chain.

A Note on Coin Swap Transaction Fees

The swap service will be set up such that as long as 100% of the funds in a transaction sent to the swap service are actually sent to the swap service (no change outputs) then all network transaction fees you pay to send those coins to the swap service will be included in the amount that you receive on the new chain. Furthermore, the swap service will have the ability to bypass the new chain transaction fee mechanics so that you receive the full value of your swapped funds at the ratio given (truncated to two decimals).

A Sustainable, Usage-Based Emission

Right now our blocks come out every 30 seconds, empty or not, and this keeps our emission at a steady pace toward the maximum of 1 Trillion TRTL some time over 100+ years from now. On the new network, there are no empty blocks, and block times won’t mean anything, so we cannot rely on that timing to release new coins into the supply.
Given that the converted supply is quite low (10 Million, two digits after decimal), and block time is now irregular, we have come up with a new way of keeping new coins entering into the system.
On TRTL v2, the network will match all base fees 1:1 with additional coins, making our emission tied to actual usage on chain. 10 Million would be a soft cap, and given enough usage to provide a demand for more coins, more coins will automatically become available via the fees produced by transaction volume.

Now What?

From here, we’re working at solidifying protocol level communications, working on designing the next generation p2p network itself, working on basic structures (transactions, blocks, etc.) and defining some of the inner workings of the actual consensus mechanisms that we’ll be introducing. We’ll provide additional details as they become available. Until then, keep chatting and don’t forget to let us know what you think at http://chat.turtlecoin.lol

Categories
Feature Story

TRTL v2

Have a seat, pour a cup of whatever drink you celebrate with, and think about where you left those old TRTL wallet keys. Whether you like what we say next or not, you’re going to need them, soon..

My friends, it is time for us to say goodbye.

Today we hit block 3,000,000. We upgraded our network and our proof of work algorithm for the last time. By block 4,000,000 or in about 1 year from today, the TurtleCoin network as we know it will begin on a path of its own destruction.

A short time after block 5 million, the chain will be dead, and completely gone, unable to produce more blocks.

Don’t panic, we have a plan. I said this would be celebrating 🙂

Sometimes you have to know when it is time to move on, and for us the time is now. Starting today we will be freezing the main core software repository. In the year that follows we will be writing code, documentation, and testing the new software we are already building for TRTL v2.

The next iteration of the software will work best with a blank slate to allow us to improve the network based on the things we learned in our current software. The main changes are:

  • Chain relaunch near December 2021
  • Coin swap w/ reverse split
  • Fair proof of stake
  • New core software

Let’s look into each one of those points and explain what is happening from a high level.

Chain Relaunch

Launching with a fresh chain on new software will enable us to be more flexible in the things we can make the new network do. If we have to operate with the constraints of backward compatibility, we will have to write a lot of code twice and basically build another version of what we have now, instead of something completely new.

Coin Swap w/ Split

Despite having a low emission atomically, our transactions average a large number of inputs. A lot of these smaller inputs now become smaller than the cost of handling them, so we call them “dust”. Think of how many handfuls of pennies you would need to pay for lunch.

To cut down on this dust, we will be reducing our supply by 100,000:1.

If you currently have 10,000,000.00 TRTL on the old chain, on the new chain you will have 100.00 TRTL. If you have 1,000,000.00 on the old chain, on the new chain you will have 10.00 TRTL. We will be keeping the 2 digits after the decimal point and will be keeping the TRTL ticker and wallet prefix.

The above examples of the coin swap amounts were updated after publication to reflect the proper swap math in atomic units.

IBMCD

The new total supply of TRTL will go from 1 Trillion (1,000,000,000,000.00 TRTL) to 10 Million (10,000,000.00 TRTL).

If you have <1,000.00 TRTL today, you will have 0.00 TRTL on the new chain.

The swap will be organized via a website that takes your new wallet address and helps move your coins to the v2 chain. When the swap is complete and the old TRTL chain is dead the old funds will be burned never to exist again.

Proof of Stake

We don’t have a fancy name for it yet, but we have designed a system that could kind of be compared to proof of stake, but it still has a little proof of work sprinkled on top.

TL;DR – There will be staking. There will be no more proof of work for mining.

We have developed an algorithm in-house that involves staking and uses a fair system for selecting block producers where whales have a hard time dominating production without significant cost. To cut down on spam and wasteful transactions, we are using proof of work to derive a proof of importance for each transaction, offering a user the option to compute more rounds of work to lower the fee, or pay a higher fee to send more rapid transactions.

The end result is a block chain that consumes less resources, is less centralized, and incentivizes good peers to stay online and provide good network throughput as we grow in volume. On the new network, there are no empty blocks, either.

New Core

We have already started specifying and building the new core protocols. It made sense to keep the modular approach of daemon+wallet, so starting with the daemon, we are writing it all from scratch. While this means we will no longer be a CryptoNote project, we will still have privacy the way we do now, and with the added bonus of not being a fork of anything, as that seems to bother some people.

Part of focusing all our efforts on the new core suite is to stop slapping duct tape on the old code base. From this point forward, there will be no new features, enhancements, or active development on the current repository. We will, however, review and address any critical issues and bug fixes that are required to keep the network in stable operation. In due time, you will find the current repository archived and read only once we are ready to nail the coffin closed via a consensus mechanism that brings the current chain to its final resting place.

We hope to be able to testnet the new network daemon soon, and I am sure we will need testers when we are ready, so if you have Discord, pop on by the TurtleCoin Discord and let us know so we can put you on a list of testers for when the time comes.

Until then, take care, we look forward to another 3 years with you all 🙂

TurtleCoin® Core Team

Categories
Feature Story

TurtleCoin v1.0.0 Upgrade

image

v1.0.0

Master Build Status

Build Status

Special Notes

Upgrade to this release is required

Network Upgrade at block 3,000,000

This release includes a mandatory network upgrade at block 3,000,000 that implements a change to the Proof of Work (PoW) algorithm for the network to Chukwa v2 (1 Thread, 1MB memory, 4 iterations). Pools, nodes, and services are required to upgrade to this new PoW to continue mining blocks at block 3,000,000 as blocks mined with the previous version of Chukwa will be rejected.

Daemon API Changes

The daemon API has changed significantly in this version. The vast majority of the API calls have been removed, migrated, or otherwise adjusted such that all services using such API require that you perform updates to your packages. The API calls have moved to a most RESTful approach and the endpoint routes have changed. Please see https://meta.turtlecoin.dev/proposals/daemon-api/ for information on what the new API looks like and update your packages accordingly.

Note: Please be mindful when updating your packages that the property names in the returned responses including their name, case, structure, and/or data type may have changed.

Client / Wallet Upgrades are Mandatory

The API changes indicated in the daemon require that you use the latest version of the core wallet software. If you use a wallet other than wallet-api or zedwallet++ that wallet software must be updated to support the new API. As such using older wallet software with public node(s) that have upgraded to this release will fail until your wallet software is upgraded.

End of Life (EOL) and End of Support (EOS) Notice

Please note that v0.28.3 was the last release to contain turtle-service. This release no longer contains the turtle-service binaries or source code and thus is no longer supported. You must convert to wallet-api to continue working with the network as it is the only service to be upgraded in conjunction with numerous daemon API changes. If you have not converted your wallet(s) and or services over to Proton, zedwallet, or wallet-api you are encouraged to do so now. Should you experience any issues working with wallet-api, please make sure that you open an issue so that the issue may be resolved as quickly as possible.

Legacy Wallet Support Removed

Support for legacy wallets (ie. those created with simplewallet and/or turtle-service) has been removed from the project. We highly suggest that you upgrade your wallet(s) using a prior version of the core suite via wallet-api or zedwallet++ or recreate your wallets from the recovery mnemonic or keys using zedwallet or wallet-api.

As always, make sure you have backed up your keys as that is the only foolproof way to restore your wallet in the event of an issue.

Release Notes

General Updates

  • Bump version to 1.0.0
  • Removed turtle-service
  • Removed NodeRpcProxy
  • Removed support for legacy wallet versions
  • Removed WalletUpgrader
  • Removed support for upgrading legacy wallets to new wallet format
  • Removed WalletGreen
  • Implemented consensus change at block 3,000,000 via major block v7 to Chukwa v2
  • Replaced all usage of nlohmann::json with rapidjson
  • Updated coverage of TX_EXTRA field parsing
  • Numerous CI/CD process changes in support of newer GH runners

TurtleCoind Updates

  • Required P2P minimum version bump to v11
  • Upgraded API endpoints to RESTful style calls (see. https://meta.turtlecoin.dev/proposals/daemon-api/).
  • Resolved a bug in the retrieval of headers such that the iterator was decrementing below 0 and thus trying to look for blocks that will not exist
  • Change the /indexes endpoint to be inclusive of the end height supplied
  • Added explorer property to the /info API call
  • Adjusted TX_EXTRA field ordering in block templates such that they are ordered by tag type (ascending)
  • Catch and handle segfaults when block is not found in some explorer methods

zedwallet++ Updates

  • Updated user expoded file path opening with error messages
  • Added --reset CLI flag
  • Added rewind to height CLI flag
  • Updated WalletBackend to rewind on subwallet import

wallet-api Updates

  • Updated WalletBackend to rewind on subwallet import
  • Added rewind endpoint (see documentation for more information)
  • Prevent the import of wallets that already exist in the wallet container
  • Update Regex matchers in API endpoints

miner Updates

  • Updated support for new daemon API
  • Updated support for Chukwa v2

cryptotest Updates

  • Inclusion of Chukwa v2 test hashes and verification

Known Issues

  • N/A

How To Sync Quickly

Visit the checkpoints how to use site for simple to follow directions on using checkpoints.

How To Compile

Please see the How To Compile section of the project README for instructions on how to compile this release on your system.

Changelog

See the TurtleCoin Release page for the full change history.

Thanks

Cryptonote Developers, Bytecoin Developers, Forknote Project, TurtleCoin Community

Categories
Weekly Update

This Week In TurtleCoin (September 16, 2020)

Wew it sure has been a while since the last update hasn’t it?

Geometric Hexagon GIF - Find & Share on GIPHY
Big Karai updates in this issue 🙂

Developer Updates

TurtleCoin 1.0 Is Ready!

As some of you who follow the dev pipeline may already know, we nerds on the TRTL core team have been busily working on bringing TurtleCoin into being a legitimate version 1.0.0 product. We are so excited to say that this goal has been a success!

To those of you outside of programming circles, what this means is that over time, through many planned efforts, we have rewritten and improved enough of the codebase that we are no longer the same TurtleCoin software that was initially released years ago.

This change is significant because we are doing away with a lot of legacy technology in favor of newer interfaces that make TRTL an easier network integration for commercial or professional use cases. Turtle Services is going away in favor of the newer Wallet API, so exchanges and web wallets will have newer integrations that are already in the pipeline and ready to try today, and also the daemon has lots of much needed improvements. In the old days of TRTL a daemon outright crashing in the middle of the day several times was normal, and we used to write software to manage those quirks- now it is almost unheard of that a daemon or wallet crashes without extreme circumstances.

What 1.0.0 means to you is more value from TurtleCoin as a product when you recommend it to people, and more technical potential for serious services to adopt our network for their products. These improvements to the software as a whole make us better equipped as a developer team to help them with their integrations and engineering questions. If you operate a service such as an exchange or e-commerce website that wants to integrate with TRTL, send your developers to us so we can answer their questions and help make it a pleasant transition.

Users: You still have time to upgrade, and as always, your TRTL isn’t going anywhere if you don’t upgrade, you will just need to update before you want to access them next time. As always, don’t forget to export your keys or seed phrase for safekeeping, and download the newest release when it becomes available from latest.turtlecoin.lol

Big thanks to IBMCD and Z who have put a considerable amount of time into core, and all of the helpers along the way who helped us get where we are today!

Rock

http://latest.turtlecoin.lol

https://i1.wp.com/user-images.githubusercontent.com/8020386/91375139-71a4b680-e84c-11ea-8503-7f3774678224.png?w=580&ssl=1
TurtleCoin® Open Issues Browser

TurtleCoin® Open Issues Browser

Keep track of all the open issues in one place.

@l33d4n

Code: https://github.com/turtlecoin/trtl-issues

Demo: https://turtlecoin.github.io/trtl-issues/

Karai Questions

A few questions come across quite a bit, and I always wish there were some sort of link I could toss into the chat as a diversion as I run away. Today we will fix that. Here are some common questions that I dont always have time to type out an eloquent answer for:

  • Q: What is Karai?
    A: Karai is a high volume network-agnostic off-chain scalability and communication layer for disparate networks.
    Longer Answer:
    Karai is high volume because when tuned correctly it can process over a million transactions per second.
    Karai is network-agnostic because although TRTL is natively baked in, Karai can be integrated with any other network such as ETH, BTC, XMR, etc.
    Karai is an off-chain scalability and communication layer in the same way that you would use Lightning Networks to bring more capacity for tracking events offchain on the BTC network, Karai can be used in a similar way to reduce overhead and fees by offloading event volume onto an off chain network without an extra token or cost. By this same concept, Karai can signal events on one or many networks simultaneously, which opens the door for possibilities like atomic transfers and other activities that transcend individual network borders.
  • What is Karai a fork of? Karai is written 100% from scratch, and is not a port or effigy of any other networks or products. Karai is written in Go on nights and weekends by one person under the critical stare of others.
  • What problem does Karai address? BTC and other networks that require fees for transactions and have a finite burst capacity for traffic, for example when CryptoKitties came around, ETH clogged up fast. Karai addresses this by moving traffic off the main network onto ephemeral side networks that can notarize their state on their main network for a fraction of the cost of operating all on chain.
  • What about smart contracts? Smart contracts require a perfectly tuned and executed programming environment inside of a box with tools we provide that may well shoot your eye out if you don’t build them just right, and often require yet another token to work. Karai doesn’t need another token, and it doesn’t force your code into a box full of holes.
  • Can Karai do ${BUZZWORD}? No.

Karai Tech Updates

There are almost too many things to update you guys on, so lets hit some short bullet points of the *recent* things that have gone into the pipeline:

  • Vultr evicted us from their platform, so be sure to give them a middle finger and 0 dollars for the trouble they have caused the next time you see them.
  • Two new stagenets have been added to replace the one that Vultr destroyed. You can now use the two networks to test your Karai applications. As always, uptime for both networks is listed on our uptime page at uptime.karai.io provided by the good folks at UptimeRobot.com
  • Icarus, or the unstable stagenet, is where the bleeding edge breaking changes happen. Code from the private Karai git gets deployed here. Currently this stagenet is operating fully dockerized with a DB backend that interfaces with Elastic Search, Postgres, Sqlite, MySQL, and others.
  • Daedalus, or the stable stagenet, is operating with in-memory data structures for holding its transactions. Daedalus has much less volume, but has a higher capacity of transactions per second, as it is 100% based in RAM, writing raw JSON to disk as needed for preventative measures.
  • Subgraphs are live on Icarus. Daedalus is still running in blockchain mode. What this means is that Karai has gone from operating like a blockchain to being a full directed acyclic graph similar to IOTA, Nano, and other DAG networks. When visualized, the transactions are no longer single file objects all in a straight line. Graphing a Karai network history ends up looking like a fractal of endless trees and branches. (see the picture above) This sounds like a bunch of magic but has been the biggest step forward by far for Karai.
  • Karai explorer is a new product from the hands of Daniel Leedan and ZoidbergZA. The explorer will be a way for users of Karai to check out the transactions flowing through their networks, and to help them examine the data in each tx if they desire. To give the most TRTL like experience possible, I have added a /stats endpoint to the Karai API that gives useful data about the network and coordinator, along with a /transactions and /transactions/txhash endpoint to give access to the full graph history as well as a specific lookup per transaction by tx hash similar to the way we do on TRTL now.
  • New interfaces Currently if you have a desktop or mobile application that you are writing, you can integrate with Karai using our Go and Javascript/Typescript libraries. The downside is if your app is written in something else besides Go and Javascript, like C# or Crystal, you would have to write your own connections by examining the Karai coordinator code yourself. We have had a few offers to port the libs to other languages when the overall API stabilizes, but as with most things we will be making plants to write our own libs if the need is there.
    What languages would you like a Karai lib for? Do you have the skills to implement the APIs in your language of choice? Drop a line in #dev_karai and let us know what you want to see.
  • Docker and Makefiles have brought some much needed streamlining to the dev process. If you have docker installed, you can launch a few containers and have Karai up in no time with just a few commands from our handy dandy makefiles. When I am launching Karai to test a development build I just type make karai and I am off to the races. Pretty cool for very little extra work.
  • Transaction metadata, as I have stated before, is the next step development-wise after subgraph construction. Subgraph construction is in a comfy state of done-ness. It works, however it is un-optimized, but still ready for use, so the next goal would be to add the metadata to the different parts of a subgraph.

    Let us review the parts of a graph real quick to get an idea of why we need metadata:

    The first transaction in a Karai graph is the root tx. Think of this like a genesis block, in TRTL terms. Karai has a strict definition for this transaction, a type 0 transaction, which only appears once in any graph.

    Immediately following the root tx is a metadata-only transaction called a Milestone. Its job is to set rules for how the subgraphs connected to it are constructed, like how sudden bursts of millions of transactions should be handled, as well as handling user data like public addresses of participating nodes that own transactions in a subgraph following a milestone. This allows for faster scan speed over traditional blockchains that must scan the entire chain from root to tip to find their own records.

    Each milestone has subgraphs as child graphs from that point. Each subgraph has a designated subgraph leader. The leader is determined by using the first transaction in a subgraph and appending an extra metadata field to it that contains data relevant to transactions in the rest of the subgraph. If your public key doesnt appear in that subgraph leader, you can skip syncing that subgraph if it doesnt mean anything to you.

    Subgraphs are created by starting a timer when the first transaction is created, and keeping a creation window open to gather transactions flowing in during the interval. When the timer finishes, the subgraph is closed and assembled in its final formation, and the metadata is written to the subgraph leader’s header data.

I think that is a good summary of the important parts, but as always I am leaving out a lot of context, details, and design decisions you might want to know more about. If you want to know more, direct yourself to the dev_karai room in the Discord.

Rock

https://github.com/karai

https://uptime.karai.io

Hey officer guys! Check out these really cool embroidered patches that Akupara made! They cost only 1M TRTL, which at todays prices are a steal of a price. Get yours today!
CONTACT AKUPARA IN DISCORD FOR MORE INFO

Meme Artistry

I saw a bunch of memes in the Discord by the user TUᴙTlɘᴙAiᴎ and immediately said that they must go into the roundup. I dont have a name for this column so Im just going to call it what it is, pure artistic skill. Big thanks to TUᴙTlɘᴙAiᴎ for these contributions!

Off Topic But Still Cool

This is something one of our TRTL devs made that is not necessarily TRTL related but still pretty damn cool! Check it out! It is a game programmed in the style of old Game Boy games https://skizot.itch.io/skydrop
Good job Skizot 🙂

Good First Issues

I used to pester the same person every week for these, but now we have a nifty explorer to check them out, look at it here! Thanks Daniel Leedan! Good First Issues are a good starting point for any beginner developer who wants to jump in and help out.

turtlecoin/turtlecoin-wallet-backend-js

turtlecoin/turtlecoin-mobile-wallet

turtlecoin/violetminer

Free Advertising

Free advertising for any TRTL related services and service providers!

Join the Pool With the Grassiest Roots In the Communityhttps://trtl.muxdux.com

TRTL Dev After Dark

This is a collection of the links that are pasted into dev_offtopic that we collect with a bot that ExtraHash wrote. Thanks!

DiceKeys | Crowd Supply
Security keys you create by rolling dice
https://www.crowdsupply.com/dicekeys/dicekeys
Submitted by iburnmycd on Sat, 22 Aug 2020 13:51:17 GMT
@adlrocha – Network Coding in P2P Networks – @adlrocha Weekly Newsletter
Linear combinations on-the-fly!
https://adlrocha.substack.com/p/adlrocha-network-coding-in-p2p-networks
Submitted by RockSteady (TRTL) on Mon, 24 Aug 2020 04:30:52 GMT
GitHub – jmoiron/sqlx: general purpose extensions to golang’s database/sql
general purpose extensions to golang’s database/sql – jmoiron/sqlx
https://github.com/jmoiron/sqlx
Submitted by RockSteady (TRTL) on Tue, 25 Aug 2020 02:17:01 GMT
There You Go Wow GIF by Kontrast Werk – Find & Share on GIPHY
Discover & share this Kontrast Werk GIF with everyone you know. GIPHY is how you search, share, discover, and create GIFs.
https://giphy.com/gifs/kontrast-werk-mindblown-lfaig-nh1-iD6CVE4PrSqhhHdyYR
Submitted by RockSteady (TRTL) on Tue, 25 Aug 2020 15:08:35 GMT
Arwes – Sci-Fi UI Framework
Futuristic Sci-Fi and Cyberpunk Graphical User Interface Framework for Web Apps
https://arwes.dev/
Submitted by RockSteady (TRTL) on Wed, 26 Aug 2020 15:09:18 GMT
TurtleCoin Open Issues
https://l33d4n.github.io/trtl-issues/
Submitted by l33d4n on Thu, 27 Aug 2020 02:04:42 GMT
https://github.com/turtlecoin/trtl-issues/invitations
Submitted by RockSteady (TRTL) on Thu, 27 Aug 2020 02:08:06 GMT
trtl-issues/repos.json at master l33d4n/trtl-issues GitHub
TurtleCoin Open Issues Browser v2020. Contribute to l33d4n/trtl-issues development by creating an account on GitHub.
Https://github.com/l33d4n/trtl-issues/blob/master/repos.json
Submitted by l33d4n on Thu, 27 Aug 2020 02:10:20 GMT
https://github.com/turtlecoin/trtl-issues/invitations
Submitted by l33d4n on Thu, 27 Aug 2020 02:12:43 GMT
GitHub – turtlecoin/trtl-issues: TurtleCoin Open Issues Browser v2020
TurtleCoin Open Issues Browser v2020. Contribute to turtlecoin/trtl-issues development by creating an account on GitHub.
https://github.com/turtlecoin/trtl-issues.git
Submitted by zpalmtree on Thu, 27 Aug 2020 02:14:17 GMT
Repositories – GitHub Docs
https://docs.github.com/en/rest/reference/repos#list-organization-repositories
Submitted by zpalmtree on Thu, 27 Aug 2020 02:16:49 GMT
https://api.github.com/orgs/turtlecoin/repos?sort=updated`
Submitted by zpalmtree on Thu, 27 Aug 2020 02:17:04 GMT
Repositories – GitHub Docs
https://docs.github.com/en/rest/reference/repos#list-organization-repositories
Submitted by l33d4n on Thu, 27 Aug 2020 02:20:06 GMT
trtl-issues/main.js at master l33d4n/trtl-issues GitHub
TurtleCoin Open Issues Browser v2020. Contribute to l33d4n/trtl-issues development by creating an account on GitHub.
https://github.com/l33d4n/trtl-issues/blob/master/dist/js/main.js#L102
Submitted by zpalmtree on Thu, 27 Aug 2020 02:22:51 GMT
https://media.discordapp.net/attachments/579918539830460417/662493503271731238/image1.gif
Submitted by zpalmtree on Thu, 27 Aug 2020 02:23:10 GMT
GitHub – turtlecoin/trtl-issues: TurtleCoin Open Issues Browser v2020
TurtleCoin Open Issues Browser v2020. Contribute to turtlecoin/trtl-issues development by creating an account on GitHub.
https://github.com/turtlecoin/trtl-issues
Submitted by RockSteady (TRTL) on Thu, 27 Aug 2020 02:25:35 GMT
Speed up loading with parallel api requests by zpalmtree Pull Request #1 turtlecoin/trtl-issues GitHub
Issues:

Spacing on issue labels and number of issues is broken. It seems like there was extra whitespace in the original version. Probably best fixed with some margins.
Scroll bar seems to not work

Note: I removed the spinner. It doesn’t seem needed when the page renders and starts loading issues near instantly.
https://github.com/turtlecoin/trtl-issues/pull/1
Submitted by l33d4n on Thu, 27 Aug 2020 05:09:59 GMT
https://api.github.com/orgs/turtlecoin/repos?sort=updated‘,
Submitted by zpalmtree on Thu, 27 Aug 2020 05:14:41 GMT
https://raw.githubusercontent.com/turtlecoin/trtl-issues/master/repos.json`
Submitted by zpalmtree on Fri, 28 Aug 2020 00:43:01 GMT
Back To The Future Biff Tanner GIF – Find & Share on GIPHY
Discover & share this Biff Tanner GIF with everyone you know. GIPHY is how you search, share, discover, and create GIFs.
https://giphy.com/gifs/reaction-65DcceNYwMBs1nGATv
Submitted by RockSteady (TRTL) on Fri, 28 Aug 2020 01:13:47 GMT
Will Smith IDid It GIF – WillSmith IDidIt Happy – Discover & Share GIFs
The perfect WillSmith IDidIt Happy Animated GIF for your conversation. Discover and Share the best GIFs on Tenor.
https://tenor.com/view/will-smith-i-did-it-happy-excited-omg-gif-8068878
Submitted by l33d4n on Fri, 28 Aug 2020 01:15:05 GMT
https://turtlecoin.github.io/trtl-issues/
Submitted by l33d4n on Fri, 28 Aug 2020 01:21:25 GMT
TurtleCoin Open Issues
https://turtlecoin.github.io/trtl-issues/
Submitted by l33d4n on Fri, 28 Aug 2020 01:31:30 GMT
Make loading ordered by zpalmtree Pull Request #2 turtlecoin/trtl-issues GitHub
Slightly slows down initial paint
https://github.com/turtlecoin/trtl-issues/pull/2
Submitted by zpalmtree on Fri, 28 Aug 2020 01:34:15 GMT
How to Install Android OS to Run Favourite Games and Applications in Linux
Android is a project which aims to port the Android system to Intel x86 processors to let users install it easily on Linux, Windows systems, or using Virtualbox.
https://www.tecmint.com/install-android-in-linux/
Submitted by iburnmycd on Fri, 28 Aug 2020 13:11:24 GMT
The A.R.M. Terminal – a Cyberdeck for your desk BACK7.CO
My concept for this project has been pretty clear since the original idea. I love the movie The Matrix, and I often wonder about many movies like it if they had included 3D printing or other newer tech in their universe. I loved the look and idea of a floating terminal, and many of us already have
https://back7.co/home/arm-terminal
Submitted by RockSteady (TRTL) on Fri, 28 Aug 2020 14:13:22 GMT
GitHub – turtlecoin/trtl-issues: TurtleCoin Open Issues Browser v2020
TurtleCoin Open Issues Browser v2020. Contribute to turtlecoin/trtl-issues development by creating an account on GitHub.
https://github.com/turtlecoin/trtl-issues
Submitted by RockSteady (TRTL) on Sun, 30 Aug 2020 00:23:12 GMT
Breast Cancer Love GIF by Mighty Oak – Find & Share on GIPHY
Discover & share this Mighty Oak GIF with everyone you know. GIPHY is how you search, share, discover, and create GIFs.
https://giphy.com/gifs/love-halloween-pink-l378p60yRSCeVoyAM
Submitted by RockSteady (TRTL) on Sun, 30 Aug 2020 01:25:07 GMT
Aluminum Monitor Stand USB 3.0 Hub ports with fast charge Metal Riser Support Transfer Data and Charging,Keyboard|Laptop Stand| – AliExpress
Cheap Laptop Stand, Buy Quality Automobiles & Motorcycles Directly from China Suppliers:Aluminum Monitor Stand USB 3.0 Hub ports with fast charge Metal Riser Support Transfer Data and Charging,Keyboard
Enjoy Free Shipping Worldwide! Limited Time SaleEasy Return.
https://www.aliexpress.com/item/4000744985776.html
Submitted by l33d4n on Wed, 02 Sep 2020 08:06:28 GMT
https://www.amazon.com/Charging-Station-Organizer-Compatible-Smartphones/dp/B07ZNDQYKS
Submitted by iburnmycd on Wed, 02 Sep 2020 12:49:24 GMT
BitTorrent v2
https://blog.libtorrent.org/2020/09/bittorrent-v2/
Submitted by RockSteady (TRTL) on Mon, 07 Sep 2020 20:17:16 GMT
Shopping Cart – VirMach
https://billing.virmach.com/cart.php
Submitted by Crappyrules on Tue, 08 Sep 2020 13:20:54 GMT
52Pi Rack Tower 4 Layer Acrylic Cluster Case Large Cooling Fan LED RGB Light for Raspberry Pi 4 B / 3 B + / 3 B / Jetson Nano|Demo Board Accessories| – AliExpress
Cheap Demo Board Accessories, Buy Quality Computer & Office Directly from China Suppliers:52Pi Rack Tower 4 Layer Acrylic Cluster Case Large Cooling Fan LED RGB Light for Raspberry Pi 4 B / 3 B + / 3 B / Jetson Nano
Enjoy Free Shipping Worldwide! Limited Time SaleEasy Return.
https://www.aliexpress.com/item/4000576747782.html
Submitted by l33d4n on Sun, 13 Sep 2020 15:16:07 GMT
v/docs.md at master vlang/v GitHub
Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. https://vlang.io – vlang/v
https://github.com/vlang/v/blob/master/doc/docs.md
Submitted by RockSteady (TRTL) on Tue, 15 Sep 2020 15:44:32 GMT
https://comodosslstore.com/blog/what-is-ssl-tls-client-authentication-how-does-it-work.html
Submitted by iburnmycd on Wed, 16 Sep 2020 02:58:14 GMT
Funny memes by Angel McDaniel on Circle game | Memes ...
you looked.
Categories
Weekly Update

This Week In TurtleCoin (August 19, 2020)

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

TurtleCoin Block Explorer v2020

New TurtleCoin block explorer: Beautifully designed, fully responsive and super customizable.

@l33d4n

https://l33d4n.github.io/trtl-explorer/

https://explorer.turtlecoin.lol

Boredom Killer #62

Today, for the fun of it, I threw together a quick little easily-deployable P2P, end-to-end encrypted messaging service class, written in TypeScript, which leverages TurtleCoin-Utils + the knowledge I’ve gained from developing TurtleTips. This library lets you encrypt and pass along any arbitrary data string you like between peers – could be used for a chat client, for sharing confidential data between two parties, or passing along any other information you see fit. I may clean it up and release it as a standalone library, or I may hoard it with the rest of my boredom-killing projects, only time will tell. (Insert :t_devilish: emoji.)

Canti

node-cryptonote-utils

Updated this package for major block 7 coming up at block 3,000,000 and added Typescript types.

I’ve been told that this package is still faster than the block template handling in utils for pool purposes, so challenge accepted.

IBMCD

https://github.com/turtlecoin/node-cryptonote-util

TurtleCoin-Crypto, TurtleCoin-Utils, & ledger-turtlecoin-app

Handful up updates published to NPM:

  • TurtleCoin-Crypto
    • Updated outdated dependencies
    • Separated all interfaces out into their own Typescript file
    • The user supplied crypto primitives must now adhere to the ICryptoConfig interface
    • Better user cryptographic primitive function handling
    • Node.js provided bindings via TypeScript or CommonJS are now async. This is a breaking change for many downstream packages.
    • Added support for configurable Chukwa v2 & and other Argon2id variants
    • Corrected issue with not including fe_invert.h in ` (thanks @rashedmyt)
    • Added support for FreeBSD (thanks @Izder456)
    • Switched from TSlint to ESlint
      Additional tests added” IBMCD
  • TurtleCoin-utils “Lots of work going on here prepping things for ledger integration. Next release will be published soon.
    • Abstract interface defined for LedgerNote And CryotoNote classes (which then makes their use interchangeable)
    • LedgerDevice class used to communicate with the app on the Ledger Nano devices
    • Incorporated the TurtleCoin-rpc-js package into the library (and kill the stand alone version)
    • Pretty much everything moved to async/await (promises)
    • Coin configuration abstracted our. Bye, bye config.json
    • Added support for the Pool Nonce tag
    • Added support for additional tx_extra tags for coinbase transactions
    • Lots of other updates
  • ledger-app-turtlecoin “- Added support for generating a transaction including full signing to the application on device.
    • Slightly better memory management
    • Few more helper and primitive methods exposed to the host application
    • More CI/CD automated testing

IBMCD
https://github.com/turtlecoin/turtlecoin-crypto
https://github.com/turtlecoin/turtlecoin-utils
https://github.com/turtlecoin/ledger-app-turtlecoin

For the last damn time- turtle-service is dead. Wallet-API is your new daddy.

Dale Earnhardt Jr.

Karai Updates

Recently Karai was wired up to get a steady stream of data flowing into Karai so that some of the data ingest methods and JSON serialization could be tested. To test these methods, Karai learned how to take in COVID19 data, Bitcoin price index data, as well as all of the trade activity of TradeOgre.com. This is pretty cool, and we even got JSON serialization half working, so that is a plus.

The current stagenet, Zeus, is happily chugging along pulling data and stuffing it into transactions that are smoothly being added to the graph.

Next on the horizon are fixing an issue where JSON is being encoded twice causing some forward slash escapes to riddle the nest data objects, and refactoring some of the functions in graph.go to make us a bit more well equipped to begin working on subgraph construction, which as you might remember is what gives karai its weblike appearance instead of a linear chain of transactions.

Also, Daniel_Leedan has been nice enough to start working on a Karai transaction browser template that is based on the design of the new TurtleCoin block explorer, so it should look pretty cool when it is done! I was somewhat pounding my head against the desk while not looking forward to building one so this was a weight off my shoulders. Thanks Daniel_Leedan!

Updates to the Karai website and documentation soon. I get so excited to write code that goes into the Karai core that I sometimes forget to keep the documentation and human side coming, so expect more updates to come!

Rock

https://github.com/karai

New Bounties!

250A bounty to help with the Turtle 2020 Website translation to pt-br.D4rkGh0st
45000 TRTLWe are offering a 45kTRTL bounty for the Russian translation of the website, it is just a few sentences so shouldn’t take much time, a quick win!@TurtleMax

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!

Free Advertising

This is a spot to spam anything TurtleCoin related that you would like to advertise, it’s free to put an ad in the roundup.

Join the Pool With the Grassiest Roots In the Communityhttps://trtl.muxdux.com

Shoutouts & Thanks

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

Join the Pool With the Grassiest Roots In the Communityhttps://trtl.muxdux.com

TRTL Dev Afterhours

The afterhours section is a new column we are trying out that aggregates all of the links from #Dev_OffTopic for the week so we can share them with you guys.

MrLahayeJust wanted to show to you guys my new home office. TRTL theme based.

https://imgur.com/a/gfZd4s1

Godspeed!
Take part in the Go development research from JetBrains : golang
118 votes, 12 comments. Hi Gophers! The JetBrains Market Research & Analytics team is currently holding interviews with Go developers that we would
https://www.reddit.com/r/golang/comments/i747w4/take_part_in_the_go_development_research_from/
Submitted by RockSteady (TRTL) on Tue, 11 Aug 2020 15:02:46 GMT
TurtleCoin Block Explorer
https://l33d4n.github.io/trtl-explorer/index.html
Submitted by l33d4n on Fri, 14 Aug 2020 05:33:31 GMT
Viewing English and Japanese subtitles at the same time
https://richardjharris.github.io/viewing-english-and-japanese-subtitles-at-the-same-time.html
Submitted by madk on Fri, 14 Aug 2020 19:02:15 GMT
Wallet RPC documentation | Monero – secure, private, untraceable
Monero, a digital currency that is secure, private, and untraceable

https://www.getmonero.org/resources/developer-guides/wallet-rpc.html
Submitted by Turtle Max on Fri, 14 Aug 2020 21:45:45 GMT
TurtleCoin Tips
https://turtlecoin.tips/
Submitted by zoidbergZA on Sat, 15 Aug 2020 14:47:57 GMT
CoinAPI Documentation
https://coinapi-docs.wrkz.work/
Submitted by pluton on Mon, 17 Aug 2020 01:17:06 GMT
Haskell mini-patterns handbook :: Kowainik
Kowainik Collection of small Haskell patterns with detailed description, examples and exercises
https://kowainik.github.io/posts/haskell-mini-patterns
Submitted by RockSteady (TRTL) on Wed, 19 Aug 2020 12:00:55 GMT
Oculus VR will require Facebook login to use devices
If existing users don’t want to merge their Oculus and Facebook accounts, they have until January 2023 to use it before support is cut off.
https://www.businessinsider.com/oculus-vr-users-log-into-facebook-2020-8
Submitted by RockSteady (TRTL) on Wed, 19 Aug 2020 12:25:26 GMT