Double-Spending Masterclass

Forum Admin (33K reputation)Forum Admin (33K reputation)Forum Admin (33K reputation)Forum Admin (33K reputation)Forum Admin (33K reputation)Forum Admin (33K reputation)Forum Admin (33K reputation)Forum Admin (33K reputation)Forum Admin (33K reputation)
Group: Administrators
Posts: 3.6K, Visits: 6.8K
Masterclass taught by: Come-from-beyond

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. This the Byzantine Generals problem that cryptocurrencies solved with Satoshi's white paper nearly a decade ago.

To help with the masterclass, Come-from-Beyond asked the community to produce some examples of a double-spend. Achim provided the following:

Achim Heiniger:
Alice owns 1 iota. I would:
1. Get 90% of global hashpower, which is not that hard atm.
2. Merge all tips until I end up with a chain-like tangle. There would be only one tip: "tip1"
3. Publish two legit transactions: tx1 that references tip1 where Alice spends 1 iota to Bob, and a second spam transaction tx2 that confirms tx1.
4. Publish a prepared subtangle that also references tip1, the subtangle contains a doublespend transaction that spends 1 iota from Alice to CfB.
5. 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.

Tomer Krisi:
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

hans meiners:
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.

Ivan Liborio:
But will both receivers see their received iotas as confirmed during this inconsistency period? (edited)


Tomer Krisi:
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

Tomer Krisi:
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

Tomer Krisi:
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.

Tomer Krisi:
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()

Tomer Krisi:
I see...

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.

Coordinator is currently used as protection against an XY attack ("34% attack"). In the future, the technique explained during the Consensus Masterclass (also posted in this forum) will be used instead to reach consensus.

Merge Selected

Merge into selected topic...

Merge into merge target...

Merge into a specific topic ID...

Reading This Topic