In this topic we discuss a potential solution to mitigate the Conflict spamming attack. While Conflict white flag proposes a simple solution for this attack vector, it does not rely on the basic premise that a valid transaction in the Tangle always references two valid transactions as it was introduced in the IOTA whitepaper. In the following we propose a different idea:
Ignoring Recent Conflicts in the Tip Selection
Each transaction gets an additional flag whether it is locked or not. Then, the tip selection algorithm never selects a tip that directly or indirectly approves a locked transaction. As potentially invalid transactions are locked, this reduces the chance of re-attachments.
In order to determine this flag, a node performs the following algorithm on each incoming transaction x. We fix the parameters c_1 and c_2 with c_1 < c_2 both greater than the expected network delay. Also note that this algorithm relies on the notion of disputing transaction instead of conflicting transaction, where the more formal definition of disputing is given in the next paragraph.
- If x is in dispute with any transaction that is younger than c_2, then
- Transaction x is marked as locked.
- Else
- Transaction x is marked as locked and added to a buffer B, where it remains for time c_1. After that it is removed from B.
- If the node does not receive a transaction in dispute with x during this time, the locked flag of x is unset as soon as it is removed from B.
- When a transaction y is finalized (e.g. confirmed by a milestone)
- Remove y from B.
- Remove the locked flag from y.
In short, when two disputing transactions are received within a short time, both will be ignored. However, in certain cases (for example after snapshots, when the original transaction became orphaned or to spend more than once from an address) issuing such transactions must be possible after a longer waiting period.
Definition of a Dispute
For this approach it is crucial to carefully specify the definition of a dispute.
- In order to mitigate the conflict spamming attack, the following must hold
x is in conflict with y ⇒ x is in dispute with y
(but not necessarily the other direction) - If a user that is not in the possession of the private keys can issue a transaction y that is in dispute with x, this could be used by an attacker to permanently censor any transaction x. As such, only the owner of the funds must be able to create disputing transactions.
This leads to the following specifications:
- Re-attachments must never count as disputes (and thus conflicts)!
There are the following options for this:- Do not allow re-attachments:
Easy to do. However, to prevent a situation in which funds are stuck, it must be possible to issue a new transaction re-spending these funds.
⇒ one time signatures do not work - Always ignore re-attachments:
To identify (and then ignore) re-attachments across snapshots, the bundle hash of each applied transaction must be included in the snapshot file, even for 0-value addresses
⇒ not feasible - Ignore only recent re-attachments:
To avoid the drawback of the last point, re-attachments are only ignored when they are “recent” and never in different snapshots. There must be consensus on the definition of “recent” and it leads to the following definition: Two transactions conflict, iff they are conflicting in the old sense but are no re-attachments OR they are re-attachments with a large time difference. - Ignore re-attachments in the balance computation by applying the Conflict white flag approach to them (but not other conflicts).
- Do not allow re-attachments:
-
x is in dispute with y, iff x and y spend from the same address.
This is well-defined. Non-conflicting transactions spending from the same address are still completely valid and can be issued after c_2 without any penalties. - In the UTXO model: x is in dispute with y iff x and y both use the same unspent output.
This is well-defined and can be checked easily. - In the account model: x is in dispute with ledger state L, iff x applied to L leads to an address with negative balance.
This is not well-defined for only two transactions and to check this criterion all possible ledger states would need to be checked, which is not feasible computationally.
Advantages
- The premise that a valid transaction “vouches” for its referenced transactions is still correct: A valid transaction never confirms two conflict transactions.
- This method is just an addition to the tip selection to mitigate the conflict spamming attack, as such it is 100% backwards compatible with the previous interpretation of the Tangle.
Disadvantages
- By itself, it does not offer 100% protection against the conflict spamming, only heuristic to make it (much) harder.
- If a non-disputing transaction x is not immediately “finalized” after c_1 an attacker can still try to get a conflicting transaction y, issued at c_1 + \epsilon, confirmed by artificially enhancing y in the consensus process.
- The tip selection only considers value transactions that are older than c_1. Depending on c_1, this will make the Tangle “wider” (effectively increasing the network delay) which causes other issues.
In order to prevent the conflict spamming attack efficiently the c_1 should be chosen as large as possible, while for the sanity of the Tangle is should be chosen as small as possible. - Finding reasonable values of c_1 and c_2 heavily depends on the network and the used consensus mechanism and require more tests and simulations to find out.
- It requires the ignoring of re-attachment. This is a challenging topic on its own and it seems that this requires valid timestamps in some form (e.g. global milestones or checkpoints).
- Re-attachments or re-spends can only be issued after time c_2 has passed which could significantly slow down honest users.
Conclusion
If the original implications on the validity of referenced transaction should be kept, the Hetfield solution offers a possibility to make the conflict spamming attack much harder and potentially uneconomical. However, this forces us to ignore re-attachments which is a challenging requirement. More analyses and tests would be necessary to propose a final specification of this approach, even in the context of a coordinator network.