Increasing asset safety by combining commitment output with asset binding output

[dr-orlovsky]

1. If someone would like to protect RGB asset from an occasional loss due to a wrong wallet software being used, then a) use P2C commitments b) commit only to colored outputs c) this will disallow payments to existing address d) with multisig one will need to tweak all public keys of all participants

2. Otherwise, everybody are free to use OP_RETURN, pay to existing address or have «simple» multisig version with commitments stored in a (dummy) change output

To put this protocol enhancement forward we have the following options: A. Commit to the (dummy) change output always B. Commit to the first public key inside the script always C. Allow «safe» multisigs as an option for those who needs to with commitments in all public keys (i.e. all of them will be tweaked) D. Make «safe» multisigs the only possible option

«A» means we add just a tiny bit to bitcoin blockchain pollution (by increasing transaction size b/c of the additional transaction output in cases when there is no change) — but simplify the protocol, software. However, it will be possible to attack some of the non-symmetrial multisig wallets by burning RGB assets by the will of some (not all) of the multisig wallet owners

«B» does the same but w/o blockchain pollution, instead adding to the protocol complexity and requiring each time to create custom multisig wallet

«C» solves the safety issue allowing for thos who do not need it to failback to simple protocol like «A» and «B»

«D» is strictly safe, but most complex option, also requiring a multisig wallet to be used only once (it does not affect the blockchain size footprint though, just adding to wallet software and custodial policies complexity)

[dr-orlovsky]

@giacomozucco:

I disagree we should frame the change output as "dummy", necessarily. The idea of using change to include the commitment, imho, is the one in which we can actually optimize blockspace more in theory. My assumption is: for every kind of spending, including corporate multisig, the coinselection never allows for perfect match of amounts (pluss mining fees), so we have a very high probability to having the change output there ALREADY, for RGB-unrelated reasons. So, tweaking that one would have some advantages: we know the payer can spend it, since he was the one tweaking it, we don't add anything which was not there already, etc. One could say that, in a RGB transaction, also the output of the receiver is supposed to be there as well. But this is NOT actually the case. Indeed, if Bob is already planning to spend some UTXO in future, he can ask Alice to commit the assets into it, without actually adding ANY output to Txa...and Txa can be a transaction Alice was already planning to do for other reasons, where she just tweek some (deterministiccaly ordered) output, which happens to be her own change (likely there anyway, in most realistic scenarios where coinselection is not exact) with the commitment.

[afilini]

First of all, it's not correct that with option "A"

... it will be possible to attack some of the non-symmetrial multisig wallets by burning RGB assets by the will of some (not all) of the multisig wallet owners ...

The only way to burn RGB assets is by spending the UTXO which contains them (which is not the UTXO that cointains the commitment), and this can only be done if the Bitcoin spending conditions are met - whatever conditions they may be. If it's a 15/15 multisig, then all 15 people need to sign a transaction that spends the output, and they can burn the asst only if they all agree to do so.

Now, second misconception: it's not true that you need to tweak all the pubkeys in a multisig to provide what you call "safety". Tweaking even one pubkey completely changes the receiving address, so "normal" wallets won't even see transactions coming up (even if their pubkey is still there, untouched).

Also, talking about safety: I would argue that tweaking and then importing private keys actually reduces the safety of wallets, because it makes it even harder to backup your keys safely, while providing no other benefits (see the previous paragraph).

Even if all these points were not enough to convince you, there are a few other issues with your proposal of tweaking all the public keys:

1. What even is a public key? My answer would be "whatever is on the stack when a CHECKSIG opcode is called". This means that RGB would need its own fully Bitcoin-compatible script interpreter, because it's really not trivial (more like, impossible) to find with absolute certainty what is and what is not a pubkey just by looking at a script without entirely executing it.
2. Proofs would get bigger (linearly) because you would need to list all the pubkeys + the redeem script (compared to just one, constant, pubkey).

In my opinion there's no other way to get this right other than option "A". All the others are more complex, use more space, make it harder for people to backup their wallets, while at the same time they provide literally no other advantage over the simple single-sig output solution.

[dr-orlovsky]

@afilini, thanks for detailed thoughts.

The only way to burn RGB assets is by spending the UTXO which contains them (which is not the UTXO that cointains the commitment), and this can only be done if the Bitcoin spending conditions are met - whatever conditions they may be. If it's a 15/15 multisig, then all 15 people need to sign a transaction that spends the output, and they can burn the asst only if they all agree to do so.

Correct, that what I meant. From what you said it follows that if public keys in UTXO containing RGB assets are not tweaked, there is a way to spend bitcoins and "burn" RGB assets just by not creating an appropriate proof (like by using usual wallet).

