Summary

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.

Motivation

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.

Detailed design

Definitions

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 SigLockedSingleOutput.

Name Type Description

Output Type uint8 Set to value 1 to denote a SigLockedDustAllowanceOutput.

Address oneOf

Ed25519 Address

Name	Type	Description
Address Type	uint8	Set to value 0 to denote an Ed25519 Address.
Address	ByteArray[32]	The raw bytes of the Ed25519 address which is the BLAKE2b-256 hash of the public key.

Amount uint64 The amount of tokens to deposit with this SigLockedDustAllowanceOutput output.

Validation

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 SigLockedDustAllowanceOutput:

The Address must be unique in the set of SigLockedDustAllowanceOutputs in one transaction T. However, there can be one SigLockedSingleOutput and one SigLockedDustAllowanceOutputs T.
The Amount must be ≥ 1,000,000.

The semantic validation remains unchanged and are checked for both SigLockedSingleOutputs and SigLockedDustAllowanceOutput, but this RFC introduces one additional criterion:

A transaction T

consuming a SigLockedDustAllowanceOutput on 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).

Drawbacks

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 SigLockedDustAllowanceOutput in 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.