Categories

## 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

## 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!

## 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 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 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 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

# v1.0.0

## 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

• Bump version to 1.0.0
• Removed turtle-service
• Removed NodeRpcProxy
• Removed support for legacy wallet versions
• 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

• 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

• 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

• Updated WalletBackend to rewind on subwallet import
• Prevent the import of wallets that already exist in the wallet container
• Update Regex matchers in API endpoints

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

• Inclusion of Chukwa v2 test hashes and verification

• 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

## This Week In TurtleCoin (September 16, 2020)

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

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

## TurtleCoin® Open Issues Browser

Keep track of all the open issues in one place.

@l33d4n

## 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.
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.

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

## 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 for any TRTL related services and service providers!

## 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!

Categories

## This Week In TurtleCoin (August 19, 2020)

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/

#### 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)
• Switched from TSlint to ESlint
• 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
• 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

Dale Earnhardt Jr.

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

## 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!

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.

## Shoutouts & Thanks

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

## 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.

Categories

## This Week In TurtleCoin (July 29, 2020)

This week we put the pedal to the metal and knocked out our biggest developer bounty we have ever had, in the name of TurtleCoin adoption and security of your coins! You are going to love it! Keep reading

Like the sound of bounties? Have skills? Visit our #bounties channel for your chance to get paid and earn a limited edition pink TurtleCoin Developer role in Discord @ chat.turtlecoin.lol

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.

#### Github tip bot

Recently I have been working on a tip bot for Github which allows users to tip each other by commenting on issues. It is triggered by a command that discord users will be familiar with to send a tip, for example:

If the receiving user doesn’t have a tips account yet, any tips sent to that user still get processed and are available to them when they create an account. To create an account a user simply has to sign in to the react web app with Github auth and they’re all set.

It is also possible to set an optional time-out for unclaimed tips(tips sent to users who have not activated an account yet), if an unclaimed tip expires, the original sender is refunded.

If you’d like to help test the bot ping me on discord 🙂

zoidbergZA

New Translations for TurtleCoin website!
Chinese, French and Turkish

Submit a translation in your language here: https://github.com/turtlecoin/turtlecoin.lol

#### TurtleCoin® Ledger Wallet

Over the last week I was able to get Ring Signatures working on the Ledger Nano S. After doing that, checking ring signatures was easy. I’ve also exposed a few other crypto fundamentals that are used in wallet management in the event that we absolutely have no other choice but to use the crypto functions on the device (it’s not a fast as a host device — the Nano S sports a < 100Mhz CPU). Needless to say, as you can see, this the application on the ledger is pretty much all but “done” (knowing full well that development is never done).

I’ve set up the CI/CD pipeline for the project with GitHub actions including Unit Tests against the Nano S emulator, making it very easy to tell when something isn’t working. I used the same test script but pointed at a real Ledger Nano S to create the video you see here.

There are a number of tools that I’m also building out for talking to the application when it’s running on the Ledger. See the rest of my updates for more 🙂

IBMCD

#### TurtleCoind® Crypto Library

Just rolled a new major version of the TurtleCoin crypto library v5.0.0. A few minor bug fixes are included but the biggest change is that the TS/CommonJS exports are all async now, which will pave the way for going down into the actual C++ code to make them asynchronous. As a bonus, the library now includes the code for Chukwa v2 as well as a few utility functions to make it easier to handle any other Argon2id variants.

IBMCD

## TurtleCoin® Utilities Library

With the recent changes to TurtleCoin-crypto going full async, there were a number of changes that had to take place in this library as well. Most of the updates taking place in the library are related to that and as soon as I’m 100% comfortable it’s ready, I’ll bundle up the release. This next release will also be a major version change as the async changes require a bit of tweaks to downstream code and thus broke the API expectations.

In addition, I’ve added a small export that provides the necessary functions to talk to a Ledger Hardware device running the TurtleCoin® Ledger Wallet application. You supply the transport mechanism (HID, USB, BLE, etc.) and the class does the rest. Every command supported by the application today can be handled via the class added to the library. Looking forward to start hooking it up to things wallets like Proton.

IBMCD

https://utils.turtlecoin.dev/

#### TurtleCoin® Block Explorer

Did a couple of small updates to the explorer over the weekend in preparation for the network upgrade at block v0.28.0. It’s subtle, and it’s not always there, but you’ll get it when you see it.

