Buffy's IOTA Facts


Hi I am buffy. I do premium IOTA tech consulting.

All articles · FAQ

Zero-Value transactions: Fun but worthless

TL;DR: Zero-value “transactions” are fun for hobbyists, but give no guarantees to developers & industry partners, making it a bad platform to build production systems on.

Note: Per the reaction on a previous article, I’m always happy to consider feedback & will update the article where I’m wrong. However, I do only consider things that are actually specified. Off-hand ideas thrown around on Discord are hard to verify, hard to analyze & hard to argue with.

Zero-Value Transactions are unreliable


If you write a temperature reading to the tangle and broadcast it to a node of your chosing, what are your guarantees about the data?

  1. Are they guaranteed to be in the tangle?
  2. What if the node retries (reattaches/promotes) for you?
  3. After you’ve seen them being confirmed, are you (or other people) guaranteed to be able to read them in a month? a week? immediately?
  4. Are they immutable?

For any other database systems (e.g. AWS DynamoDB), the answers are Yes, Not needed, Yes/Yes/Yes and “when wanted & legal”. For IOTA, the answers are No, No, No/No/Maybe and in a problematic way.

1. Data might not persist in the Tangle, even if your node says so

If you commit to a single node, and get an OK back from the RPC, there are still plenty of error cases which can result in your transaction being dropped.

  1. Your transaction might simply be voted out (because one of it’s dependents conflicts1. If gossiping is done over UDP, and you’re having a bad minute, no neighbors (or too few) might actually hear about the transaction.
  2. The node might crash at any point and simply drop your transaction. If it takes a very (?) long time, the node might just prune the transaction before it is even sent2.

At the time of writing, thetangle.org shows a 97%3 confirmation rate, even with the temporary White Flag boost. This means 3 out of a 100 writes fail. For comparison, AWS DynamoDB will start refunding money below 99.99% (“standard”) and 99.999% (“global”) availability.

Production-ready database system create reliability from unreliable components by making sure the data is properly replicated, persisted to disk and (in case of strongly consistent systems) that consensus exists that the write should be applied. This normally happens in a few hundred miliseconds, before the client is given an OK. IOTA can’t guarantee any of these, by design.

2. Nodes may prune at any time.

This is by no means hypothetical: An example of pruning affecting a production system can be seen on http://transparency.iota.org (which might just be the only production system using IOTA): The “transaction” links (bottom right in each card) for grants older than 7 (?) days show no data (example from the Hornet Phase 2 grant, 14 days old at the time of writing). The site, utils.iota.org, is not broken though: heading to thetangle.org and trying one of the recent ones on utils.iota.org does work for me.

3. Data is immutable (until pruned), but that’s hardly a good thing

Other statements that don’t hold up

Messages are verified

The argument here is that the Tangle does create validation through the Merkle tree (some form of verification).

The first thing to look at is what is actually verified.

What the tangle (and other blockchains) actually does is called “Trusted Timestamping”. In effect, it verifies that some piece of data existed at a specific time. The timestamp in each transaction becomes part of the hash, which then gets referenced by other transactions etc.; standard merkle tree stuff.

But using the tangle for timestamping is not straight forward - the tangle is mainly built for feeless microtransactions, not timestamping. Two large problems:

Merkle-proofs require more than just than the transaction

Without going into too many technical details, due to necessary optimizations (see Hans’ post in #serious_tech_talk for details) you cannot actually prove the statement “is transaction X in the tangle”:

Due to the way you need to optimize merkle proofs, you need to observe the tangle for a while after you published the message. In order to prove inclusion in the tangle, you need to provide not only the message hash, but also a part of the DAG (minutes or hours worth of tangle activity).

Positive proofs only

You can only trust “postive” proof-of-inclusion results:

In other words, if you own a message that you’d later like to verify exists in the tangle, you might be able to do so, but not in a trustless manner.

Free Trusted Time-stamping in split-seconds is already a thing

Instead of jumping through all the hoops above, why not just use an rfc3161 timestamping server? Plenty of free ones are available, which you can all use in combination if you like, and if your threat model is “Multiple CAs, Universities & Apple are compromised”, you have different problems anyway (and certainly should not be relying on experimental blockchain technology)

“If you need persistence, you can run a permanode”

First of all, I don’t think there is a single use-case for zero-value transaction (in a production environment) that does not require at least some form of reliable persistence. But permanodes do a poor job at this:

Neither of the two permanode types solves problem (1.) - it is unclear whether a transaction you send will actually arrive at the database-backed permanode. And since the fullnode will eventually “degrade” into a selective node for legal reasons, and selective nodes require trust, the question then becomes - why not skip the tangle & write straight to a regular database?

“The tangle is not a database anyway”

In that case, the remaining use-case is as a “communication system”. But

The Tangle doesn’t really add anything as a communication system, it only makes a hard problem worse.


There are other problems here, that are similarly problematic, like

I might address those in a later post.

I am aware that you can make arguments (for a post-coordicide world) that “it is decentralized”, and that is certainly a valid argument. The question is whether users, developers are willing to put up with the above problems, just to have decentralization. After all, some IF leaders have pointed out that industry partners do not actually care about the Coordinator that much.

The tangle is a fun platform to experiment on and build prototypes, but it is useless when you’re trying to build actual applications on top of them.

Happy to hear your feedback, feel free to send me an email and/or twitter. Or stop by #serious_tech_talk in CinTan’s Spec!

  1. I know that hans has mentioned an “approval switch” to make this problem less bad. This seems to break merkle proofs & the DAG approval structure (i.e. everything in The Tangle whitepaper). Given that this has been an off-hand comment on #tanglemath, and i’ve seen no actual specs for this, I’m going to assume that this is something in Hans’ head which may or may not actually work out) 

  2. Everyone has an approximate vague concept of how long components - hard drives, SSDs, CPUs, RAM, PSUs - last, usually derived from personal experience using PCs. It is important to note though that load is an important factor in life-time, too. It is already well known that SSDs degrade with the amount of writes, and similar effects (although not as extreme) happen with other components, too. Have a look at your Task Manager and check your utilizations, and compare that with the 100% goal that data center operators strive for. 

  3. There is the argument floating around that “these are invalid transactions”. Then

    • Why are “invalid” transactions being counted in TPS, but not CTPS?
    • There’s certainly evidence that valid transactions are still not being confirmed post-chrysalis (search for “promote” in official discord),
    • Once White Flag is removed, in the productionization of Coordicide, the conf rate will drop again anyway,
    • Even if not, my argument certainly works with 99%, too.

  4. I should point out that running databases for production workloads costs actual money. AWS generated 77% of Amazon’s profit in 20Q2. Companies don’t run their business off cheaper consumer-grade hardware (or even Raspberry Pis) because, at the end of the day, the additional reliability makes it worth it.