For data integrity AIONs concept of only storing a path of txs to prove that a txs exists in the Tangle is a nice concept but has the problem that you still need to store a lot txs in the long term. Even if you use timewarps because they can only get confirmed in a short time frame.
With the UTXO model one could just reference a data tx with a value tx and can use the OutputID (Pair<Address, TransactionID>) as proof at any later time to proof that the data txs were there, because otherwise the value txs could not have been confirmed. That way one would only need to store the data tx and a 1i tx that references it to proof that it exists if I understand it correctly.
Would it work like that or did I miss something?
Because you only need 1i it could lead to a dust attack, so this could become a problem but other than that, I see no downside.
This could have very important implication for DID storage on the Tangle as storing Proofs that they are part of the Tangle becomes a lot easier. It wouldn’t even need to even do a dust transaction, but can also look for the closest confirmed value tx. What happens if the value tx is spend though, can the now spend value tx still be used as an anchor point? If not, that means you basically introduce a very small and recoverable fee to create your own controlled anchor point in the Tangle.
Would love to hear the thoughts of the research team on this!
You don’t need UTXO for this. Even now you can keep 1 iota in the address and the 1i output to that address would contain data existence of which we want prove. Those addresses won’t be snapshotted, just like unspent outputs in the UTXO. That is an expensive way of keeping data proofs it seems
Messages are pruned, but not UTXOs, because they are needed to keep track of the balances. We can use this property to prove that data exist. To do this we need to send the data either in a value transaction itself or we send it as a data message and reference this message with another value transaction. The first option would reduce the amount of messages you need to send and store to only one, but with the other way the sender doesn’t need to own IOTA tokens himself. For example a sensor could send the data in a message and another service references the data message with a value transaction and stores them.
An UTXO consists of the transaction hash, the index of the output on the transaction, the address and the value. You can put an indexation payload (data) in the transaction payload and it will also be to calculate the transaction hash.
First version more detailed explained:
First you need to get some IOTA token to be able to create UTXOs. When you have them every time you want to send data you include it in a transaction where you send the token to yourself again. This transaction will create a new UTXO that’s known by all nodes and will be stored until it’s used as input. As long as you don’t use this UTXO for a new transaction you can prove that your message is in the Tangle, because otherwise the nodes wouldn’t have this UTXO. So as long as you want to be able to prove it you shouldn’t use this UTXO as input for a new transaction, expect maybe you want to store more data. In this case you can create a new transaction with the data included like the first time. Now with the new UTXO you can prove that your new data exists, but because the transaction uses the first UTXO as input you can also prove at the same time that the first data exists. You can repeat this step as many times as you want and all you need to store is all your own transactions.
If someone now wants to verify that your data exists you just provide the latest UTXO and the transaction/s until the point where the data is. The person can then start to calculate the UTXO of the first transaction with the data and will find it in the next transaction until there is no transaction anymore, but then the UTXO is known by all nodes, where he just needs to check if it’s really there.
As this also does what you are looking for and can work without owning any iota upfront or requires it to keep it locked.
That solution would solve multiple problems and we can get rid of timewarping entirely and the main long connecting proof will be part of each node. You only need the tx path to(/from) a dust transaction as proof. The rest is done by the nodes.
