giacomozucco
commented
5 years ago First of all, let's make explicit the rationale for the UTXO-based option: block-space use minimization for the asset scheme (which is generally good for scalability and for privacy as well).
This is the typical scenario: Alice wants to send some RGB assets to Bob, but she also already intends to spend, for whatever reason in principle unrelated to RGB assets at all (ie: Bitcoin payment to Carol, LN channel opening/closing, CoinJoin, UTXO consolidation, etc.) some of her Bitcoin UTXOs. The first level of optimization she could adopt, using the address-based option only, would be just batching, including Bob's address, with a trivial (but above-dust) amount of sats, among the other outputs. But an even superior level of optimization can be reached with the UTXO-based approach.
Instead of an address, Bob gives Alice one of his UTXO, serialized. Alice, then, produces an RGB proof moving the ownership of some assets to that UTXO. She takes the RGB proof and she makes commit to it, using the pay-to-contract scheme, one of the addresses which she controls the private key of, among the set of outputs in her ALREADY PLANNED Bitcoin transaction (typically the change output, which is supposed to be likely there anyway...but not necessarily, since LN channels could provide other less trivial examples of Alice-controlled outputs). Now, Alice can broadcast the on-chain Bitcoin transaction she already wanted to broadcast (with one output opportunely tweaked to commit to the proof) and send the RGB proof (together with the entire, asset-specific, RGB "proof-chain") directly to Bob via Bifröst.
In principle, Alice could also use an address which she DOESN'T control the private key of, starting from Carol's public key for example, but that would require her to somehow make Carol aware of the new UTXO so produced, of the necessity for her to tweak her private key with a message, and of the message itself. This could be quite complex in practice. But it's safe to assume most Bitcoin transactions would include Alice's change address anyway.
First important caveat: it's paramount that everybody (not just for Bob, otherwise asset could be double-spent) can uniquely determine WHICH output, if any, contains the RGB commitment. The position of the output containing the commitment doesn't have to be fixed (it shouldn't be, in order to keep RGB compatible with different ordering logics without breaking down), but it must be publicly and deterministically certain and unique (of course ASSUMING that Bitcoin transaction is also anchoring an RGB transaction, nobody except for BOB can actually know if that's really the case). Secondo important caveat: since Alice tweaked the public key used to produce one of her addresses, her software will have to store/backup the RGB proof (or its hash), at least until she will spend sats again from said address, since she will have to tweak the private key accordingly. Bob, in turn, when he will want to move the assets further on-chain, will just have to spend that UTXO he gave to Alice, committing into some of the outputs of the same transaction.
It's noteworthy that the pay-to-contract commitment scheme, as designed in current specs, do not suffer from reply-attack risks under this scenario, being non-invertible (https://github.com/rgb-org/spec/blob/master/01-rgb.md#public-key-tweaking).
dr-orlovsky
The current spec provides two options to specify the receiver: with UTXO-based output and address-based. The first form allows paying to some existing UTXO, while the second requires a new address to be generated by the payee (see https://github.com/rgb-org/spec/blob/master/01-rgb.md#address-based-vs-utxo-based for more details).
However, when combined with pay-to-contract scheme, the receiving UTXO will be no more tweaked, so the whole design consideration for the pay-to-contract gets broken here...