Also went through and updated the TurtleCoin® Utilities package deployed with the explorer as there’s some big things coming to the blockchain api that’ll open up a lot more data for the explorer.

IBMCD

https://explorer.turtlecoin.lol

## 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!

This Good First Issue comes from Zedwallet developer Zpalmtree who requests a brave dev newbie who can add two commands to Zedwallet. This GFI is cool because it gets you both a Developer and a Core Contributor role in the chat!

• list_fusions command for zedwallet
• rewind command for zedwallet, the same way as it is implemented in turtlecoin wallet backend js

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.

## Shoutouts & Thanks

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

## 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.

Categories

## This Week In TurtleCoin (July 21, 2020)

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.

## TurtleCoin® Ledger Application

Have a Ledger Nano S or X? Want to use it to keep your TRTL safe? Check out the video… clicky clicky.

I recently got my hands on a brand new Nano X and the first thing I did was beat it on ground and run over it with my car. After that, I gave it to the doggo and let him play with it for a bit. After all, if I’m going to store my hard earned TRTL on one of these things, I need to know that it will hold up to abuse.

After I got that testing out of the way, I got to work digging into what it takes to make this bad boy work with TurtleCoin. I admit, the Ledger SDK documentation made everything sound so easy to work through. Let me warn you, it’s not. Looking through headers and source files and trying to keep your head straight while you’re working in C, thinking through how to fit everything important in just 4KB of RAM, and other fun limitations, is not an easy task. In any event, I’ve made some awesome progress in the last 5 days. The Nano is now generating all the necessary keys, exporting public keys, exporting the private view key, and some other basic functionality. I’m still working on completing the necessary pieces and as we all know… slow and steady is the way.

IBMCD

#### TurtleCoin® V0.28 & V1

We’re happy to announce that v0.28.0 is shipping July 22, 2020. This release upgrades RocksDB to v6.10.2, resolves a few minor bugs that we’ve found along the way, introduces a new TX_EXTRA field just for the pool miner nonces (no pool changes required), and implements a consensus change that requires proof that coinbase (miner rewards) are properly claimed.

This is also the last release to include turtle-service which means that turtle-service is officially EOL with this release. EOS for turtle-service is scheduled for v1.0.0 which is currently planned to be out in time for block 3,000,000.

For those of you looking ahead to what v1.0.0 has to offer, we’ve got quite a few changes stacked up and ready. We’ll be introducing changes to the Proof of Work (PoW) algorithm to help secure the network. The daemon (node) API has been completely overhauled and moves to a more RESTful style implementation versus the json_rpc madness we have today. We’ve also nixed turtle-service, legacy WalletGreen support (this means if you haven’t upgraded your wallet to the new format used by wallet-api and zedwallet, you may want to back up your keys soon). We’re also working on a few other things that will make their way into v1.0.0 in all it’s glory.

The TurtleCoin Developers

https://github.com/turtlecoin/turtlecoin

#### Porting turtlecoin-crypto to FreeBSD

I ported the turtlecoin cryptography libs over to FreeBSD. They compile on FreeBSD now. Hopefully in the future we can get the turtlecoin-core compiling as well!

izder456

#### Turtle issues

Hebrew translation + issues on mobile when horizontal and slide on IPad (still open)

@Daniel_Leedan

#### RTL Support

Add RTL support to the TutleCoin website

@Daniel_Leedan

#### TurtlePay® Blockchain Collector

I’m overhauling this bad boy in preparation for v1.0.0 of the TurtleCoin® core software. It’ll store raw blocks, it’ll be faster, it will be stronger, it will be better. I’d say it’s going well but after a week of syncing progress, i’m at block 1.5M. I’ll let you know when it finishes, til then, I think I’ll be working on a few other things.

IBMCD

https://github.com/TurtlePay

#### TurtleTips

After talking with iburnmycd a few months back, I started coding up a little project as a bit of a proof-of-concept for a semi-centralized, non-custodial web wallet – a wallet where you control the spend keys, but a remote server does the hard work of syncing for you. Using this concept, an instance of this wallet, in theory, can sync up in a fraction of the time of conventional methods; as long as the backend is caught up with the network, all the frontend needs to do is play catch-up with whatever inputs and outputs the backend deems relevant.

