Dust attacks mitigations

--- title: Dust attacks mitigations tags: discussion --- # Dust Attacks Mitigations ## Summary In the current dust proposal we offer that a receiver should create a deposit to a [`SigLockedDustAllowanceOutput`](https://github.com/GalRogozinski/protocol-rfcs/blob/dust/text/0032-dust-protection/0032-dust-protection.md#definitions). For every 1 Mi deposited on an address there should be up to 100 dust outputs allowed on the same address. However an attacker can still cause the following problems: 1. Dust censoring - Fill up the dust quota on a service's address to block real customers from sending funds to the service. 2. Allowance censoring - Block the withdrawal of the allowance deposit by continously sending dust to an address. This document will try to present two mitigation to those issues: lowering Pow requirements for dust sweeping, and dividing dust quotas into classes. ## Current solutions that don't require changes To solve dust censoring, the receiver can continuously sweep and consolidate dust outputs. However, if the receiver wants to always be available for receiving dust, then there is no reason to assume that the sweeping rate will be faster than the dust creation rate. Also constantly sweeping dust may cost more in terms of PoW than the value swept. To solve allowance censoring the receiver can wait until dust quotas are full or even fill them himself by self dusting. Then with one transaction sweep the dust and the deposit. ## Exploring other mitigations In order to carry these attacks out, one should send many dust outputs as quickly as possible to the target address, and hope that the dust won't be all swiftly swept by the receiver. The factors that will make the attacks effective are: 1.Dust spamming rate: The more MPS of dust the attacker can create, the easier it will be for him to fill up the quota, or ensure it doesn't empty. 2. Target's dust sweeping rate: The rate the target can consolidate dust to free up the quota. 3. The dust quota itself: The stricter the dust quota, the easier it will be to fill up. (1) has some mitigation by the default validation rule that states that within a transaction ["the address must be unique in the set of SigLockedSingleOutput."](https://github.com/luca-moser/protocol-rfcs/blob/signed-tx-payload/text/0000-transaction-payload/0000-transaction-payload.md#syntactical-validation) However, an attacker having access to specialized hardware may still be able to spam dust at a high enough rate. Since in Chrysalis there's only PoW as rate control, the best we can do is to have harsher PoW requirements for dust. This may not be such a great idea, given that it may cause dust payments to stall. It will make it harder for low end devices to issue payments. So subduing this factor is not so practical... It is possible for (2) to consider lowering PoW requirements for dust sweeping. This should reduce the time and cost for sweeping dust for the receiving party. If we ensure that the receiving party can usually collect dust faster than it is created, the attack can be mitigated successfully. Currently, PoW is specified to grow linearly with the size of the message. If we allow exclusive dust sweeping transactions to follow a different rule, for example a constant PoW, we can ensure that dust sweeping will always be far easier than dusting an address. The drawback is that it allows to send very large messages without incurring in any PoW cost. So perhaps a sublinear growth for sweeping dust is preferable? Even with the above PoW change, given the current price of IOTA, an attacker filling up the quota of 100 dust outputs with 100i, and still incur a PoW cost for the receiver that is higher than the profits of the swept dust [TBD: find out real cost of dust]. However, by altering with the dust quotas allowed by the allowance deposit this problem may be mitigated. #### Weight function We can assign weights to different outputs that depend on the amount. At the current price level, and according to known use cases, dust outputs transferring larger amount of dust should be more prevalent than small amount of dust. So we can define dust classes and give them different weight units (WU), and change the validation rule so an address with a 1 Mi deposit can hold up to 1 million WU of dust *per each class*. #### Step weight function: *One possible naive (and probably not safe) division would be:* tiny: 1 iota to 10 iotas -> 100,000 WU small: 11 to 100 iotas -> 10,000 WU medium: 101 iotas to 1,000 iotas -> 1,000 WU large: 1001 iotas to 10,000 iotas -> 100 WU extra large: 10,001 iotas to 100,000 -> 10 WU humongous: 100,001 to 999,999 -> 1 WU The first division is considered not safe because for a very small cost the attacker can still proliferate dust outputs. *Another possibly safer division (probably not optimal) would be:* Small: 1 iota to 5,000 iotas -> 100,000 WU Medium: 5,001 iotas to 10,000 iotas -> 10,000 WU large: 10,001 iotas 50,000 iotas -> 5,000 WU extra large: 51,000 iotas to 999,999 -> 100 WU The idea in the latter division is to make really small dust amounts practical only for testing but not so much for commercial use. This seems like a fine assumption at the current price level. Extra large dust amounts will take up to 10 seconds to fill up at 1000 MPS rate. This should give enough time for automatic dust sweeping services to perform their task. **Pros:** - Easy to understand and implement - Disconnecting between different classes quotas makes this hard to attack - On the more prevalent dust use cases it will allow to up to a million dust outputs **Cons**: - small changes in the amount can cause a jump from class to class. - It is very limiting to small dust outputs, but arguably their use won't be so prevalent. - The chosen mapping that tries to optimize utility and security depends on the token price. - Sweeping small dust may not be cost effective in terms of PoW... So the receiver may choose to not bother sweeping them ever. ### Conclusion Lowering the PoW requirements exclusively for sweeping will help ensure that the cost of PoW can remain small when sweeping dust. This will ensure the viability of receiving dust payments. Also, making dust easier to sweep will help ensure that an attacker will have a hard time filling up the quota. This will help mitigate dust censoring. The dust classes will ensure that the quotas for receiving larger, and probably more common, dust outputs will be very high and thus harder to block. This is because there will be more time to sweep the outputs. The cost of the attack will also increase. However, this is done at the expense of receiving small dust amounts. An attacker trying to block the deposit allowance withdrawal, using extra large dust outputs, will end up paying the receiver more than the full deposit amount. If the attack will use low dust amounts, then filling the quotas will not be hard so the receiver can use the original atomic transaction mitigation. ### Questions: 1. PoW for sweeping should grow sub-linearly or maybe just remain constant? If sub-linear, than what would be the proposed equation? If PoW will become sublinear can it open an attack vector? 2. In order to have a better weight function, maybe a continuous function (linear or logarithmic) would be better? So there won't be sudden changes in WU? However, how do you do a clear separation of class quotas in this case? Maybe have clear strict classes that each have some continuous weight function? ### Conclusion: 1. Check how more expensive it is to attack with current proposal comparing to sweeping. 2. Weight classes can be added in later versions if needed.