Giters

RGB-WG / rgb-core

RGB Core Library: consensus validation for private & scalable client-validated smart contracts on Bitcoin & Lightning

Home Page:https://spec.rgb.tech

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Broadcasted witness tx has different txId than the one specified as anchor in consignment

adambor opened this issue · comments

commented

This issue has been moved from LNP-BP/nodes repo....

Hello, I have an issue when following the demo-rgb.sh.

When I finish creating the consignment, with the transfer finalized by executing:
rgb-cli -n testnet transfer finalize --endseal ${TXOB} ${PSBT} ${CONSIGNMENT}
And then I sign and finalize the transaction:

btc-hot sign ${PSBT} ${DIR}/testnet
btc-cold finalize --publish testnet ${PSBT}

The resulting txId is different than the one specified in consignment, so the consignment never validates. Any idea why that might be the case?

Tx is broadcasted and mined on testnet here: https://blockstream.info/testnet/tx/6796b0ef9cd3128c43159081dd6bf11ff1afe474bb6bf3e96aa33b038f5af6b0
+ attaching the consignment, transfer, and psbt in a zip file. rgb-tx.zip

Looking forward to your reply!

Maxim's reply:
Hi! Thank you for reporting. Can you please move the issue to https://github.com/RGB-WG/rgb-core/ where it should belong to?

Next, the answer is simple: indeed the commitment modifies txid, thus if you'd like to store assets in the same witness transaction (which contains commitment) you need not to provide txid and a special form of single-use-seal is used (called 'witness-based', referencing only the output number)

Originally posted by @dr-orlovsky in LNP-BP/nodes#16 (comment)

commented

Hello,

It's super cool to know that it's possible to actually assign the change of the RGB asset to the witness transaction's output! How does one specify it with "rgb20 transfer" command?

However that's not the issue here, I am receiving token change on a different and already existing UTXO. The problem is that the witness transaction has a different txId than the one referenced inside of the consignment file, due to that the consignment never passes validation and ends up with:

adam@node1:/data/rgb$ rgb consignment validate demo.rgbc
---
unresolved_txids: []
unmined_endpoint_txids:
  - 1604ed46aaa005823731de0fb6c84160e8a68a721c0db20bdc32e3163fc568a3
failures:
  - TransitionNotInAnchor:
      - 41110920c4b42e0ff61d73721edefd18cac7085be7996715862c2fc81ee9085b
      - 1604ed46aaa005823731de0fb6c84160e8a68a721c0db20bdc32e3163fc568a3
warnings:
  - EndpointTransactionMissed: 1604ed46aaa005823731de0fb6c84160e8a68a721c0db20bdc32e3163fc568a3
info: []

Even though I broadcasted the generated transaction here: https://blockstream.info/testnet/tx/6796b0ef9cd3128c43159081dd6bf11ff1afe474bb6bf3e96aa33b038f5af6b0
The txIds are different between the actual witness transaction broadcasted on-chain and the one referenced in the consignment file (1604ed46aaa005823731de0fb6c84160e8a68a721c0db20bdc32e3163fc568a3)

commented

Will investigate this. Thank you for all the details.

Was it a first transfer of the funds, or it gets failing after several?

@zoedberg maybe you have witnessed a similar issue?

commented

Was the very first transfer, was following the demo-rgb.sh file.

commented

may be related to RGB-WG/rgb-node#197

@adambor if you were using a release build, could you please try building in debug mode and see if this "fixes" the TransitionNotInAnchor issue?

commented

Yep, I was downloading the release from cargo. Will try to compile the rgb-node myself and in debug mode.