Content-Type: multipart/alternative;
 boundary="===============4943912933812360673=="
MIME-Version: 1.0
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>
Date: Mon, 20 Nov 2023 20:47:13 +0100
Message-Id: <196556244-f24094b55827d9a09fa29ca8aa04b163@pmq1v.m5r2.onet>
Cc: Casey Rodarmor <casey@rodarmor.com>
Subject: Re: [bitcoin-dev] Purely off-chain coin colouring
Precedence: list

This is a multi-part message in MIME format.
--===============4943912933812360673==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

> Sign-to-contract looks like:
=C2=A0
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 th=
eir own commitments as they please, but if it will be officially standardiz=
ed, then it will be possible to build more protocols on top of that, in a w=
ay which will be understood properly by other nodes.
=C2=A0
Before, I thought about interpreting signature R-value just as a Taproot-ba=
sed 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 simpl=
er 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.
=C2=A0
Also, I thought about including OP_RETURN at the beginning of each commitme=
nt, to make sure it will be never pushed on-chain, but only stored and proc=
essed 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 p=
ublic key prefix in all commitments, and simply convert it directly into a =
proper Taproot address.
--===============4943912933812360673==
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<div>
<div>&gt; Sign-to-contract looks like:</div>
<div>&nbsp;</div>
<div>Nice! I think it should be standardized as some informational BIP. Thi=
s is a similar case as with Silent Payments: it is possible to let users ma=
ke their own commitments as they please, but if it will be officially stand=
ardized, then it will be possible to build more protocols on top of that, i=
n a way which will be understood properly by other nodes.</div>
<div>&nbsp;</div>
<div>Before, I thought about interpreting signature R-value just as a Tapro=
ot-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 c=
ould be always nested in the old ones, 32 bytes is enough to do that.</div>
<div>&nbsp;</div>
<div>Also, I thought about including OP_RETURN at the beginning of each com=
mitment, 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 in=
to a proper Taproot address.</div>
</div>

--===============4943912933812360673==--