From: vjudeu@gazeta•pl
To: Anthony Towns <aj@erisian•com.au>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: Casey Rodarmor <casey@rodarmor•com>
Subject: Re: [bitcoin-dev] Purely off-chain coin colouring
Date: Mon, 20 Nov 2023 20:47:13 +0100 [thread overview]
Message-ID: <196556244-f24094b55827d9a09fa29ca8aa04b163@pmq1v.m5r2.onet> (raw)
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]
> Sign-to-contract looks like:
Nice! I think it should be standardized as some informational BIP. This is a similar case as with Silent Payments: it is possible to let users make their own commitments as they please, but if it will be officially standardized, then it will be possible to build more protocols on top of that, in a way which will be understood properly by other nodes.
Before, I thought about interpreting signature R-value just as a Taproot-based public key, and forming a commitment as a valid input, that would allow moving coins on such address, but maybe we could standardize it in a simpler way than that. In general, if a commitment would allow pushing any data, it could be always extended when needed, because future commitments could be always nested in the old ones, 32 bytes is enough to do that.
Also, I thought about including OP_RETURN at the beginning of each commitment, to make sure it will be never pushed on-chain, but only stored and processed off-chain. Another thing is that r-value is always expressed as some 256-bit number, even in DER encoding, which means we can always assume 02 public key prefix in all commitments, and simply convert it directly into a proper Taproot address.
[-- Attachment #2: Type: text/html, Size: 1346 bytes --]
next reply other threads:[~2023-11-20 19:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-20 19:47 vjudeu [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-02-03 6:39 Casey Rodarmor
2023-02-04 10:38 ` Anthony Towns
2023-02-04 11:36 ` Aymeric Vitte
2023-02-04 13:02 ` alicexbt
2023-02-04 13:06 ` Peter Todd
2023-11-17 7:58 ` Anthony Towns
2023-02-02 9:15 Anthony Towns
2023-02-02 12:19 ` Aymeric Vitte
2023-02-02 13:46 ` Rijndael
2023-02-02 14:22 ` alicexbt
2023-02-02 14:30 ` Peter Todd
2023-02-02 16:06 ` Aymeric Vitte
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=196556244-f24094b55827d9a09fa29ca8aa04b163@pmq1v.m5r2.onet \
--to=vjudeu@gazeta$(echo .)pl \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=casey@rodarmor$(echo .)com \
/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