[bitcoin-dev] Reinterpretations of contracts in different pay-to-contract schemes

[bitcoin-dev] Reinterpretations of contracts in different pay-to-contract schemes

[ZmnSCPxj]

[-- Attachment #1: Type: text/plain, Size: 1704 bytes --]

Good morning all,

I am wondering if there is the possibility of an issue arising when different pay-to-contract schemes are used on Bitcoin.

Specifically, I wonder, if it may be possible to reinterpret the byte serialization of a contract under one scheme as the byte serialization of a different contract under another scheme.  The user may expect to have committed to a contract under the first scheme, but is rudely made aware that she has also committed to a different contract under a scheme she is unaware of.

For instance, if some independent protocol uses pay-to-contract, it may be possible for the contract to be reinterpreted as a Bitcoin SCRIPT under Taproot, leading to a contract that can be reinterpreted as a Bitcoin SCRIPT and allowing a Bitcoin-level UTXO to be stolen without knowledge of the private key.

I thought of this a little while ago and mentioned it here:https://github.com/rgb-org/spec/issues/61

Now, it may be possible to use the hash of the contract, but if Taproot uses a hash of the script also and the same hash function is used, then the bytes of the contract could be reinterpreted as a Bitcoin SCRIPT program, possibly leading to a trivial-to-solve SCRIPT with enough hacking.

If this is indeed a concern, then I propose, that pay-to-contract schemes should pay to the below tweak:

     Q = P + SHA256d(P || Scheme || C) * G

Where `Scheme` is 256 bits (32 bytes) scheme identifier.  For Taproot, it could be the genesis block ID.  Then other pay-to-contract schemes must ensure that they use a `Scheme` ID that is different with high probability from other `Scheme` IDs, in order to ensure that reinterpretation of contracts is impossible.

Regards,
ZmnSCPxj

[-- Attachment #2: Type: text/html, Size: 2071 bytes --]