Recently, I’ve started to rework and revamp my proof-of-concept into a fully-fledged chrome-based extension, with the added capability of being able to send tips to website owners who put their public tipping key up as a TXT record. At the moment, I am finalizing a few things on the front-end, which is basically done, then I’ll be moving onto the backend, where I just need to do a touch of code optimization.

Canti

## Moving Up!

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

Developer – Izder456 for his contributions to getting TRTL going on FreeBSD!

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.

## Shoutouts & Thanks

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

## 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.

Categories

## This Week In TurtleCoin (July 7, 2020)

This week we argued for a solid hour about the color of a single dot on a page nobody reads. Find out who was wrong about the color of that dot in this week’s issue of the Pulitzer Prize winning scholarly publication The TurtleCoin Weekly Roundup Article, July 7, 2020 Edition.

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.

#### node-turtlecoin-p2p

I took a small break from working with the Core suite this past week and circled back to a small Node.js (TypeScript) library I was working up a few months ago. I was able to clean a few things up and put just enough spit and shine on it to feel somewhat comfortable pushing the code up to GH. The end results, is a library that allows you to connect directly to the TurtleCoin® network using Node.js without the need for running a node (ie. the daemon; ie. TurtleCoind). Which may prove very useful for those that want to try their hand at building other things that interact directly with the network. If you’ve toyed with Node.js, feel free to give it a “go” yourself. The library is written in TypeScript but of course it transpiles just fine to CommonJS.

IBMCD

https://github.com/turtlecoin/node-turtlecoin-p2p

#### TurtleCoin Website Translations

As you may remember from a previous roundup article, there is a new web designer on the TurtleCoin development team by the name of Daniel_Leedan who is helping us out with a lot of our web based marketing code.

This week, we are working on translations. Daniel_Leedan and TurtleMax collaborated on the Hebrew translation of the web site, and Rock contributed the French translation. Some of these words might not have direct translations, so maybe some of you who might know Hebrew or French can help review the translations we did this week. We would greatly appreciate it if you guys check if your language is already translated by clicking the link below and looking for a file with your country code. If your language isn’t there, copy the en.yml file and use it as a template to add your own translations and we are happy to help with the rest! This is a great opportunity to get your pink TurtleCoin Contributor role in Discord 🙂

Thank you in advance to everyone helping now as well as for the previous round of translations. You guys are great!

https://github.com/turtlecoin/turtlecoin.lol/tree/master/_i18n

What is in a library? This week, I finished up the checklist for phase 1 of the Karai p2p protocol. This is great news because it paved the way for some other things I wanted to do. Lets summarize this week’s progress. This is still my after work and weekend project, so I didn’t hit every objective, but I got a good bit in.

• Connection process works 100%. Some of you might remember this diagram that IBMCD drew up and I was in charge of building. I got the whole thing wired up and now when a new user joins your channel, your coordinator node walks them through a simple handshake process that ends with an Ed25519 cryptographic access certificate being generated and added to an access control list.
• Access control works 100%. As a coordinator you now have a way to limit abusive peers with the ban system. I added a system where you can ban by public key, unban by public key, unban all, and list both the ban list and access list. The commands are documented in the client itself so just hit enter a few times when you fire it up in coordinator mode and you should see a list of the new options. It is an astonishingly simple system that just works by moving certs back and forth from a good folder to a blocked folder. Eventually I will probably build an automated temporary block for abusive peers where if you do not generate a cert immediately after joining 3 times, then your ip or public key gets added to the block list for an hour or so.
• Extrahash and RockSteady wrote some preliminary libraries to allow clients written in Javascript and Golang to connect to Karai channels with a few basic commands. Currently the libraries do not support sending transactions, that part is still not implemented far enough in the core client yet and needs to be refactored a bit before libs can support it. Anyway, check out the links below 🙂

#### libkarai-js

This is Extrahash’s project. It all has to do with this damn dot, you see.. So the library is technically written in Typescript, so Github identified that as Typescript and gave it a blue dot next to the project language designation. Being the guy with a keen eye to design, Daniel_Leedan made a pull request adding the button dot color to each library button on the Karai.io page. Knowing that the libkarai button should be yellow, I went to the github page to find that it was in fact TypeScript, so I changed the label on the button to say TypeScript.

