Possible double-spend with double-commitment

[dr-orlovsky]

It is possible to commit to both P2C and OP_RETURN at the same time, creating two different proofs. It can be fixed by requiring that transactions with P2C commitments must not contain OP_RETURN outputs.

[Giuzzilla]

I think that the proposed solution is unnecessarily limiting to the functioning of Bitcoin transactions, which should be as useful as possible for non-RGB-related usage: both for preserving block space and for hiding RGB commits among otherwise normal TXs, which is good for privacy.

It seems that it's possible to have OP_RETURN outputs in transactions with P2C commitments and at the same time avoid double-spending of RGB tokens in the following way:

You could achieve this by including in both the transfer and the emission proofs a specific (and mandatory) signalling of which method (P2C/OP_RETURN) to use in the next spend.

In this way only what was specified by the previous proof will be valid and all the transactions will be made in an unique way, starting from the emission of the asset.

Am I missing anything?

[fedsten]

Don't we already have to deterministically define the output containing the commitment anyway? If multiple proofs are committed in multiple outputs using either OP_RETURN or P2C it shouldn't really matter as only one is considered relevant.

[dr-orlovsky]

@fedsten P2C and OP_RETURN uses different commitment mechanics (according to the current spec): P2C uses fees, OP_RETURN — just the first OP_RETURN output. So this have to be changed if we'd like to prevent double-spend. We either should: 1) Deny OP_RETURN outputs for P2C contracts, as I proposed; 2) Use fees (or other deterministic single mechanism) for both, but in this case why we need the complexity of deterministic function + necessety of fee adjustments for those who have chosen more simple and explicit OP_RETURN? There will be no privacy gains at all...

[dr-orlovsky]

@Giuzzilla it seems that with your proposal the payer will define for the future payee which commitment scheme he should use when he will be spending assets — and I assume it can't be guessed even by the payee himself at the moment when he just receives the funds and not spends them.

[Giuzzilla]

@dr-orlovsky If I understood correctly what you are asking: once you receive a payment you get with it the "proofchain" history, and you know with certainty how you should commit the next proof. Most likely they will keep defining the same commitment scheme (e.g. P2C) without tweaking that option, but clients should be able to support both.

[fedsten]

@dr-orlovsky regarding option 2, since there is indeed no privacy anyway while using OP_RETURN, wallets could just assign the index of the OP_RETURN output based on what the optimal fee already estimated by the wallet determines, skipping therefore the extra fee adjustment step.

[dr-orlovsky]

@Giuzzilla No, I had a different objection. With the proposed scheme, the payee is limited with his options to spend the assets; basically he delegates this decision either to a payer – or need to communicate to the payer which commitment scheme he will use in the future, and he may not know at that point what would be the preferred option to him.

Basically, we need very strong reasons to limit the owner of the assets from choosing the commitment scheme at the moment when the assets are actually spent. So I think the originally proposed rule (if there is OP_RETURN in the tx, you can't use P2C) is a more preferable solution.

[dr-orlovsky]

@fedsten there is also an another consideration against using the same deterministic fuction for both OP_RETURN and P2C commitments: with P2C scheme you need to play with the fee, while there is no reason to do that for OP_RETURN: it is explicit, and transaction can't have more then a single OP_RETURN output (rule by Bitcoin Core), so why we need to add a complexity to it and use fees to point to the OP_RETURN in a deterministic fashion in the same way we need for P2C?

[inaltoasinistra]

If we would like to leave more flexibility we could change the constraint to

if there is OP_RETURN of 34 bytes in the tx, you can't use P2C

But I think OP_RETURN will be used less than today in the future

[fedsten]

transaction can't have more then a single OP_RETURN output (rule by Bitcoin Core), so why we need to add a complexity to it and use fees to point to the OP_RETURN in a deterministic fashion in the same way we need for P2C?

Actually transactions can have multiple OP_RETURN outputs, the Bitcoin Core software won't rely such transactions as they are considered non-standard, but they will still considered valid if found in a block. Therefore, as long as OP_RETURN is supported we still need to deal with the possibility of having multiple OP_RETURN outputs in a transaction.

[dr-orlovsky]

I think that's a possibility. BTW does anybody use OP_RETURN with other than 34 bytes which is a hash?

[dr-orlovsky]

After today's call it was decided to accept the proposal by @fedsten:

Both P2C and OP_RETURN commitment schemes will use the same deterministic function. If the result of the function will point OP_RETURN output, then it will signify OP_RETURN commitment scheme; otherwise P2C commitment will be implied.

Multiple OP_RETURN outputs in the commitment transaction are allowed; the only valid OP_RETURN for RGB commitment will be chosen on the basis of deterministic rule described above.