-
Notifications
You must be signed in to change notification settings - Fork 26
Improve spec on binding tokens to existing UTXOs #80
Comments
@afilini can you pls elaborate on this issue you've proposed in the roadmap? |
Seems like the actual discussion are happening underneath PR #59. Copying the last proposal from there: With the current RGB spec we can already spend assets to an existing UTXOs and have a separate flow of the assets independent from the flow of the bitcoins. This will not work for Spectrum, but completely fine for the on-chain transfers. In order to obsucate UTXOs until the proofs are spent, we can use HMAC, as proposed in the mentioned PR #59 – but with a key for HMAC being the actual public key, corresponding to the UTXO address. This key is not known before the actual UTXO is spend — and when it is being spent, it becomes public, so no reason to add it to the proof, meaning there would be no size increase for the proof. |
The actual RGB spec has to be improved in pay-to-existing UTXO part in a way that we need to have two states of the proof: an initial, with only HMAC_SHA256(utxo_public_key, txid:vout) serialized – which should be included into the proof commitment – with this data being replaced later, when the UTXO is spend, with the actual txid and vout in a non-hashed form. This will not break the commitment, since a verifying party would be able to compute HMAC the proof was committed to from these data + public key in the spent tx output (related issue: #98 ) |
It shoudn't become public after the UTXO is spent. The idea is that you require the the next proof to know the UTXO, so the sender will never know it |
@inaltoasinistra, ok, let me re-phrase it in a correct way. The proof is passes several stages.
After this operation Bob transfers updated proof + a newly created proof to Carol. Now Carol also knows which output Bob has spent and had his assets bound to – but this is unavoidable anyway in order to verify the proof and prevent double spend. Original payee, Alice, still do not know which UTXO was used. Will this work? |
Alice can discover which is the UTXO computing the hash on all the outputs of the blockchain with the same rule. When she finds the correct hash she knows the UTXO. |
True, but not when the payee (Bob) uses a new public hash (HD-derived, for instance). And since it is in his interest to preserve the privacy, he will do that. |
Also new public keys are exposed when UTXOs are spent. So Alice could check all the public keys of new blocks until she found the correct key |
After the team meeting at @inbitcoin it was decided to abandon this change, since |
In https://github.com/rgb-org/spec/blob/master/01-rgb.md#address-based-vs-utxo-based
Comment by Alekos:
The text was updated successfully, but these errors were encountered: