# Tip selection algorithm used for data transactions

A data transaction on the Tangle (a.k.a. zero value transaction) does not need confirmation. The reason for value transactions to all use a similar tip selection algorithm is that it increases the chance of getting your value transaction confirmed. However, a data transaction does not need confirmation and thus it doesn't matter which tip selection method it uses. It could for example just add the transaction to the two latest valid incoming transactions. Now my question is: in the white paper it is assumed that the majority of all transactions uses a similar tip selection strategy, like MCMC. This makes sense for value transactions, but we all know that the vast majority of all transactions are data transactions (like 90% or so). So now we end up in a situation where not all transactions use a similar tip selection strategy which has great implications for the convergence of the Tangle.

How can we still be confident that the Tangle converges?

We could very well end up with a (still consistent) Tangle that has a lot of different branches. This has implications for the confirmation time, and also for the formulas stated in the white paper because they assume a similar tip selection algorithm.

You want it confirmed because transactions which do not become part of consensus (heavy part of tangle) are pruned/discarded by full nodes (because they aren't relevant and are taking up memory) and fall into oblivion.

Using the Tangle for data transactions is to have an immutable and trustless way of making a statement about the state of some data. For example, 'this car's odometer reads X kilometers'. Now it wouldn't be possible for the same car's odometer to read less than X kilometers in some future transaction, else you know it would have been tampered with. But for this to be effective, the data transaction has to become part of the 'true history' (i.e. included in the Tangle). If it is discarded, or even if it isn't, we cannot know for sure when the second odometer reading is issued, which came first.

• Please add to your answer why that would be a problem for data transactions. May 6, 2018 at 17:54
• I guess this makes sense. Some guys on the discord tanglemath channel mentioned that confirmation is not really necessary for data transactions though. This got me thinking. But it makes sense that if you run a full node you'd discard these transactions after a while for the reason you mentioned. May 6, 2018 at 18:21
• I don't see any code in the IRI to delete/forget unconfirmed transaction. Maybe I miss something, but IMO, there is no way for a fullnode to discard unconfirmed transactions (except snapshots of course, but snapshots removes all transactions anyway) May 8, 2018 at 20:10
• There is a lot of things that aren't in IRI but should be, or are in IRI but shouldn't be. IRI has a lot of work that needs to get it to production readiness or reflect our theoretical understanding of the Tangle.
– user482
May 10, 2018 at 19:44

I would question your first sentence.

If you are not interested in getting your transaction confirmed, why do you want the transaction on the tangle anyway?

One of the use cases of putting data on the tangle is to later prove that the transaction has existed before (and give an approximate time it was inserted). For example to have "unforgeable" car odometers. For that, it is necessary that your transaction has others transactions approving it, so you are interested in getting your transaction confirmed, contradicting your statement.

• It is interesting to note that, not every transaction in a stream needs to be confirmed. If, say on average, every other odometer reading will be confirmed and have the status of immutability, then as long as each data transaction contains the hash of the previous transaction in its stream then the unconfirmed transactions also gain a high level of trust. This means that many IoT devices will not need to concern themselves with the task of tracking a transaction to finality. May 9, 2018 at 8:56

Basically, if the tip selection algorithm used by the majority of the transactions gives totally random tips, the tangle will not converge.

This kind of scenario (in the context of a double-spend attempt) is described in the white paper (version 1.3, page 19) :

the input flow of “honest” transactions should be large compared to the attacker’s computational power.

and is the justification for the coordinator:

This indicates the need for additional security measures, such as checkpoints, during the early days of a tangle-based system

So as long as the majority of transactions don't use a fair MCMC-like tip selection algorithm: the coo is required to give a consistent direction to the tangle (all this is already in the white-paper).