The second IOTA Masterclass was held recently, this time focusing on double-spending (if you missed the first one you can find it here).
So what is a double-spend?
It is most simply described as any transaction that brings an address balance to a negative value. For example, spending the total balance two different times. It is essential that any double-spends attempts are not successful otherwise trust in IOTA would be damaged.
To help with the masterclass, Come-from-Beyond asked the community to produce some examples of a double-spend. Achim provided the following:
Alice owns 1 iota. I would:
- Get 90% of global hashpower, which is not that hard atm.
- Merge all tips until I end up with a chain-like tangle. There would be only one tip: "tip1"
- Publish two legit transactions: tx1 that references tip1 where Alice spends 1 iota to Bob, and a second spam transaction tx2 that confirms tx1.
- Publish a prepared subtangle that also references tip1, the subtangle contains a doublespend transaction that spends 1 iota from Alice to CfB.
- Because syncing of a chain-like tangle is much slower, I'd hope that it would lead to lagging nodes, I'd hope that Bob's node sees the legit tx first and confirms it, whereas the large rest of the network will see the doublespend first and confirm that instead of the legit tx.
Would a tx get confirmed that references only one tip (branch and trunk are the same)?
How probably will the attack succeed and what mechanisms prevent it?
Scenario #2 ends at "Get 90% of global hashpower" because we can allow an adversary to control not more than 1/3 of the hashpower.
Are you not allowing for anyone to control 1/3 of the hashing power, or just an adversary? Can't we have a benevolent guy who has more than 1/3 of the hashing power? In any case how can it be controlled?
It can't be controlled, bad wording, we consider IOTA insecure in such conditions
It's a secure assumption that an adversary can't have more than 33% of hashing power
Companies and machines probably won't conspire to destroy the system
For the second example, Come-from-Beyond supplied this image:
So let's look at this scenario with apples...
Most of the time a node receives and shares transactions with neighbors. It cares about tangle topology only when it's time to generate a transaction or to accept a payment.
Imagine that now it's 16:04 and Bob decides to send a message.
He creates a transaction that reference 2 transactions:
- one deposits 1 iota to Alice address
- the other spends 1 iota from Alice address
This doesn't lead to a double-spending so at 16:07 he stops creating a transaction containing his message.
90 minutes later a bad guy named Charlie decides to reference Bob's transaction and another transaction that spends 1 iota from Alice address
At 17:44 he finishes generating a transaction that references a subtangle with an illegal state (ledger).
None of us cares about that, we don't know about bad guy Charlie because our nodes keep receiving all transactions and sharing them among us
At 19:15 a good girl named Diana decides to send a message to her mother. She analyzes the Tangle and sees that she shouldn't reference Charlie's transaction so she references Bob's transaction instead.
Her transaction is not special, so it's not shown in the picture.
Few minutes later a smart girl named Eva decides to send a message to her boyfriend. She is good but she is also smart and decides to troll bad guy Charlie...
She finds a transaction that deposits 1 iota to Alice's address. She references that transaction and also the transaction of Charlie. We see Eva's transaction at 19:21
Later someone else generating a transaction will reference Eva's transaction without any issues because she "fixed" the problem created by Charlie.
As we can see in this scenario during a short period of time ledger can be inconsistent
Everything will be fine as long as 67%+ of hashing power is controlled by benevolent users.
PS: It's worth emphasizing that in IOTA we don't care about the order of transactions. For ledger validation we can traverse the transactions in any order. This boosts performance and helps to scale to much higher TPS than a ledger with ordering would allow.
But will both receivers see their received iotas as confirmed during this inconsistency period? (edited)
Let's say Eva has a transaction that points only to Charlie... In that scenario, after the reordering would she have to replay again?
Yes. If majority doesn't approve her tx (and it won't) then she will need to replay
So Charlie has the capability to delay the network...
no, it's only Eva that decides to troll, others will just ignore Charlie's tx, just like Diana
if Eva doesn't see everything that happens on the network how would she know if she is trolling?
She just happened to see his tx and that unconfirmed tx in the bottom. This feature enables different scenarios like crediting on subtangles.
hmmm... not sure I get it... haha.... Let me ask it this way... isn't there a possibility that she is doing it without knowing that she is trolling? if so she would have to replay, meaning that Charlie got something by that
no such possibility, transactionToApprove() function returns only valid subtangle, she is assumed to use a hand-crafted transactionToApprove()
the protocol allows that
As you will hopefully now understand, by relying on at least 67% of users being good actors and selecting only valid transactions to reference, IOTA can eliminate the possibility of double-spends being successful.
Any short term inconsistencies in the tangle are quickly overcome by the collective weight of honest users referencing valid transactions.
We currently use Coordinator as a protection against 34% attack. In the future the technique explained during the previous masterclass will be used instead to reach consensus.