The argument ensued was a waste of time, and I still don’t think we got to the bottom of it, but it looks like I am the only one writing the history of the incident this week, so for the record I am going to say I am right, and you are all wrong, and nah nah nah boo boo.

I will concede the point that Extra made which is that though the tool itself is written in TypeScript, the code it provides or ends up being used in is Javascript, hence the yellow logo I made above. I don’t know why that one is yellow and the dot on the button is blue and says TypeScript, but somehow this works in my mind.

RockSteady, Writer of History, Defender of Truth, Sole Victor, Undefeated, the 3rd

#### libkarai-go

libkarai-go being my personal project, as the author of Karai, you would think that this would be the squeaky cleanest example of a reference library that you ever did see..

You would think that, and of course you would be wrong. I will be the first to admit, I did not test this, however when I look at it and visualize it mentally, everything checks out and I am almost positive it compiles. I provide no guarantees that this code will not burn your entire house down.

This could all be just a ruse to Tom Sawyer you guys into doing the tests that I was too lazy to write, or it could be truly terrible code. Time will tell. The graphic looks sick though.

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.

## Shoutouts & Thanks

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

Big shoutout to IBMCD for helping me with the string conversion in the ed25519 library. youre a real lifesaver 😀 – rock

Thanks to Daniel_Leedan as always for tightening up our web presence! -rock

Thanks to TurtleMax for jumping in to help with the hebrew translation – rock

Welcome to all the new users who joined us this week 🙂 -rock

Shout to the devs, working hard 🙂 – Dreday000

Categories

## This Week In TurtleCoin (June 30, 2020)

This one is a bit of a long read, and some of you might have noticed we skipped last week.. We have big news this week for TurtleCoin, check it out!

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.

Boy oh boy were we busy this week. For those of you following along with the release notes you know that the next release of core is v0.28.0 due out in about a month or so. We’ve committed to make v0.28.0 the last release to include turtle-service. In celebration of moving away from that legacy service, we’ve begun work on the next greatest thing since sliced bread.

