OP_RETURN without OP_RETURN

[nopara73]

With @MaxHillebrand we were brainstorming on how to ensure correct parameters without an OP_RETURN. So I share this idea here.

Background

In order to ensure the server doesn't lie about its parameters an OP_RETURN would store the hash of these params so if the server would cheat towards any user (give different information) then the users can detect it and refuse to sign the transaction, explained by @markblundeberg here: #21 (comment)

We basically treated all of those as one problem, and what we do is hash all the information into a commitment hash that gets put as OP_RETURN as the first output.

Idea

However in expense of one more communication round it's possible to omit the final OP_RETURN from the transaction itself. After the OP_RETURN transaction is signed then the server could give back the transaction to the players to prove that all players agreed on the round parameters and sign the transaction without the OP_RETURN, too.

Now this could work, but this can be simplified, and should be simplified as a malicious peer can broadcast that transaction with the OP_RETURN (not sure why would he do that but whatever.)

Here realize that there is no need for OP_RETURN at all. It's ok if instead of the OP_RETURN tx, the sever gives just the hash of the parameters to the players.
The players if find the hash correct give back a signature that only signs that hash (not a whole tx.)
Finally the server gives all the param hash signatures to the client and the transaction itself.
If the players see that all the inputs signed the correct hash, then they sign the transaction, too.

Thoughts

I'm not sure one more communication round justify this change on Bitcoin Cash, as you can use block space in a more liberate way, but on Bitcoin it may make sense.

[markblundeberg]

Sounds like a decent idea! If there's something wrong about that, it's not immediately apparent to me.

[MaxHillebrand]

Good summary @nopara73.

One other idea we were brainstorming on that might work in several contexts where every user needs to verify that all users have the same message, single use seals might be a valuable tool to look into.

Here are the slides of the three day RGB conference where @dr-orlovsky covered the topic in depth.

[dr-orlovsky]

I think single use seals may be an overkill here and you can get the same result with a simpler construction: the commitment to parameters can be added to a public key inside any of a transaction outputs. You may check LNPBP-1, LNPBP-2 and LNPBP-3 standards on how to do that.

For more visual explanation you may check slide 6 here: https://github.com/LNP-BP/devcalls/blob/master/RGBCon0/RGB%20Con%200%20-%20Day%202.pdf

[nopara73]

Oh, there's no need for another communication round! Signing the hash of the params can be done when the input component is registered and then the transaction can be given out for signing with all the param signatures. As I see now, there's no drawback for doing this at all.

[fyookball]

I think in theory, if all players agree and sign over the OP_RETURN and then resign the same transaction (at the cost of an extra round), it might be ok. I'm not sure I see an issue with that yet. Of course, each client needs to fully validate the transaction is valid without broadcasting, which might be a heavy operation.

I'm not following the latest idea of "signing a hash of the params". Signed by who? This sounds like exactly the kind of thing that a malicious server can exploit as MITM. (pretend to sign as other players). Remember that UTXOs themselves cannot be used for signing as this is part of the information that must be hidden.

[nopara73]

Signed by who?

Every input.

Let me explain it as a whole:

When a user registers an input, he also sends a signature for the hash of the server parameters. The signature is created with the private key corresponding to the input itself.

When the server gives out the transaction for signing, he also sends out all the signatures for the server parameters.
So the user checks if every input signed the same server parameters as he did, before signing the final CJ.

[nopara73]

Remember that UTXOs themselves cannot be used for signing as this is part of the information that must be hidden.

I am still working on understanding the whole scheme, but the input component must be sent in at one point and the whole transaction must be signed by everyone at some point. So the only extension is to send a signature along with the input component, and refuse to sign if the tx does not accompany all valid signature for the params hash.

[fyookball]

When a user registers an input, he also sends a signature for the hash of the server parameters. The signature is created with the private key corresponding to the input itself.

Yeah it makes sense. Just adds complexity. Also, there are other MITM attacks the OP_RETURN prevents like the server spoofing the communication keys.

[nopara73]

Also in a light wallet it would pose an additional challenge to get the scriptPubKeys corresponding to the signatures, as light wallets don't have a UTXO database.