Anyway, I'm fine with an option A, but because of #92 it seems we will use fees to define the tweaked output, and nothing will stop some wallets to point to the multisig (and not change) output; and because of #95 we need to support tweaking of P2WSH outputs in order to have Spectrum working, it looks like instead of hard-coding the way which output should be tweaked, we just need to put into the spec what should be done IF the P2WSH output was defined (by a fee) as a tweaked one: how to determine which public keys are tweaked there — and probably we need to add to the proof kind of tuple list [(key_index, original_pk)].

As regarding storing the redeem script in the proof, I think it is not necessary because the script can be deterministically constructed by RGB/Spectrum-supporting wallets for both multisig and Spectrum channel funding outputs.

[dr-orlovsky]

and because of #95 we need to support tweaking of P2WSH outputs in order to have Spectrum working

Sorry, actually not. Still not sure about multi-hop asset transfers (working on their design), but with direct transfers we can still stick with change outputs for Spectrum. So for now all available options looks like:

(I) We need to prohibit using non-P2(P)KH as a outputs storing tweaked keys, and if fee mod count(outputs) points to such output, consider it invalid (II) We need to put into specification how the proof can be checked if it points to P2(W)SH output.

[dr-orlovsky]

@afilini,

1. You were right, if we commit to P2(W)SH, we need to include the source of the script into the proof itself – and add full-fledged bitcoin script interpreter into a verifying RGB node – because we need to verify the proofs before corresponding RGB UTXO were spend, revealing the actual script – and before that we can't see the tweaked keys behind the script hash inside the P2(W)SH scriptPubKey.

2. We can't use commitments to P2(W)SH at this stage, b/c it introduces non-linear complexity to the proofs and commitments: additionally to what is mentioned above, we can't assume how it will be compatible with the future Shorrs/Taproots/Graphroots/Scriptless scripts and whatever – not talking about scripts that do not have public keys at all.

Today me and @giacomozucco had a phone discussion on these issues and we came to the following conclusion: at RGB/Spectrum v1 we need to use fee mod count(outputs) for deterministic definition of the output we are committing to with a given RGB proof, and do not exclude any non-P2(W)PKH outputs from the count(outputs) value – but for now (in v1) treat all proofs that commit to non-P2(W)PKH outputs as invalid, i.e these proofs will "burn" the assets inside them.

In the future (v2?), when we consider how to work with all possible cases of P2(W)SH and other possible (future) types of outputs, including all these beautiful Schnorrs-scriptless-tapgrafroots, we may "soft-fork" the spec and introduce new rule(s) that will not treat non-P2(W)PKH outputs as invalid, but will provide some options to interpret them. This is the only possible way forward, b/c if we do the other way around (exlude non-P2(W)PKH outputs from counting in v1), we will face a kind of "hard-fork" problem in the future introducing a way to double-spend RGB assets by exploring the fact that un-updated RGB nodes will not count non-P2(W)PKH outputs, and commit to the other outputs than updated RGB nodes – giving an ability to present different proofs depending to the nodes running different software versions.

This also affects/is affected by #92

[afilini]

Correct, that what I meant. From what you said it follows that if public keys in UTXO containing RGB assets are not tweaked, there is a way to spend bitcoins and "burn" RGB assets just by not creating an appropriate proof (like by using usual wallet).

There's always a way to spend bitcoins and burn RGB assets, tweaking keys won't protect you from that. What actually is useful to protect your money is using a different BIP-44 derivation path so that if you import your mnemonic in a standard wallet you won't even see the outputs.

we need to support tweaking of P2WSH outputs in order to have Spectrum working

No, you can just add an extra P2(W)PKH like you would do for normal on-chain transactions

we just need to put into the spec what should be done IF the P2WSH output was defined (by a fee) as a tweaked one: how to determine which public keys are tweaked there — and probably we need to add to the proof kind of tuple list [(key_index, original_pk)].

If you point to a non-P2(W)PKH output you lose your money, that's it. What I said in my previous comment is that it's very very hard to know for sure what blob of data in a script is even a public key, let alone its index, so it's better to entirely skip that imho.

As regarding storing the redeem script in the proof, I think it is not necessary because the script can be deterministically constructed by RGB/Spectrum-supporting wallets for both multisig and Spectrum channel funding outputs.

You are partially right: it's true that it's not needed, but for a different reason. Keep in mind that you not only need to prove the transfer to whoever receives your assets, but the proof needs to be verifiable by all the subsequent owners. So even if me and you can reconstruct the script, it doesn't mean that subsequent owners will be able to do the same. Luckily, if assets reach new owners, it means that they were spent on-chain, and this publicly reveals the redeemScript.

Anyways, you don't need that if you simply forbid to tweak complex scripts.