The new IOTA tokenisation framework introduces various new UTXO types, which add a great amount of functionality to IOTA. But they can also add large amounts of data to the ledger (eg for NFTs, native assets, aliases).
2/n
All this new data will bloat the ledger, just like dust. So we need a dust solution that can also deal with this type of bloat, and would also ideally work with IOTA 2.0.
A new dust solution is proposed. This has 2 rules.
3/n
Rule 1:
Any UTXO must contain a minimum deposit.
The amount has not yet been decided, but for the sake of simplicity, let's make it 1 Mi for our examples.
4/n
Rule 2:
The amount of data that any UTXO can hold is proportional to the amount of IOTA on that UTXO.
The IOTA acts as a deposit to secure that data on the Tangle. You can add more IOTA to add more data.
The amount of IOTA required can be adjusted over time.
5/n
Now, to send amounts smaller than 1 Mi, or to send native assets, we introduce a new system of "conditional sending", which does not require total ordering of the Tangle.
It is therefore ready for IOTA 2.0.
6/n
Let's look at how this works if I want to send 10i to an address which already holds 5 Mi (assuming the minimum deposit is 1 Mi).
As before I cannot just send 10i, because the UTXO will have a value of 10i (well below the minimal amount of 1 Mi).
7/n
I cannot use a special dust allowance output as in 1.5, because these need total ordering of the Tangle.
Instead I use "conditional sending”. Let’s walk through the steps of the conditional send:
8/n
Step 1:
I send the 10i together with the minimal deposit amount (1 Mi) to the target address. This gives a total of 1.00001 Mi, which fulfils the dust protection criteria.
9/n
Step 2:
As this is a special type of transaction, it requires a further step to complete - it has to be "claimed" by the recipient.
Therefore 2 things can happen to this transaction:
10/n
a) The 10i is claimed by the recipient, which involves 2 simultaneous transactions:
i) 10i is transferred together with the recipient's own minimal deposit to a new UTXO (needs their own 1 Mi deposit to make a valid UTXO).
ii) The 1 Mi deposit is returned to the sender.
11/n
b) The 10i is not claimed in a reasonable time period (set by the sender), and the total amount of 1.00001 Mi can now be reclaimed or spent by the sender.
(The mechanism is a bit more complex but this is the simplest way of looking at it.)
12/n
Bonus:
This conditional sending can also be used as a safety net to prevent sending to the wrong address.
It is a common problem in crypto that funds are sometimes transferred to the incorrect address due to mistyping of the address.
13/n
Often this address has no owner and the tokens are lost forever! If this were to happen in a conditional send however, then the tokens are very unlikely to be claimed in the set time period, and the total amount can be reclaimed by the sender. Nice!
14/n
Final note:
We are also looking at other mechanisms for microtransactions which make the process simpler, while still respecting the dust protection rules.
We hope to share more with you soon.
Hope you made it through all of that. Heavy reading, but worth it! 😅
/thread
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Recognising the risk of ledger bloat, a dust protection mechanism is introduced.
Note: when we are thinking about dust we have to think about UTXOs rather than addresses. This is quite tricky to understand for most people, as we will see. It took me some time!
3/n
The tokenisation specifications released today have attracted a lot of interest. There is so much to delve into here, but first I wanted to talk about the ugly duckling that was also released today. The new #IOTA dust RFC: github.com/muXxer/protoco…
1/n
This RFC is quite complex to understand, because we have tried to tackle many things at the same time, using an elegant unified system. So I will try to explain this as simply as possible.
Let’s start with why this dust protection is needed. What exactly is “dust”?
2/n
“Dust” refers to very very small amounts of cryptocurrency. So small that you would usually ignore it. If you trade on an exchange, you will likely see very small amounts of tokens, which you previously traded, still remaining in your account.
3/n