Can commitment_txid be pruned in UTXO-based transfers? about spec HOT 6 CLOSED

This information can be pruned since we deterministicaly know this transaction id as transaction spending one of outputs containing the asset, i.e given the whole proofs history and original issuing contract this can be reconstructed from the blockchain information

from spec.

Related: #102

from spec.

Ok, but in the case of multiple consecutive based UTXO-based transfers, say from some_vout-> utxo_1 -> utxo_2 the proof for some_vout -> utxo_1 is committed too in the transaction spending some_vout, which is retrievable from the blockchain info if some_vout is known. This proof only shows utxo_1 in its serialised form, which is not sufficient to retrieve it on chain.

Then the proof for utxo_1 -> utxo_2 will be committed to in the transaction spending utxo_1. But if commitment_txid is pruned from the proof at a later point, this transaction can no longer be inferred from the proof history and the commitment cannot be verified, since utxo_1 is entirely separated on chain from both some_vout and utxo_2 and only associated in the RGB proof.

If all subsequent commitment_txids are pruned as well, then none of the subsequent commitments may be found either since the chain of spending can not be inferred.

from spec.

No, this works differently.

Initially, you have an issuing contract, defining the UTXO containing the issued assets. You know that UTXO. And when the UTXO is spend, you know that from Bitcoin blockchain — as well as you know the transaction which spends it. This transaction contains the commitment to the proof, and the proof points next UTXO(s) holding assets — and so on and on. There is no need to storing commitment_txid at all! It's just a performance booster for Bitcoin Core index.

from spec.

Please check this image for the details: https://raw.githubusercontent.com/rgb-org/spec/rgb-0.5/assets/rgb_overview.png

from spec.

Copying here my explanations from Slack for some future references:

It's important to have a right intuition on how you look to the system. Its not proofs referencing transactions or previous proofs, it is transactions referencing proofs in a very indirect way.

So blockchain is the primary source on the structure of proofs DAG. Each asset is assigned to some TxOut. Transaction spending this TxOut must contain the commitment to the proof showing where the assets will go next (to which TxOut) - and this constitutes the links between proofs. Proofs are not directly reference previous proofs, inputs or commitment transactions, since it is not necessary. Proofs only reference TxOuts holding asset assignments.

In order to validate a proof you need to be provided with a complete proof history up to an issuance contract - and then you start validation process from the root (issuance) to the proof you are validating.

So, if Alice wats to send Bob some assets and Bob wants to pay Alice for the assets some bitcoins,

1. Alice provides Bob with the full proof history up to the issuance contract with a new draft proof
2. Bob validates the history and creates a new tx and a new proof, where tx (a) spends some outputs from the last proof provided by Alice, (b) contains acommitment to the new proof, and (c) the proof assigns assets to some outputs of the new transaction - or some other(s) UTXO(s) owned by Bob
3. Bob provides Alice with both unpublished tx and the proof
4. If Alice ok she signs the tx and publishes it to bitcoin network
   This gives necessary atomicity and escrow guarantees.

from spec.