Full Circle Magazine FR

A CryptoCurrency is actually simply a ledger/audit of transactions, maintained by a decentralized peer to peer network. Amazingly, this ledger is protected by the computing power of the peer-to-peer network, and, unless an entity with malicious intentions gained control over more than 50% of the total network computing power, the ledger is safe and sound. The ledger simply contains transactions (here expressed in BTC/bitcoin): • Alice gave Bob 5 BTC • Bob gave Steve 1.5 BTC • Steve gave Frank 0.8 BTC All transactions are sent to the whole peer-to-peer network: in other words, all transactions are public, and therefore anyone who knows how to add can find out which accounts have received the most money. However, it is difficult to map any given account to a given entity, as any entity can have many accounts. It is actually difficult to express what a single coin of a cryptocurrency is, because coins exist only as parts of transactions and have no real being of their own. In cryptocurrencies, the only elements that have being are transactions and transaction blocks (more on this later). Coins themselves are not modeled as part of the protocol. This can lead to the question: how are coins created? There is a system in place (mining) that allows transactions to give coins to a recipient, without having any specific sender - thus coins are “created” from nothing through transactions. This will be explained as part of the block mining paragraph.

Making Sure a Person Has Enough Coins to Cover a Transaction Assume Alice wants to send Bob some coins. How are we sure that Alice has enough Bitcoins or other cryptocurrencies to send to Bob? To be sure that Alice has enough Bitcoins to send to Bob is easy: with each outgoing transaction, she needs to broadcast incoming transactions to show that she has enough money to send that money to Bob. So she will actually refer to transactions as below: • “I received 3 bitcoins on my wallet from Peter” • “I received 2 bitcoins on my wallet from Frodo” Therefore: “I can send 5 bitcoins to Bob’s wallet” Once this is done, the referred transactions (also known as the inputs of a transaction) will be considered to have been flagged as “Spent”, meaning she can no longer use them as referrals to send money, avoiding double-spending money (otherwise, Alice could keep referring to the 3 bitcoins she received from Peter and spend again and again from that transaction). In reality, none of the transactions are flagged as spent; it is simply easy to check all the transactions in the peer-to-peer-maintained transaction ledger to detect whether any transaction has been or is being double-spent (actually there is an index of unspent transactions to make that task easy).

In effect, given a long list of transactions, it is computationally very difficult (and in many cases impossible) to find a set of previous transactions that show Alice received money for exactly the amount that she wants to send. This problem is well-known in mathematics, and commonly referred to as the knapsack problem. To solve this issue, with each outgoing transaction, Alice will simply refer to ALL of her previous incoming transactions (which will be flagged as spent), and two transactions will be generated: • one that goes to Bob, for 5 BTC • one that goes back to Alice, for her remaining Balance In other words, with this outgoing transaction, Alice flags all of her previous incoming transactions as spent, and replaces them by a single transaction that summarizes her remaining balance. This solves the issue of knowing whether Alice has enough to cover the outgoing transaction.

An example is as below: • Alice received 7 bitcoins from Peter (Transaction1) • Alice received 10 bitcoins from Jason (Transaction2) • Alice received 6 bitcoins from Steven (Transaction 3) • Alice wants to send 15 bitcoins to Bob (Transaction4) So what will happen is: • Alice creates Transaction4, referring to Transaction 1, 2, and 3 as inputs, and broadcasts it to the network • Transactions 1,2,3 are therefore spent, and cannot be used as referral transactions to send money anymore • A new transaction, Transaction5, is created that gives back 8 bitcoins to Alice. That transaction is still valid, and can be used by Alice to send bitcoins later on.

Making Sure That Alice is the True Originator of the Send Request One of the problems faced by cryptocurrencies was: when looking at the transaction “Alice gave Bob 5 BTC,” how are we sure that it is really Alice who sent Bob 5 BTC? Could it be that Bob sent a fake message to the peer-to-peer network saying there was such a transaction, in order to steal 5 BTC from Alice? Or might Alice be referring to other transactions that were not sent to her? Proving that Alice is indeed the owner of the money is accomplished by signing the message using a public and private key system. Basically, when receiving money from Peter and Frodo, Alice gave each sender a public key (her receiving public key, effectively an address that identifies an account), which is a 64-digit hexadecimal number. When she generated that public key, she also generated a private key, that she alone knows - it is critical to protect that private key.

