The Tangle: an illustrated introduction

Part 4: Approvers, balances, and double-spends

So far we talked about DAGs, random walks, and various tip selection mechanisms; this week we will talk about money. The time has come to explain what we mean when we say that transaction A approves transaction B.

As mentioned in the first article in the series, each transaction contains information of the form “Alice gave bob 10 IOTAs”. It is the approver’s job to make sure that Alice really had those 10 IOTAs to give in the first place.

You might wonder at this point: where did these IOTAs come from? The answer is that they were all created in the very first transaction in the tangle, called the genesis transaction. No additional IOTAs will ever be created. From the genesis the IOTAs were transferred to the accounts of the original investors in the project, in proportion to the amount they put in. Afterwards, they sold some of their IOTA to others, and a trading network was eventually established.

Coming back to Alice and Bob, let’s look at a simple example. The box represents a transaction. For convenience, we also write down the balances in Alice and Bob’s accounts before and after the transaction took place. We see that in the beginning Alice had 10i, which she gave to Bob, after which Bob has 10i and Alice has nothing.

Eventually someone, say Charlie, wants to make his own payment. He runs the tip selection algorithm, and it turns out he needs to approve Alice’s transaction. To do that, he must verify that Alice really had the 10i she spent. Charlie had better take this task seriously: if he approves a bad transaction, his own transaction will never be approved!

To be absolutely sure, Charlie has to list all the transactions approved directly and indirectly by Alice’s transaction, all the way back to the genesis. He ends up with a long list, which may look like this:

Genesis creates 15i Genesis gives Bob 2i Genesis gives Alice 8i Genesis gives Charlie 5i Charlie gives Donna 3i Bob gives Alice 2i

This is just one option of course; any list that ends up with 10i in Alice’s account and 0 in Bob’s is acceptable. Charlie also has to keep track of all the other accounts in the system, to make sure they do not go below zero: if any of the balances in the “before” or “after” sections are negative, his transaction is invalid.

Let’s have a look at at a case where Alice tries to give more IOTAs than she has:

Alice paid Bob 100i even though she only had 10. Alice’s transaction, and any future transaction that approves it, are considered invalid by the network. Negative balances are not allowed.

The situation gets more interesting when we approve two transactions rather than one:

Bob was correct in approving Alice’s transactions, because she had just enough money in her account to pay both without going below zero.

What would happen if the total is more than she has? This is shown below. In this case, Bob cannot approve both of Alice’s transactions, because they result in a negative balance for Alice. If Bob does this, he is breaking the rules of the IOTA protocol, and no one will approve his new transaction.

This last situation is called a double spend, because Alice spent her money twice. Notice that she did not break the protocol, because she had enough money for each individual transaction. Maybe she did not even mean to double-spend, but sent her transaction twice by mistake. She did however create two branches in the tangle that cannot be reconciled. This creates a problem for honest users of IOTA: which branch should they approve?

The solution to this problem is once again the weighted walk we learned about last week. Eventually one of the branches will grow heavier than the other, and the lighter one will be abandoned. This also implies that a transaction cannot be considered to be confirmed immediately after it is issued, even if it has some approvers, since it might be part of a branch that will be abandoned eventually. In order to be sure your transaction is confirmed, you have to wait for its confirmation confidence to be high enough. This will be the subject of next week’s article.

As always, you are more than welcome to ask me questions here or on Discord, @alongal#3938.

Part 1: Introduction to the Tangle

Part 2: transaction rates, latency, and random walks

Part 3: Cumulative weights and weighted random walks

Part 5: Consensus, confirmation confidence, and the coordinator