What could be better than sliced bread you say? What about a v1.0.0 release of the core software. Woah… a major version change you say? You’re damn right a major version change. We’re pulling out all the stops with this one. We’re introducing a PoW algorithm change (as Chukwa is quickly coming up on a year old) at block 3M, completely killing off support for turtle-service, and have overhauled the node (daemon) API to get rid of the ugly API calls (json_rpc is dead to us). We’ve replaced the API calls with a REST-like interface that is tons easier for developers to interact with. You’ll also see brand new docs coming out for it (something like https://meta.turtlecoin.dev/proposals/daemon-api/) that lays it out beautifully. In addition, we are also introducing a few consensus changes to help everyone keep their sanity.

We will be addressing numerous open issues, increasing performance, and numerous other small changes to improve the core suite. Stay tuned for more updates. Got an idea? Open an issue or hit us up in discord and we will see if it can make the list.

IBMCD

This week I got around to cleaning up a ton of warnings and errors that are generated when compiling with a newer compiler, such as clang 10 or GCC 10. This also included upgrading RocksDB to v6.10.2. Happy compiling!

zpalm

In preparation for the v1.0.0 release, I added a requirement for miners to include their public address in the blocks they mine. This helps easily detect network centralization by a single wallet, while still keeping the miner and his transactions anonymous.

zpalm

https://github.com/turtlecoin/turtlecoin/pull/1073

https://github.com/turtlecoin/turtlecoin

• We got a new contributor this week, Hai Turtle who has contributed a few bits here and there after recently learning Go, the language Karai is programmed in. Hai is a long time friend in TRTL land so it was a natural fit. Thanks Hai!
• We are getting dedicated fields in TurtleCoin for pointers and notary transactions. Before, we would encode the info and stick it in a payment ID, which just felt dirty for all parties involved. Since Wallet API is changing some, I will be changing the Karai client software to adjust accordingly with our fancy new transaction fields. This sounds like a bunch of fuss over nothing, but I guess a good analogy would be sharing a room with 32 of your siblings and then getting your own room. Terrible analogy but its a roundup, sue me. Nobody reads the Karai udpates anyway 🙂
• Progress Updates on connecting to channels: We can now somewhat connect to channels the proper way. There is a complicated key exchange and signing process that happens over a websocket between the channel coordinator and a joining node. The process we are working on is a means of establishing a cryptographic identity on the channel for the various peers before we go full P2P.
• Karai integrated with Matrix Chat: For the last few months or so, I have been using something called Matrix chat, which is like discord or IRC, except anyone can run a server and two or more people can federate their servers together, which spreads out the duty of tracking message history etc. When we arent using Matrix chat to have encrypted chats with the other members of the Illuminati, we are using it to pipe Karai channel messages into the Karai matrix server. This is kinda cool to watch, and currently bounces the data field from transactions in the Zeus staging network into a channel. From day two or so, random people connect sometimes and send test messages, which has been fun to watch.
• Zeus staging network has been moved to a different host. Moving to a new host always has its quirks, like in our case where the subtle differences in the server provisioning UI led to me deleting the Zeus staging network twice so far accidentally. That has been lovely, so sorry if that messed up anything any of you were working on. I will be setting up some type of uptime monitor dashboard for Zeus that is hosted on a different provider in case there is an outage at the datacenter level. I have a bad habit of updating the code and then not updating stagenet or updating stagenet and falling asleep before I turn it back on, so a red light green light website thing would be cool.

## Moving Up!

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

This week we got two new contributors that have been making waves in our little pond. Big thanks to both of you for your help!

• Daniel-Leedan gets the role of Developer and Karai Developer for submitting code updates to both projects. Over the past week he has added a few finishing touch improvements on our websites, and has been a pleasure to work with. His GIFs are always handy too! Way to go Daniel 🙂
• Hai Turtle gets the role of Karai Developer for helping me out with some scope issues I was having and for showing me a better way to accept conditional user input. Hai picked up Go fairly quickly and was able to submit a few updates to the Karai core code that really helped us out. Hai is a familiar face in TRTL circles, so it is always a pleasure to have him involved. Big thanks!

## 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 /violetminer
Disable GPU mining on setup – If a user has a lot of GPUs, but does not want to use them, it would be convenient for them to do this at first run.
https://github.com/turtlecoin/violetminer/issues/34

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.

Create a nice voucher with TipBot.
See sample for a link. Real action with Discord TipBot (ID: 474841349968101386)

## Shoutouts & Thanks

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

• https://caphillauto.zone CRITICAL SUPPORT FOR THE CAPITOL HILL AUTONOMOUS ZONE!
• Il Dvce 🐢 I shout @zerouanita that asked me for years my ragù (bolognaise sauce) and when i maked It for him he stopped reply me in DM

## 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.

Categories

## Why? Because it’s fun to do bad things.

For those of you who paid attention during the last roundup, we mentioned that some discussions were happening at the old sandwich cart about a few potential changes around the chat. Turns out we were discussing whether or not the time was right to give a shot at letting market talkers have their own channel in the server.

If you go to the chat right now, there is a room called turtle-traders. If you are surprised, so are we. Keep reading though..

## In the beginning…

When the TRTL discord first launched, it was during crypto December and what seemed like the entire world was in the chat talking about all topics under the sun. This had the positive effect of attracting a lot of otherwise unoccupied bright minds… along with a few shitheads, as can be expected with a sample size that large.

We hit 10k chatters almost instantly.

In our price history if you look back far enough when total emission was very low, and sell orders were very thin, we had an early investor who meant well end up purchasing and entire BTC worth of TRTL from the one exchange we were listed on at the time, which caused an instant spike to something in the low 30 Satoshi range.

We have been living that down ever since. Naturally that spike sent what I would say in hindsight are the wrong signals, and buyers poured into the chat with hands on hips, demanding ridiculous things of brand new devs who had just signed, clapping at the nerds while telling them to work harder for their investment and basically justify their commitment to their new crypto-tradegod overlords.

I do not remember how long this went on but we quickly lost a few great devs who were really pushing things forward at the time in interesting directions, because they didn’t sign on for that, they just wanted to be devs, and the rapidly declining price didn’t make that any easier. People I knew personally even left the project. Things were getting bad and something had to be done.

Right when things were coming to a tense crescendo between traders and devs, the SEC began alluding to pending legislation on cryptoasset networks like us, and to pre-emptively get our little Turtle nuts out of the fire, we made the decision to push the traders out of the chat.

It was not a difficult decision.

## The first market server

Naturally the traders had to go somewhere. We had two rooms named General in the main server and the lines of chat would move so fast you could not get a word across at all, just type something and send it into the fray while praying for the best. Needless to say there were a troupe of people who needed somewhere to go, and we were just sliding them out the door.

A developer contributor by the name of Madk stepped up and formed his own Discord, which was convenient since he was not closely linked to core at the time, and was not an American, so risk of being hassled by the SEC was very low for him.

I don’t remember exactly how long this server lasted but it filled up quick, and attracted all types. There were many friendships formed there, and a few horror stories as well.

Eventually Madk decided he wanted to take his mod hat off and unceremoniously nuked the server one night. There are a lot of details I am deliberately leaving out here, but you will just have to ask someone who was there to tell you if you are that interested.

Personally, it is my opinion that those who endured those years were better for it as a result, but I am also aware that my opinions aren’t always great.

The guys might say he was always this way, but I don’t think Madk was ever the same after that.

## The next market server

Again, being cast out of their native home land, a group of lads still claiming to be traders along with their pet bots were not ready to let the party die, so a new market server guy emerged from the crowd ready to lead the charge. His name was Buggles.

Buggles created the second market server for those of you around long enough to remember the switch. It was a natural fit and easy transition for many of the people there. Buggles had been part of the community for quite some time at this point, and everyone just moved over.

Ironically this market server did not have much trade discussion. It mainly consisted of the aforementioned lads doing lad things, and being nice, then over in the corner, a few people being berated by the ‘cool kids’ for their support of TRTL. There were accusations of us being a shitcoin, the name ToiletCoin gained popularity in some circles (Xaz still has the username TRTL = ToiletCoin` to this day in fact) and though the good times mostly outweighed the bad, that type of stuff is just bad for the image and morale of the users of the network and disrespects those who continue to contribute code and documentation to it. It wasn’t Buggles fault, these problems just seem to dog us since our early history, I don’t think it would be any different if we were another network.

Until that time we had always referred users to a read-only room called Market Talk in the main server where a direct link to whichever market server we were using at the time would be for easy access. It is not that we did not want people to ever talk market topics, we just wanted to keep the main server for support and development so it seemed natural to at least help folks find their way out of the server to keep market talk where it belonged.

As the price dipped further and people got worse and worse views and opinions of parts of our community, I kinda got tired of how users were treated by the traders and removed the link to the market server one day, a decision which even Alien our TurtleCoin CEO said was a good idea.

What followed, I would say, was just unworkable. Probably not my finest moment.

## How to kill a crypto discord

After removing the link to the 2nd market server, I was at wits end with having to explain to people who had just agreed while entering the server not to market talk and that yes it was indeed a serious rule, and it started to feel like a chore to exile people. We just want to write code, and all this market talk stuff was distracting us from that.

If you are not already shouting at me through the screen, I made a critical mistake at the time. I removed the link to an alternative market chat, giving traders nowhere to go. And even if they did get the link, the first impression would be poor when they arrived at the market server, and when they inevitably look for a place to talk shop in the main server, we would send them to the origami chain gang.

This was an unworkable solution obviously.

While everyone was being sent home for COVID and signing on to our discord, I was busy with a broom chasing them out of the chat for trying to blow off steam and shoot the shit with their friends about market stuff.

Soon, less and less people were chatting daily, and while it was the most productive time of my own time at TRTL, pushing code to what I felt was the most impactful project I had contributed to so far, I was frustrated that we were still sinking slowly. I felt like every day was treading water, but it was my own fault.

## Market talk & other things we never thought would happen in 2020

A few days went by when maybe only 20 people or so were active in the discord chat, and while these were some of our most productive and dedicated members, I could feel morale draining and just had one of those Fuck it moments.

Fuck it. What is the worst that happens?

I figured, you know, right now is the time when we need eyes on us.. There is no way we are putting all this work into a brand redesign for 2020, we finally have a stable core suite, we are working on completing Karai, one of our biggest milestones this year, and still trying to pump life and fresh memes into a dead discord all day and the chat was still dying.

I am not sure if a market discussion channel will breathe some life into a once very lively server, but we have never been a team to sit around doing the same shit that does not work, or even worse, doing nothing.

We are giving this a shot, we hope you guys make the most of it, and most of all, I hope this brings more adoption for TRTL and its users for 2020 and beyond. We still push code to multiple projects every day, and still see new faces, so while we give ourselves this second chance we hope you guys join us and shoot the shit in the new market room.

Have a good night 🙂