So far, we've covered Directed Acyclic Graphs (DAGs), random walks, and various tip selection mechanisms. In this article, we'll finally discuss financial matters - specifically what it means when "Transaction A approves Transaction B."
As mentioned in the first article of this series, each transaction contains information like "Alice gives Bob 10 IOTAs." The approver's first task is verifying whether Alice actually has 10 IOTAs to give Bob.
Some might wonder where these IOTAs come from. IOTA differs from well-known cryptocurrencies like Ethereum and Bitcoin by not requiring mining. All IOTAs were created in the genesis transaction, with no new IOTAs ever created afterward - the total supply remains constant. During the genesis transaction, IOTAs were distributed to initial investors (ICO participants). Subsequent user transactions formed the current network.
Let's examine Alice and Bob as a simple example. The boxes below represent transactions, showing their account balances before and after transactions for clarity. Initially, Alice has 10i; after giving Bob 10i, Alice has nothing left.
Later, Charlie creates another transaction. After running the tip selection algorithm, he determines he must approve Alice's transaction. To complete this approval, Charlie must confirm Alice had 10i available to spend. Careless verification helps nobody - if Charlie approves an underfunded transaction, his own transaction will never be successfully verified.
To approve Alice's transaction, Charlie must list all transactions directly and indirectly approved by Alice's transaction back to the genesis transaction:
- Genesis transaction created 15i
- Genesis transaction gave Bob 2i
- Genesis transaction gave Alice 8i
- Genesis transaction gave Charlie 5i
- Charlie gave Donna 3i
- Bob gave Alice 2i
Any sequence resulting in Alice having 10i and Bob having 0i is acceptable. Charlie must also ensure no account in the system shows a negative balance - otherwise his transaction becomes invalid.
Now consider another example: What happens when Alice tries to give Bob more IOTAs than her account balance?
If Alice gives Bob 100i but only has 10i, Alice's transaction and all subsequent transactions attempting to approve it will be considered invalid by the entire IOTA network.
The situation becomes more interesting when approving two transactions instead of one (which is actually the typical scenario).
In the right example, Bob's payment transaction successfully approves Alice's two payment transactions because Alice's account balance covers both payments.
What happens with insufficient funds? The following example shows Bob cannot get Alice's transactions approved because doing so would leave Alice's account balance negative - which violates protocol. If Bob approves Alice's transactions, he breaks IOTA protocol, and all honest network participants will prevent Bob's transaction from being approved.
This scenario is called a double spend, where Alice spends her money twice. Importantly, Alice didn't break protocol when spending, as her balance covered each individual transaction when sent. Alice might not have intended a double spend attack - she might have accidentally broadcast two transactions. Regardless, Alice created two incompatible branches in the Tangle that cannot be reconciled, posing a significant problem for honest IOTA users: "Which transaction should they approve?"
The solution lies in the previously mentioned weighted random walk. Eventually, one branch accumulates greater weight while the other diminishes. Subsequent transactions attach to the heavier branch (effectively confirming those transactions), while lighter branches get abandoned. This implies a delay between broadcasting a transaction and its successful approval - even if some transactions approve the new one, we cannot guarantee it won't be part of a conflicting branch. To confirm whether the transaction is confirmed, we must wait until its confirmation confidence becomes sufficiently high (which we'll explain in the next article).
👉 Learn more about blockchain confirmation mechanisms
Frequently Asked Questions
Q: Why does IOTA not require mining?
A: Unlike Bitcoin or Ethereum, IOTA had all tokens created in the genesis transaction, eliminating the need for mining to create new tokens.
Q: What prevents double spending in IOTA?
A: The weighted random walk mechanism ensures conflicting transactions (double spends) get resolved by favoring the branch that accumulates more weight through subsequent approvals.
Q: How long does transaction confirmation typically take in IOTA?
A: Confirmation time varies based on network activity, but transactions generally require multiple subsequent approvals and sufficient confirmation confidence before being considered fully confirmed.
Q: What happens to transactions that don't get approved?
A: Transactions that remain unapproved or get abandoned due to conflicts might eventually become orphaned and invalid if the network consensus favors other branches.
Q: Can I reverse a transaction in IOTA once it's confirmed?
A: No, confirmed transactions in IOTA are irreversible like in other cryptocurrencies, as long as they've gained sufficient confirmation confidence.
Q: How does tip selection help prevent network spam?
A: By requiring new transactions to approve existing ones, the Tangle ensures spammers contribute to network security rather than burdening it.