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
They were so small that they are now stuck in your account, as you don’t have enough to pay the fees for transferring this dust anywhere.

That’s one way you may see dust accumulate, because they are stuck due to fees.

4/n
But you may actually see dust accumulate as an attack:
gemini.com/cryptopedia/cr…

5/n
Dusting attacks can also “bloat the ledger”. This means that the amount each node needs to store will increase irreversibly, and cause the performance of the network to decrease. This is particularly easy if the network is feeless like #IOTA.

What does this actually mean?

6/n
Remember that 1 Mi (= 1 MegaIOTA = 1 million IOTA) is currently just over $1.30.

So I can send 1 million 1 IOTA transactions feelessly by buying IOTA for just over $1.30. It will take time to send all of these transactions, but it is easily doable.

7/n
Now if I send 1 IOTA to a million addresses using that 1Mi, it takes a lot lot more space to store that on the IOTA ledger, than 1 Mi on a single address. Why?

1 Mi on an address = store 1 address.
1i on a million addresses = store a million addresses.

8/n
(I have simplified this to avoid explaining utxo’s)

But we can see that we need a mechanism to stop people attacking the network by sending these dust transactions.

And this situation is made much worse by the introduction of native tokens and NFTs.

9/n
These new output types essentially behave like 1 IOTA transfers, but even worse, because they involve 0 IOTA.

So to prevent attackers filling up the database with nonsense data, we use the same protection.

But why is this not an issue with other cryptos?

10/n
Well it is!

But remember that the feeless nature of IOTA means that we encounter these problems well before other protocols. So, these are issues that affect everyone. We just have to try to be ahead of the curve to deal with them.

11/n
TLDR:
We have a really elegant solution to the dust problem which works really well with the new tokenisation framework.

Importantly is also begins to answer some tokenomic questions about #IOTA.

Let me know what you think and please comment in the RFCs.

❤️

• • •

Missing some Tweet in this thread? You can try to force a refresh
 

Keep Current with Navin Ramachandran

Navin Ramachandran Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @navinram999

12 Feb
Many people have been asking me what #IOTA Industrial Oracles are all about.

This excellent article outlines a major problem with traditional DLT oracles.

hackernoon.com/lying-to-the-b…
If you put garbage data into your DLT, you will get garbage results out of your smart contracts. Garbage in, garbage out.
How do you tackle this? Dell and Intel have been looking at exactly this problem. With the added benefit of privacy preservation.

builders.intel.com/docs/networkbu…
Read 7 tweets
29 May 19


1/ I have heard this a few times in the last day.
IOTA's coordicide uses a voter model which has been extensively studied since the 70s.
2/ The voter model originates in these two papers:
P. Clifford, A. Sudbury, A model for spatial conflict. Biometrika 60 (1973), 581–588.

R.A. Holley, T.M. Liggett (1975) Ergodic theorems for weakly interacting infinite systems and the voter model. Ann. Probab.3(4),643–663.
3/ An oversight of all this work is referenced in the FPC paper.
summit.sfu.ca/item/17718

We are humbled to build on the seminal research of other groups.
Read 5 tweets

Did Thread Reader help you today?

Support us! We are indie developers!


This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!

:(