Possible conflict of pay-to-contract schemes with Taproot about spec HOT 18 CLOSED

Taproot is the most obvious, but, if other schemes also use pay-to-contract similarly, again a UTXO committing to an RGB proof may itself be reinterpreted as committing to a different pay-to-contract scheme contract. I have a thread on bitcoin-dev awaiting moderation about the reinterpretation problem. I believe the general solution is to adjust the tweak to:

Q = P + H(P || S || C) * G

Where S is a scheme ID (32 bytes/256 bits) that is unique to the scheme. The contract C is to be interpreted according to the scheme S.

In short, pay-to-contract must commit, not only to the contract itself, but to how the contract is to be interpreted.

from spec.

Thread on bitcoin-dev: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016354.html

from spec.

I really have to catch up on Taproot since I don't know much about it, but my initial impression is that doing this would require to break an hash function: in our pay-to-contract scheme we would only commit to the hash of a proof, and many of its fields are controlled by the "sender" (which, if I understood correctly, should be the victim in the model you described).

So, the attacker would have to craft and "address" such that, once embedded into a proof (possibly with some data he doesn't know yet) will make the hash of the proof an executable, malicious, Bitcoin SCRIPT.

Now I'll go study and come back later when I fully understand how Taproot works ;)

PS: if you have any good references/articles please let me know here or via DM at twitter.com/afilini

from spec.

Oh, and about your suggestion of making small Bitcoin amounts: I was thinking about it while writing the slides for the Berlin Lightning hackday a couple of days ago.. Speaking for the Lightning part, my idea was to force the payment of fees on the underlying Bitcoin layer, to reduce the amount of data we have to gossip around (we already have Bitcoin fees and asset/Bitcoin exchange rate).

In this model, in order to have proportional fees, you would need to use the exchange rate to estimate the value of the asset being moved in Bitcoin, and then apply the Bitcoin proportional fee to it.

If this is really what we end up doing (I honestly don't really like it but I don't have any other solution yet) you would need pretty "big" Bitcoin channels to transport "big" RGB proofs, otherwise you wouldn't have enough liquidity to move the tokens.

Link to the talk if you are interested: https://youtu.be/QrX1SpD6l9g?t=5h9m47s

from spec.

but my initial impression is that doing this would require to break an hash function: in our pay-to-contract scheme we would only commit to the hash of a proof

It may be possible to do so opportunistically. For instance, if the first two bytes of the hash are 0x4C 0x1E (OP_PUSHDATA1 30: push the next 30 bytes in the script as a single word on the stack), this results with high probability to a SCRIPT that pushes a truthy (nonzero) value on the stack, and is therefore anyone-can-spend with an empty witness stack. About 1 out of 65536 contracts will hash to a value that starts with those two bytes. Other reinterpretations to OP_PUSHDATA* opcodes may also be possible

Of course, it is possible that Taproot will also use a hash to further protect the Bitcoin SCRIPT and make such reinterpretation much harder with high probability. I have not seen enough details on the low-level of Taproot myself, perhaps it may also use a hash around the script before concatenating with the pubkey and hashing again. It may be useful to ask gmax or similar if this concern is unfounded.

from spec.

it is possible that Taproot will also use a hash to further protect the Bitcoin SCRIPT and make such reinterpretation much harder with high probability

No, I apologize, I am being daft here. If Taproot does use a hash and you also use a hash, and it is the same hash function, then the direct serialization of your proof might be reinterpreted as a direct serialization of a Bitcoin SCRIPT, and various values and codes you use in your proofs may correspond to particular Bitcoin SCRIPT opcodes that could lead to an easily-spendable Bitcoin SCRIPT.

In short: you may need to look very well into any concrete Taproot proposal that comes up in the future (there are none yet other than basic sketches).

from spec.

Yes, if the hash function is the same (and I think it would be likely), then it could become an issue.

As I said before, I think it would be hard to force the victim into unknowingly pay to a precise SCRIPT, but as you pointed out in many cases a big "family" of SCRIPTs can make you loose funds.

I guess I will keep this open as a reminder and to see if someone else has an idea to propose. Once Taproot will be finalized we will make sure there are no conflicts.

from spec.

I think it might make more sense to have the taproot-based p2c scheme be:

base pubkey: P
p2c: Q = P + H("rgb" || P || contract)*G
taproot scriptPubKey: R = Q + H(Q || "OP_RETURN")*G

So R = P + H("rgb"||P||contract)*G + H(Q||"OP_RETURN")*G

from spec.

That certainly seems a plausible solution aj.

from spec.

A possibility when using Taproot is to merge the OP_RETURN and pay-to-contract commitments, by having one script branch in the Taprooted MAST be an OP_RETURN script with the contract in the OP_RETURN. "Real" script alternatives can be placed in other leaves of the MAST; we simply add an additional one to contain the RGB contract.

Still, we must be careful that a RGB contract serialization may be interpretable as the serialization of another pay-to-contract system using the same technique. So we should use tagged sha just as in bip-taproot.

from spec.

Thread on bitcoin-dev: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016354.html

I do like this proposal, it looks workable @ZmnSCPxj, have you had any further thoughts on the topic since then?

from spec.

Comment by ajtowns seems better. Alternatively, given current taproot proposal it would be possible to embed a hash of the RGB contract in a taproot branch that is OP_RETURN, with a RGB-specific tagged hash function as per bip-taproot. The bip-taprrot tagged hash is effectively what I propose, i.e. making a prefix that is specific to each use case, except the bip-taproot tagged hash fleshes it out and considers efficient implementations.

from spec.

Alternatively, given current taproot proposal it would be possible to embed a hash of the RGB contract in a taproot branch that is OP_RETURN, with a RGB-specific tagged hash function as per bip-taproot.

Looks cool and sounds like a new commitment scheme for RGB. @giacomozucco, @afilini what do you think?

Comment by @ajtowns seems better.

Emm... I don't get why P + H("rgb" || P || contract)*G is anyhow better than P + H(P || contract)*G...

from spec.

Alternatively, given current taproot proposal it would be possible to embed a hash of the RGB contract in a taproot branch that is OP_RETURN, with a RGB-specific tagged hash function as per bip-taproot.

I see a problem here: double spend. It is possible to commit more then one RGB proofs into the taproot scripts tree. I don't see trivial solutions without affect privacy (i.e. include all the taproot scripts into the RGB proof)

from spec.

Emm... I don't get why P + H("rgb" || P || contract)*G is anyhow better than P + H(P || contract)*G...

The original problem pointed out that multiple pay-to-contract schemes may exist, not just RGB.

The extra H("rgb" | is intended to disambiguate, so that even if RGB contracts can written whose serialization is equivalent to the serialization of a contract in a different pay-to-contract scheme, if the other scheme uses a different prefix, it cannot be used to commit to multiple pay-to-contract schemes.

I see a problem here: double spend. It is possible to commit more then one RGB proofs into the taproot scripts tree.

You are correct and indeed the @ajtowns solution is strictly superior, as it avoids this issue.

from spec.

Got it and agree. Since I'm doing implementation of the complete RGB spec from scratch (here https://github.com/dr-orlovsky/rgb-rust) I'll add this to the code and also will do a PR to the spec itself.

from spec.

Seems like we need to add "RGB" prefix into the contract serialization as well (additionally to the actual PK tweak), in order to make the serialized contract code unambiguous. This prefix has to be included into the hash of the contract. I've already made this in code (see commit
rgb-archive/rust-rgb-2019@7a1e1ce above). I will add this to the spec as well.

from spec.

Closing, discussion shall continue in the new PR #73

from spec.