This week depending who we asked, you either got cooked alive in your apartment or floated away in the rain, nevertheless we still got work done 😀 here is this week’s update!
in this memetastic issue of the roundup, we make hay while the sun shines as other miners forget to upgrade for Chukwa!
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.
I think I need to listen the to the Kevin Rose TRTL podcast again – the only reason I really ended up in TurtleCoin in the first place is that of the core concept of a “network” with “applications” and “TRTL is just the currency one”. There was a bunch of other details that I liked as well technically, hence probably warrants a relisten.
Cause if we want “other” applications it seems like it mostly comes down to messaging. As in information needs to get around to the apps on everyone’s devices. Right now we have the daemon which then feeds wallets. The wallets keep balances by reading the messages in the blockchain. Blockchain works cause of PoW. Nice.
How do we get other applications then?
The current thinking is a smart contract platform, aka Karai, something like Ethereum – however, we’ve identified issues with it that we don’t want to adopt. So breaking down things to first principles any app we can think of is doable the traditional way (racks and go – racks is the catch-all phrase for anything that combines compute/storage), depending on what it is that can be expensive to maintain or difficult to launch in the amount of time needed to set up various parts. Racks are also susceptible to adversaries be they Governments or script kiddies. Thus the natural jump is to a peer-2-peer model, aka de-centralisation. Once Filecoin becomes a real thing storage via IPFS is handled, what isn’t handled is the compute side of things. Ethereum does it by being the compute, the daemon has a virtual machine that accepts scripts which when invoked produces results that are then committed to the blockchain and chicken dinners for all! As we can see they are having scaling issues and personally I don’t believe that is the best way to go about this in the first place. The thing is whatever is in the blockchain is never actually used as is, apps written to run client-side are also needed to interact with any of this data.
How about we simply augment the TurtleCoin blockchain to support the various kinds of messages needed to power these client-side devices? Maybe it needs Karai to help with that, not sure. Thinking about this it is difficult to define Karai as a smart contract platform like Ethereum as the only way you get Ethereum is if you do Ethereum and all that isn’t what I believe is actually needed to get to “TurtleCoin Network” powers distributed applications.
Having non-fungible-tokens is something that should exist. This trading card game is a practical example of how being able to say I own a thing and it is a unique thing, like printing out a piece of paper and it being unique, is useful. Keep in mind that representing physical items in the digital realm is different, yes someone could chop up a block of land into 1,000 pieces and say that whoever has those 1,000 digital tokens owns the land, but really the person whose name is on the land title at the local land titles registry is the landowner… Then the game actually takes place off-chain and requires a client. The rules are published and the smart contracts are in place and the tokens exist – with all of these components in place ANYONE can create a client to play this game or any other kind of application where those tokens fit. No one can actually take the tokens away from anyone cause blockchain. The tokens don’t rely on the game devs being around in the future, the tokens now exist, their value and significance is open source and committed to digital permanence as long as Ethereum exists, even then if Ethereum dies they can still be sucked up into a new thing as all of Ethereum up to the stop point exits…
This is a platform to handle identity verification without usernames/passwords by using PKI. In practice it works like this, the bank calls you and says “so give me all your personal details and I can verify I’m speaking with the correct person” and you’re like “dafuq? you’re not my bank, scammer!” and hang up.
Instead, the bank calls you and sends a signal on their side of the app conversation with some info they told you on the phone, you open your app and confirm you are you and the bank also sees the confirmation, you know you are talking to the bank and the bank knows they are talking to their customer, no more “so ahh give me all your details so I can steal your identity”. It works by sending messages and apps responding to those messages as needed. This is like our currency application. The difference here is 95% of the messages don’t need to be recorded as they are only useful for the moment they are read. Committing all these messages to a blockchain is really only useful for auditing purposes in the future to see what happened previously. Really dedicated apps can take care of that if needed. These messages are small however if the application was adopted by millions the message volume would explode the storage requirements of the network (~25KB/msg, 10k msg, 91GB/yr for ONE app…) and make it unsustainable. Thus it seems like some kind of ephemeral messaging ability is needed. See discussion in #dev_general for more on ephemeral messages.
These are my thoughts on what TurtleCoin network needs to help us address, non-fungible-tokens / ephemeral messages. Maybe Karai is our non-fungible-token platform and ephemeral messages go into TurtleCoind. Outright compute in a distributed VM, I don’t know about that maybe? an example would be great!
Well, when a coinbase transaction and a fusion transaction love each other very much…
Just kidding. Grab a drink, this is a long, and confusing read.
Lets start by looking at where the money for a transaction comes from in the first place. All money originates in the network from mining – which creates new coins, via a coinbase transaction.
A coinbase transaction is a special kind of transaction that is rewarded to the person who mines a block. The money ‘magically’ appears, and is not sent to the miner by anyone.
This might make you think that miners can print as much money as they want. However, the coinbase transaction cannot be more than the current ‘reward’ – if it is, the other pools and daemons will reject the block containing it. The current reward is calculated by looking at the emission curve, and the total amount of coins in the network.
Lets say Bob decides to do some solo mining, and gets lucky one day. Maybe he mined block 900,000.
Bob got 29,013.99 TRTL from mining this block. As you can see, this transaction has no inputs, because it is a coinbase transaction. The bit we’re interested in here are the outputs. Interestingly, Bob does not just receive a big chunk of 29,013.99 TRTL. Instead, he receives 6 outputs, of varying amounts, which add up to the full 29,013.99 TRTL.
Whenever a transaction is sent, it must be split into denominations. This is quite simple to do – it’s just splitting into units, such as thousands, hundreds, tens, etc.
The reason for this is due to how the mixin / privacy features work. When we form a transaction, we need to match the amounts we use with other ones other people have sent. If we didn’t split our outputs into these standardized amounts, we would need other people to have made transactions of exactly 29,013.99 TRTL before, which is pretty unlikely. Think of these standard amounts as building blocks to make any transaction amount.
So, Bob has got an amount of TRTL now, comprised of a few separate outputs. How does he spend them?
Finding which transaction outputs belong to us
First, Bob needs to work out if this transaction belongs to him. Since CryptoNote coins are private, we can’t tell what address a transaction was sent to without owning the private keys belonging to that address.
Now we’re going to have to get a bit nerdy and talk through some code. I’ll try and keep it simple. If you want to follow the code, check it out here.
Each transaction has a transaction public key which comes with it. We start by taking this public key, and our private view key, and performing some magic crypto operations, we can generate a key derivation.
Next, we loop through each output in the transaction, so in this case we’d start with the 0.09 TRTL output.
For each output in the transaction, we take our key derivation, the output index (This is simply the ordering of the outputs in the transaction), and the output key (That’s the long hex string which looks like a hash in the image)
We do some more magic crypto operations, and we get out a public spend key. This is the public spend key that the transaction was sent to.
If you weren’t aware, a TurtleCoin address (and any CryptoNote address, actually) is just a ‘nicer’ representation of the public spend key and the public view key.
For example, the address:
corresponds to the public spend key:
and the public view key:
So, we’ve got out the public spend key this transaction was sent to. What’s next? We just need to checkout if that public spend key is the same as the public spend key our wallet uses.
If it is the same as the public spend key our wallet uses, this transaction output belongs to us!
By the way – if the transaction doesn’t belong to us, we won’t get out the actual spend key the transaction was sent to – we’ll just get some meaningless garbage. So, your privacy is intact 😉
We then repeat this process for every output in the transaction. We can’t automatically assume because one output belongs to us, they all do. Remember, you can send a transaction to more than one person at once.
Once we’ve added up the outputs that belong to us, we’ve worked out how much we’ve been sent in this transaction. In Bob’s case, that’s 29,013.99 TRTL. Good work, Bob!
Storing the magic stuff which lets us send transactions
Bob’s got his wallet all synced. He wants to buy a TurtleCoin t-shirt from Alice. How does he send his money?
If we find that a transaction output belongs to us, we can then create a transaction input from that, using our private spend key. We can then spend those inputs, creating new outputs, for someone else to repeat the cycle with. A little bit confusing.
There are a few bits of information we need to store that comprise our new input. We need:
- The transaction public key – This is included in the transaction.
- The output index – This is the output index previously mentioned.
- The amount – We can take this from the output data.
- The key – This is the output key we used before.
We also need the global output index. This is part of the output data. This is used to keep track of all the output keys. Each different amount has a different global output index store. So, the first ‘1’ amount that was ever used in a transaction gets a global output index of 0. The second ‘1’ amount gets an index of 1, and so on. If someone then sends a ‘2’ amount, this gets an index of 0, since the indexes for different amounts are not related.
That’s a bit confusing, but if you don’t understand it, don’t worry – It doesn’t really matter.
Finally, we need to generate this inputs key image. To do this, we need to take the key derivation from before (remember that?), and our private spend key. We then perform yet again some magic crypto operations, and we are left with the key image.
Because we need to generate a key image to spend our funds, and we need a private spend key to do so, this allows us to create ‘view only’ wallets, which can only find incoming transactions, and cannot spend them, since it has no private spend key.
If you’re feeling utterly baffled by the previous explanation, the following diagram might help. Or, it might confuse you more. Sorry!
Spending our transaction inputs
Bob has got his transaction inputs all ready in his wallet. Surely he’s able to make a transaction by now?? Good news Bob. Let me explain the steps he needs to take.
Selecting the inputs
Link to the code here.
To start with, we need to find enough inputs to cover the amount Bob wants to send. Alice is sending her t-shirts for 25,000 TRTL, so we need at least that much. He also needs at least 0.1 TRTL for the network fee.
Inputs are selected randomly, to make it harder to detect any patterns in spending. We just keep taking inputs whilst we don’t have enough funds to cover the transaction.
Lets say that the inputs that get randomly selected are 3 TRTL, 0.09 TRTL, 20,000 TRTL, and 9000 TRTL. That sums up to 29003.09 TRTL, so we’ve got enough to cover the transaction.
Since Bob only wants to send Alice 25,000 TRTL, but he doesn’t have the exact amount to send, he instead sends the ‘change’ back to himself. In this case he wants to send 25000 TRTL + 0.1 TRTL (for the network fee) and he’s got 29003.09 TRTL in the inputs, so he needs to send 4002.99 TRTL back to himself.
Preparing the destinations
Link to the code here.
Now we need to split this 29,003.09 into separate atomic amounts, and indicate who we’re actually sending each bit to.
Alice has given Bob her address, which we extract the public spend and view key from. We then split the 25,000 TRTL we’re sending her up into units, which is simply 20,000 TRTL + 5000 TRTL. These will eventually become two outputs for Alice to scan, just like we did at the beginning of this article.
Next, we need to setup the destinations that Bob is sending to himself. We take our address, split it into a public spend and view key, and again split up the amount into units. This will give us 4,000 TRTL + 2 TRTL + 0.9 TRTL + 0.09 TRTL.
So, the transaction will have 6 outputs – 2 belonging to Alice, and 4 belonging to Bob.
Outputs = 20000 TRTL + 5000 TRTL + 4000 TRTL + 2 TRTL + 0.9 TRTL + 0.09 TRTL
Preparing the Transaction Inputs
Link to the code here.
Next we need to hide our real inputs among other inputs, to obscure which inputs are really used to create the transaction. We ask the daemon for as many fake outputs as our mixin value, and we need this many for each amount we are sending. If we are using a mixin of 3, we need 3 fake outputs for 20,000 TRTL, 3 for 9,000 TRTL, and so on.
Next, we loop through each real input, and the fake outputs. We generate a key image using the real input transaction public key, our private view key, and our private spend key. This also gives us a temporary key pair for each transaction input, which we’ll need later for our ring signatures.
Now we can finally make a transaction input, which consists of the amount, the key image we just generated, and the global output indexes of both the fake outputs and our real input. Gah, confusing.
We end up with 6 transaction inputs, with each one having 3 fake global output indexes, and one real global output index. No-one but us can tell which is the real index.
Preparing the Outputs
Link to the code here.
Now we can make the outputs of the transaction. We start by generating a random key pair. This is used so multiple transactions to the same address cannot be linked together.
Next, we loop through the destinations we prepared earlier. We generate the output key by taking the receivers public view key, the private key from the random key pair we just generated, and the receivers public spend key.
Then, we create our output, which is just comprised of the output key we just generated, and the amount the output is worth.
We store the public key from the random key pair we generated – this becomes the transaction public key later.
Assembling the transaction
Link to the code here.
We’ve done most of the work now, we can start putting this transaction together. We start by creating the tx_extra – This has a few bits of data in, but most importantly is the transaction public key. If we’re using a payment ID, we also add that in here.
Then, we copy over the inputs and outputs we prepared earlier, and add a few extra bits like the transaction version, and the unlock time if you want your transaction to not be spendable instantly.
Finally, we hash this data to give us the transaction prefix hash.
Generating the Ring Signatures
Link to the code here.
Finally, we generate the transaction ring signatures. These are used to verify that we own all the funds being spent. We generate signatures for each transaction input, using the private key of the temporary key pair we created for each input earlier, the transaction prefix hash, the public key that each fake transaction output has (including our real input), and each transaction input key image. This again, uses some cryptography magic.
Ring signatures indicate that one person of a group signed a message with their private key, but it cannot be determined which person signed the message. This proves we are able to spend the amounts in the transaction, but our identity is kept hidden.
Sending the transaction
Finally, we’re done! We send our transaction off to a daemon, and if it verifies the transaction is legitimate, Alice will get her funds shortly. There’s one thing we missed when I explained this – detecting when you have spent funds, rather than just when you have received funds.
Finding which transaction inputs belong to us
Fortunately, this bit is pretty simple. Remember when we generated a key image, when we found a transaction that belonged to us? Because that key image is used in a transaction when we send it, we simply look at each transaction input, and if it uses a key image which we created, then we sent it.
Thus, when Bob scans the transaction he sent to Alice, he will see the 4 inputs we used to create the transaction, and find that they use key images he previously created. He will mark these key images as spent, so he doesn’t accidentaly use them in another transaction. This would cause an attempted double spend, which would fail, as a key image can only ever be used once.
When Bob sums the transaction inputs, he would get 3 TRTL, 0.09 TRTL, 20,000 TRTL, and 9000 TRTL – The exact amount he sent. He should then scan the transaction outputs, and find 4 outputs that belong to him – 4000 TRTL + 2 TRTL + 0.9 TRTL + 0.09 TRTL – The change that he sent back to himself.
With this, Bob can work out the total amount he spent on the transaction – inputs – outputs = 25000.1 TRTL.
You may remember that Bob decided to pay a network fee of 0.1 TRTL, but we never gave an address to send this to. The network fee is simply the difference between the sum of the inputs, and the sum of the outputs – the miner who includes this transaction in a block is allowed to add this amount to the coinbase transaction as a reward.
In summary, a transaction is comprised of inputs, outputs, and ring signatures.
- Transaction inputs are money we have previously received, combined with some data to generate the keys. They are also hidden among other people’s inputs.
- Transaction outputs are money that the receiver(s) get. This may include some change which returns to the sender.
- Ring signatures prove the transaction is valid and we own the corresponding private keys. This is an example of a zero knowledge proof: A third party can prove the signatures are legitimate, but it gives them no information about who the sender is, or who the receiver is, just that the transaction is legitimate.
- If a transaction input has the same key image as one we generated, that is an outgoing transaction by us.
- If a transaction output has the same public spend key as ours when decrypted, that is an incoming transaction for us.
I’m sorry if you didn’t understand this. It’s quite confusing, and quite hard to explain. I have to say, the whole inputs, outputs, fake outputs + real input thing confuses me as well.
Thanks for reading – hopefully you learnt something!
There was cheering, there were tears of joy, we have finally made it!
We know the info on there is not all filled in yet, and we’re working on getting it fixed, so in the mean time please send CMC a thank you tweet, or thank you FB post to express your gratitude that they finally listed us, because truthfully we really did not meet the requirements yet to be listed. This just shows how powerful the community can be!
This week we reached #27 on CoinGecko Developer Score, polished our golang skills, and compiled almost completely on Raspberry Pi!
A new fork upgrade has been released! In this release we moved the entire network up a notch on the security score and set a static mixin of 7. If you don’t know what that means, we have an article about it right here!
This week we became more than a meme coin, went live with a new algorithm, got a step closer to compiling on Raspberry Pi and hung out with podcast celebs 🙂
Altcoin Buzz Podcast — Thanks to pHaTe and the folks at Altcoin Buzz Podcast for having RockSteady on for an interview, it went great! Listen to the episode and give them a subscribe on iTunes and YT while you listen!
This week we opened our school of shitcoin artistry, added about 10 devs to the fold, and forgot to write about it until Monday. Hard work over here, folks. Don’t get none on ya! Check it out!
Zpalmtree’s “How To Fork TurtleCoin” Tutorial — “I had a really fun time this weekend live-blogging the process of making my own altcoin forked from TurtleCoin with Zpalmtree’s new guide for how to fork TurtleCoin properly.