RFC: Dust Protection

[GalRogozinski]

Rendered

[karimodm]

I find the pseudo-code really hard to follow! I think it needs to be consistently simplified.

[karimodm]

This entire section should be gone.

[Wollac]

I find the pseudo-code really hard to follow! I think it needs to be consistently simplified.

I agree. I was even wondering whether it should be removed completely. During the last few iterations the Validation rules got rather precise and well-defined, so IMHO they are much easier to understand and review than the pseudo code.

[Wollac]

If we really wanna keep the pseudo code, it must be simplified:
E.g

• remove if tx not null it is fair to assume this is always given
• remove the maps and rather write something like "if there is another SigLockedDustAllowanceOutput with address in tx"
• ...

[Thoralf-M]

An attacker can send microtransactions to an address with a SigLockedDustAllowanceOutput in order to fill the allowed threshold and block honest senders of microtransactions.

Not only that, the attacker could also make it basically impossible to move all funds from that address if more dust per dust allowance output is allowed than one can have inputs in a single transaction to collect it with the dust allowance output together
Even large dust allowance outputs should not allow more than 100 dust

[GalRogozinski]

@Thoralf-M
you have a good point

But maybe the address owner can take funds out in batches?
The idea of increasing the number of outputs so that the address would not be easily blocked for dust recieval.

For example, a service can put 3 Mi and constantly consolidate 100 outputs.

[Thoralf-M]

But maybe the address owner can take funds out in batches?

@GalRogozinski if an attacker constantly sends new transaction to this address the owner of the address can only move all funds if he does the PoW faster than the attacker or if the attacker stops spamming at some point
If you want to receive more dust on an address you should create multiple dust allowance outputs on it

[Thoralf-M]

Reducing the dust per output to 100, independent of the amount of the dust allowance output, also protects in cases where someone with a lot iotas (1 Ti for example) creates a dust allowance output unintentional (unintentional with such a large amount), then an attacker can just spam 100 million dust outputs to this address

[GalRogozinski]

Since we have a rule that a single message can't create more than 1 output per address, it means that an attacker will have to create 100 different messages with a signature for each. A sweeper can use 100 inputs with 1 output and 1 signature in a single message. At least from tests on my personal laptop I concluded that the attacker would need to have X20 PoW power to keep up with the sweeper.

I want to point out that the current know flaws with the proposal are discussed here https://hackmd.io/@iota-protocol/S1zFaBCjP (just a draft). In the Chrysalis protocol team we talked about implementing the dust tiers idea later on. The assumption behind the dust tiers solution is that tiny dust is less useful for business purposes than larger dust. Meaning we can be very limiting on small dust outputs, but not so much on larger dust, which will be more expensive to spend in a large scale.

If you want to receive more dust on an address you should create multiple dust allowance outputs on it
I don't understand the difference in security between having more dust allowance outputs or just having one consolidated one

As for the last comment about someone accidentally creating a 1 Ti allowance, I guess it is possible but unlikely...
The default behavior of libs would be to create regular outputs. How often would people do it accidentally? Will it amass to 1 Ti?

The reason to allow more than 100 is to make sure that businesses that want to rely on microtransactions can actually do it w.o having their addresses blocked. From a security perspective, I agree with you.

[GalRogozinski]

Hmm, It doesn't make sense that the amount will be less than a dust amount. I can rephrase it this way. Should wallets in general update themselves in case of a change? That's up to the wallet to decide... I still think of it as syntactic validation, but I guess it can be viewed as semantic Btw, why does the hardware ledger itself has to validate anything? Shouldn't it just sign and leave validation to the software wallet on the laptop that is connected to the ledger?

…

On 22.1.2021 10:11, Thomas Shufps wrote: Some suggestion from my side: move |The Amount must be ≥ 1,000,000.| from syntactical validation to semantic validation. Reason: Amount of dust will change over time and I can't put a static value into eg the validation of the Nano Ledger app! That shouldn be validated on node side and not on hardware-wallet side. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#32 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4WDF4I7UUIB4PNIPD2M73S3EXMLANCNFSM4UU6SNIA>.

[thibault-martinez]

The amount of a SigLockedDustAllowanceOutput must be at least 1 Mi.

This is already said right after in the syntactical validation, bit repetitive.