tip: 15 title: Dust Protection description: Prevent bloating the ledger size with dust outputs author: Gal Rogozinski (@GalRogozinski)
discussions-to: https://github.com/iotaledger/tips/pull/32 status: Active type: Standards layer: Core created: 2020-12-07 superseded-by: TIP-19
In the UTXO model, each node in the network needs to keep track of all the currently unspent outputs. When the number of outputs gets too large, this can cause performance and memory issues. This RFC proposes a new protocol rule regarding the processing of outputs that transfer a very small amount of IOTA, so-called dust outputs: Dust outputs are only allowed when they are backed up by a certain deposit on the receiving address. This limits the amount of dust outputs, thus making it expensive to proliferate dust. Since a receiver must make a deposit, the protocol makes receiving dust an opt-in feature.
An attacker, or even honest users, can proliferate the UTXO ledger with outputs holding a tiny amount of IOTA coins. This can cause the ledger to grow to a prohibitively large size.
In order to protect nodes from such attacks, one possible solution is to make accumulating dust outputs expensive. Since IOTA does not have any fees that might limit the feasibility of issuing many dust transactions, deposits pose a valid alternative to achieve a similar effect.
When an address is supposed to receive micro transactions, it must have an unspent output of a special type as a deposit. This deposit cannot be consumed by any transaction as long as the dust outputs remain unspent.
An additional benefit of this rule is that it makes a mass of privacy violating forced address reuse attacks more expensive to carry out.
Dust output: A transaction output that has an amount smaller than 1 Mi
SigLockedDustAllowanceOutput: A new output type for deposits that enables an address to receive dust outputs. It can be consumed as an input like a regular
|Output Type||uint8||Set to value 1 to denote a SigLockedDustAllowanceOutput.|
|Amount||uint64||The amount of tokens to deposit with this SigLockedDustAllowanceOutput output.|
Let A be the address that should hold the dust outputs' balances. Let S be the sum of all the amounts of all unspent
SigLockedDustAllowanceOutputs on A. Then, the maximum number of allowed dust outputs on A is S divided by 100,000 and rounded down, i.e. 10 outputs for each 1 Mi deposited.
However, regardless of S, the number of dust outputs must never exceed 100 per address.
The amount of a
SigLockedDustAllowanceOutput must be at least 1 Mi. Apart from this,
SigLockedDustAllowanceOutputs are processed identical to
SigLockedSingleOutput. The transaction validation as defined in the IOTA protocol TIP-7, however, needs to be adapted.
Syntactical validation for
Addressmust be unique in the set of
SigLockedDustAllowanceOutputsin one transaction T. However, there can be one
Amountmust be ≥ 1,000,000.
The semantic validation remains unchanged and are checked for both
SigLockedDustAllowanceOutput, but this RFC introduces one additional criterion:
A transaction T
- consuming a
SigLockedDustAllowanceOutputon address A or
- creating a dust output with address A,
is only semantically valid, if, after T is booked, the number of confirmed unspent dust outputs on A does not exceed the allowed threshold of min(S / 100000, 100).
- There can no longer be addresses holding less than 1 Mi.
- The actual validity of dust transaction can only be checked during semantic validation.
- A service receiving micropayments may fail receiving them, if it did not consolidate dust outputs or raised the deposit for the receiving address.
- An attacker can send microtransactions to an address with a
SigLockedDustAllowanceOutputin order to fill the allowed threshold and block honest senders of microtransactions. The owner of the address can mitigate this by simply consolidating the attacker's dust and collecting it for profit.
Rationale and alternatives
The rationale for creating a special
SigLockedDustAllowanceOutput rather than rely on the default
SigLockedSingleOutputs is to prevent attackers from polluting arbitrary addresses that happen to hold
a large amount of funds with dust.
One may note that an attacker can deposit a dust allowance on 3rd party address outside his control and pollute that address with dust. From a security perspective this is better than an attacker depositing a dust allowance on addresses under his control. This is because the receiving party might later choose to consolidate the dust outputs and hence relief UTXO memory consumption. The receiving party is also unlikely to be displeased from obtaining more funds, small as they may be.
There are potential alternatives to introducing dust allowance deposits:
- Burning dust: Allow dust outputs to exists only for a limited amount of time in the ledger. After this, they are removed completely and the associated funds are invalidated.
- Sweeping dust into Merkle trees: Instead of burning dust outputs after some time, they are instead compressed into a Merkle tree and only the tree root is kept. In order to spend one of these compressed outputs, the corresponding Merkle audit path needs to be supplied in addition to a regular signature.
The first option can cause issues, when dust outputs were burned before users could consolidate them. Also, changing the supply can be controversial.
The second option is much more complicated as it introduces a completely new unlock mechanisms and requires the nodes to store the Merkle tree roots indefinitely.
Copyright and related rights waived via CC0.