Content-Type: multipart/alternative;
 boundary="===============5271140119223292099=="
MIME-Version: 1.0
From: vjudeu@gazeta.pl
To: Casey Rodarmor <casey@rodarmor.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Date: Mon, 20 Nov 2023 23:20:46 +0100
Message-Id: <196446418-e1135f5da0a7baa7dc932feecf123170@pmq3v.m5r2.onet>
Subject: Re: [bitcoin-dev] Ordinals BIP PR
Precedence: list

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

> I've commented a few times asking the BIP editors to let me know what is =
needed for the BIP to either be merged or rejected.
I would accept it, if each Ordinal would require including OP_RETURN at the=
 beginning of the TapScript, to prevent them from being pushed on-chain. In=
 that case, they could still be moved by a single Schnorr signature. Or, ev=
en better, creating a new Ordinal should not require sending them to Taproo=
t at all, but just the R-value of a signature, from any address type, shoul=
d be sufficient to make a commitment.
Which means, if some user has some legacy address, then it should be possib=
le to sign a regular transaction, and then, R-value of that signature could=
 contain some Ordinal.
Also, Ordinals should support scanning the chain in a similar way as Silent=
 Payments could do. Which means, users should not be forced to upload data,=
 if they were already uploaded in a different form. For example, there was =
a user, trying to upload the whitepaper, even though it was already done, a=
nd it was wrapped in a multisig in some old transaction. Which means, Ordin=
als should allow scanning the chain, and discovering old data, without rein=
venting the wheel, and forcing users to post that data again on-chain.
Another thing to address is the content of each Ordinal: some people tried =
to create something like NFT. In that case, the uniqueness should be enforc=
ed. And by scanning the chain for similar data, it should note that "hey, t=
he whitepaper was already pushed by someone, in a multisig, long time ago",=
 so the Ordinals protocol should prevent users from uploading the same data=
 again, and again. Because in some use cases, like NFTs, it could be mislea=
ding.
--===============5271140119223292099==
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<div>
<div>&gt; I've commented a few times asking the BIP editors to let me know =
what is needed for the BIP to either be merged or rejected.</div>
<div><br />I would accept it, if each Ordinal would require including OP_RE=
TURN at the beginning of the TapScript, to prevent them from being pushed o=
n-chain. In that case, they could still be moved by a single Schnorr signat=
ure. Or, even better, creating a new Ordinal should not require sending the=
m to Taproot at all, but just the R-value of a signature, from any address =
type, should be sufficient to make a commitment.</div>
<div><br />Which means, if some user has some legacy address, then it shoul=
d be possible to sign a regular transaction, and then, R-value of that sign=
ature could contain some Ordinal.</div>
<div><br />Also, Ordinals should support scanning the chain in a similar wa=
y as Silent Payments could do. Which means, users should not be forced to u=
pload data, if they were already uploaded in a different form. For example,=
 there was a user, trying to upload the whitepaper, even though it was alre=
ady done, and it was wrapped in a multisig in some old transaction. Which m=
eans, Ordinals should allow scanning the chain, and discovering old data, w=
ithout reinventing the wheel, and forcing users to post that data again on-=
chain.</div>
<div><br />Another thing to address is the content of each Ordinal: some pe=
ople tried to create something like NFT. In that case, the uniqueness shoul=
d be enforced. And by scanning the chain for similar data, it should note t=
hat "hey, the whitepaper was already pushed by someone, in a multisig, long=
 time ago", so the Ordinals protocol should prevent users from uploading th=
e same data again, and again. Because in some use cases, like NFTs, it coul=
d be misleading.</div>
</div>

--===============5271140119223292099==--