Improve spec on binding tokens to existing UTXOs

[dr-orlovsky]

In https://github.com/rgb-org/spec/blob/master/01-rgb.md#address-based-vs-utxo-based

Comment by Alekos:

By writing in a proof that the new "owner" of an RGB output is an external UTXO, it's possible to separate the flow of Bitcoins from the flow of assets:

• Base version: writing which UTXO is the new owner
• Obfuscation: Hide the UTXO until the proof is spent. This hides the UTXO from the sender (which creates the proof). Discussion: spec#59

[dr-orlovsky]

@afilini can you pls elaborate on this issue you've proposed in the roadmap?

[dr-orlovsky]

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.

[dr-orlovsky]

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 )

[inaltoasinistra]

This key is not known before the actual UTXO is spend — and when it is being spent, it becomes public

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

[dr-orlovsky]

@inaltoasinistra, ok, let me re-phrase it in a correct way.

The proof is passes several stages.

1. "Unspent proof": the proof is created by the payer (Alice). It receives from the payee (Bob) the hash, which is HMAC_SHA256(public_key, txid || vout) and includes it into the proof, committing to it with either P2C or OP_RETURN commitments. This proof is passed then to Bob and kept in this stage. Nobody else except Bob know where the bound asset, owned by Bob, resides.
2. "Spent proof": when Bob needs to spend (part of) the asset to Carol, he changes the proof structure in the following way:
   • removes original HMAC_SHA256 and replaces it with explicit txid:vout information
   • spends the UTXO to which the proof was bound, making public_key explicitly available in bitcoin blockchain to everybody who knows the original UTXO (at this point nobody except Bob himself

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?

[inaltoasinistra]

Original payee, Alice, still do not know which UTXO was used.

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. This operation is cheap, a bitcoin node uses more resources

[dr-orlovsky]

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.

[inaltoasinistra]

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

[dr-orlovsky]

After the team meeting at @inbitcoin it was decided to abandon this change, since a) it does provide very limited temporally privacy trading on a lot of complexity b) if the privacy is the concern, its better to adapt some best practices from zero-knowledge proofs, like in confidential assets.