In the MAM introduction article there is for example this part about the message size:

These messages can have any size; however, a heuristic evaluation would demonstrate smaller messages yielding higher potential for data integrity. For example, one could transmit an encrypted 4k video using MAM but this will saturate the network leading to a lagging user experience.

Here I'm not concerned about the lagging user experience for a subscriber as it's obviously not a good use case for MAM but my concern is, how will the network/tangle suffer if people would still actually send such big data streams?

From my understanding data streams are 'broadcasted' to all nodes (like normal transactions) and subscribers only qualify as such as they know the address of the stream (= channel ID) and decryption key.
This would mean that only few but data intense streams could put the whole network under heavy load up to a point where full nodes on slower connections could become practically unusable. It would also mean a much faster tangle size increase between snapshots which could also become a problem for smaller full nodes (of smaller companies or individuals).

Am I missing something here or are there countermeasures?

2 Answers 2


Transaction size is limited. An intensive data stream will be splitted into many transactions. Each transaction requires a small pow and the idea is that even if it is small, the pow will discourage usage of intensive data stream.

The expected way to use MAM for such use case is to just transfer securly kind of credentials encrypted on the tangle and use those credentials to setup a completly off-tangle connection between devices to do the heavy data stream.

As far as I understand, addressing the problem of big data stream is exactly the same as addressing the problem of spammers. MAM doesn't impact the problematic here.

  • The PoW is a good point. The difference to fighting spam is that MAM would be 'legitimate' spam and therefore there is no way to filter it.
    – Jey DWork
    Commented Dec 11, 2017 at 0:57
  • full nodes could also just refuse to store the message of a zero-value transaction for longer than a few days. Commented Jan 4, 2018 at 20:15

The primary countermeasure for this will be automated snapshotting.

Per the IOTA Roadmap:

To keep IOTA in accordance with the needs of embedded devices which will permeate and constitute the Internet of Things it uses ‘snapshotting’, which keeps the ledger database that devices has to keep very small in size. Snapshotting is similar to Blockchain pruning, except Snapshotting has the significant advantage of grouping several transfers to the same address into 1 record, which leads to a smaller storage requirement overall.

Source: https://blog.iota.org/iota-development-roadmap-74741f37ed01

The size of transactions only affect node holders. As node holders will have access to snapshotting, they can decide if they want to keep that data for themselves.

I'm curious about why you think that anyone except full node holders will be affected by the size of any given transaction.

  • That doesn't answer the question because let's do snapshots is one of the worst scaling concepts imaginable.
    – Helmar
    Commented Dec 10, 2017 at 9:42
  • The size of the tangle for full node holders is also only my secondary concern. My primary concern is the bandwidth / network congestion for full node holders. I'm especially thinking about small to mid sized companies which could have a hard time running full nodes. And obviously the network quality would suffer greatly if there are only few full nodes and if it really would be easy to clog up the whole network by only a few data intense MAM streams.
    – Jey DWork
    Commented Dec 10, 2017 at 20:31
  • by the way, snapshotting and MAM rises also other question like this one: iota.stackexchange.com/questions/28/… which is also very interesting and currently unanswered.
    – Jey DWork
    Commented Dec 10, 2017 at 20:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.