How to reference Tx in transfer proof when using P2C scheme?

[chm-diederichs]

When implementing some RGB proofs, it seems the txid has a circular dependence when the pay-to-contract scheme is used. The proof references the on chain Tx to which it is bound in the bind_to field

My understanding:
->bind_to references original_txid in proof
-> proof used to tweak public keys of some outputs
-> Tx output public keys have changed, therefore SHA256d(Tx) = new_txid != original_txid
-> bind_to is changed to now reference new_txid
-> etc.

As far as I can tell, the current behaviour is not explicitly defined. Should the bind_to field be omitted when tweaking the keys and verifying commitments?

[chm-diederichs]

Taking an Alice, Bob, Carol example:

Alice's prepares a proof and binds it to Tx_a, which she prepares with necessary commitments and coloured outputs assigned to Bob. Alice has no need for the bind_to to be referenced since she is creating that Tx herself.

Unlike with the commitment, the binding of the assets is not deterministic, but is chosen by the trading parties. So as far as I can tell, there shouldn't be any way to simply infer from previous transactions which Tx the assets will be bound to next, especially so for UTXO based transfers, so the TxID must be conveyed to all future parties in some way.

Without bind_to in the proof, Alice would have to communicate the TxID to Bob after it has been published, otherwise Bob would not be able to access the UTXO to which his assets are now bound (assuming vout based transfer). Even for a UTXO-based transfer, when Bob now knows the location of the assets, without the bind_to field future parties (i.e. Carol) would not be able to verify the commitments.

Possible solution:

Omit the bind_to field from the proof when committing to it, kind of like SIGHASH. Then the bind_to can be put in after, once the keys have been tweaked and the TxID is finalised. This removes the circular dependence.

It seems this may allow double spending, where one party can commit the same proof to multiple Tx. However, this would require at least one UTXO to be spent by multiple separate Tx, so this should be protected against double spend. (Please correct me if I am mistaken)

Once the assets are transferred to Bob, and the proof is finalised with the correct bind_to showing the correct TxID, Bob can now send assets to Carol. Since this proof is now in the inputs, the TxID of Tx_a is now committed to. Therefore its only the TxID of the current transaction which is malleable.

[dr-orlovsky]

Well, as I just checked, bind_to field is absent in the current RGB spec; it was introduced only right inside the code of the original rgb library by @afilini, and I just followed his design in my re-write — and, it seems we do not need it. I will move the issue into the rust-rgb repo since it is not spec-related

[chm-diederichs]

How do future parties know where the commitments will lie if the TxID is not referenced within the proof at each step?

For vout based transfer they can just walk back up the chain and the location of the commitment will be deterministic; but for UTXO-based transfer, the TxID of previous transfers must be included, no?

[chm-diederichs]

The verification process implemented in rgb-rust is dependent upon being to fetch the transaction using tx_provider function, which takes as input the bind_to fields of the relevant proofs/inputs.

I don't think this is an issue of rgb-rust specifically, it's an issue affecting the general verification protocol.

commitment verification: https://github.com/rgb-org/rgb-rust/blob/95e84e652f56969d6f11406c5636ed177515fa50/src/proof.rs#L187

verification of previous comments: https://github.com/rgb-org/rgb-rust/blob/95e84e652f56969d6f11406c5636ed177515fa50/src/proof.rs#L233

[dr-orlovsky]

The code is wrong b/c of my misinterpretation of the original rgb code, which was broken in it's verification functionality.

The spec was also incomplete in this regard. Basically, you need to always commit within the tx that spends any of RGB assets, so there is no need to reference its txid inside the proof itself. I've updated the spec – pls see rgb-archive/spec#102 and rgb-archive/spec@da3a77b

bind_to field within the proof should not be part of the commitment, it's an extended prunable field added to enhance the speed of communications with Bitcoin Core – check rgb-archive/spec#78 This field will be removed if we will accept rgb-archive/spec#80