For each incoming transaction (input) that Alice refers to when she wants to send money, Alice needs to prove that she is the owner of the Public key that this incoming transaction was sent to. To do so, she mathematically combines her transaction message “Alice sends 5 BTC to Bob” to the private key (linked to her incoming account public key) to generate a signature that is appended to her transaction message. This signature does not contain her private key, nor can her private key be inferred from it. However, it is possible to verify that a message was properly signed by the relevant private key by comparing the public key to that signature and the message. Therefore, all nodes on the peer-to-peer network can do the following for each transaction sent: • check the referral transactions that prove the sender has enough coins to send (i.e. that previous transactions that the sender received are enough to cover the amount being sent); • get the public key (or public keys) that the referral transactions were sent to (this should be the sender’s receiving public key); • check the signature of the send transaction against each public key and the send transaction message content; • if the signature matches the public key, then it means that indeed the sender is the owner of the private key linked to the public key that the referral transactions were sent to. The sender is therefore entitled to send that money, and mark the referral transactions as spent.

This ingenious system makes it easy for anybody to check whether a sender owns the private key to a public key to which money was sent, and therefore to check that the sender indeed was the recipient of enough money to be able to send money. All of this without knowing the sender’s private key! What is also interesting is that, each message being different, the signature generated by mixing the private key to that message is also always different, even though the private key itself doesn’t change. Therefore the signature not only serves to prove that the sender is the owner of a receiving account that has received enough money to cover the transaction, but also to protect the message against tampering: if anyone were to change the contents of the message (such as the public key to which the message is being sent to in order to receive it maliciously), the signature would not match the message it is attached to anymore, and the transaction would be rejected. Generating new public keys and private keys is easy, and can be done without access to the Internet - it is almost impossible to have a collision with another user, because of the sheer number of possible public keys. Cryptocurrency clients will usually do it for you. Terminology point: referral transactions are usually referred to as the “input” to a transaction, and the “output” of the transaction is the public key and account to which money is being sent.

Checking the Input Transactions Of course, all of the referral transactions need to be checked as well! This is achieved by looking at their inputs (their own referral transactions) and then checking those, all the way back to the beginning. When downloading a cryptocurrency client (such as a Bitcoin client), the first thing the client does is actually download the whole history of transactions from nodes on the network, and validate each and every one of the transactions and their inputs, and it keeps doing so for any new transactions received from the network. It also makes sure that no transaction has been referred to as input more than once, since that would indicate there was a double-spend. Thus a peer-to-peer security network, requiring no trust between nodes, is formed.

Quick Summary of What We Have Seen Thus Far A cryptocurrency is just a list of transactions, which are protected against tampering and negative balances through a public/private key system. In effect, any public key used on the network is an account, also referred to as a wallet. The only thing necessary to claim ownership of that Public key (and therefore to claim ownership of all the transactions that were sent to that public key) is the Private key linked to that Public key. That Private key gives the power to send money to another Public key address. In other words, a cryptocurrency account is a simple tuple of (public key, private key), which can be printed on paper. If you have that tuple, you own the account. All the records are kept in the peer-to-peer network, and it is therefore not necessary to keep track of anything other than your own public and private key tuples. You can at any time know how much coin each of your public keys is entitled to spend by getting the most recent ledger from the peer-to-peer network, and adding up all unspent transactions that were sent to each public key until you get your balance. All cryptocurrency transactions are irreversible. There is no customer support, no central entity to refund you. Transactions cannot be rolled back because they are already part of the public record across many nodes.

Main sources: • the bitcoin paper: http://bitcoin.org/bitcoin.pdf • the excellent, but fast-moving, under-the-hood explanation of bitcoin (this explanation follows roughly the same structure, but spends more time on some points and less on others): http://www.imponderablethings.com/2013/07/how-bitcoin-works-under-hood.html • the Primecoin paper: http://primecoin.org/static/primecoin-paper.pdf • an explanation of the paper: http://www.reddit.com/r/primecoin/comments/1rp5vx/could_someone_explain_in_detail_the_algorithm/ COMPETITION Win 500 Dogecoin (DOGE) by answering the following question: Referral transactions are usually referred to as ___ ? (Hint: the answer is in the article) Email your answer to: ronnie@fullcirclemagazine.org before Friday 21st March. The winner will be notified via email for a valid Dogecoin wallet address. Another 500 DOGE will be up for grabs next month in Cryptocurrency Part 2.