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 

I thought of this a little while ago and mentioned it 

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 

bitcoin-dev mailing list

Reply via email to