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_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
