From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Reinterpretations of contracts in different pay-to-contract schemes
Date: Mon, 03 Sep 2018 09:26:35 +0000 [thread overview]
Message-ID: <as13xXV08xcjwms8bpl8TJF-G0RgUBTEK_Q8jqxQ742Yc-w3jpQjeJf0tTQXogcPsHF7uEV2TYy6eF8jF9JQNrKOMlf5vWuDSMVDUdao5Nw=@protonmail.com> (raw)
[-- 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 --]
reply other threads:[~2018-09-03 9:26 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='as13xXV08xcjwms8bpl8TJF-G0RgUBTEK_Q8jqxQ742Yc-w3jpQjeJf0tTQXogcPsHF7uEV2TYy6eF8jF9JQNrKOMlf5vWuDSMVDUdao5Nw=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox