Content-Type: multipart/alternative;
 boundary="===============6943333024461161345=="
MIME-Version: 1.0
From: vjudeu@gazeta.pl
To: Kostas Karasavvas <kkarasavvas@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Date: Wed, 22 Nov 2023 00:10:55 +0100
Message-Id: <196658683-e78610e544d8c89fc4432671990127cb@pmq1v.m5r2.onet>
Subject: Re: [bitcoin-dev] Ordinals BIP PR
Precedence: list

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

> Since it is spent it does not bloat the mempool.
=C2=A0
This is not the case. If you post some 100 kB TapScript, with some Ordinal,=
 then it of course bloats mempools, because then other users could post 100=
 kB less, when it comes to regular payments. If you have Ordinals in the cu=
rrent form, then they take place of regular payments. Which means, you can =
include some payment, or some data. You cannot include both, because you ca=
n produce 4 MB block per 10 minutes. It is always a choice: confirm this pa=
yment, or confirm that data.
=C2=A0
> Regardless of OP_RETURN the data will be on chain. What am I missing?
=C2=A0
If you have regular OP_RETURN, the data is pushed on-chain. However, if you=
r OP_RETURN is part of your TapScript, then you cannot provide any valid in=
put to satisfy that kind of TapScript, so it cannot be pushed on-chain. Whi=
ch means, you have to use another TapScript branch, without OP_RETURN, or s=
imply spend by key. Note that regular OP_RETURNs are placed in transaction =
outputs, but in that case, TapScript is revealed in transaction input (and =
to be more specific, in the witness part), which prevents from posting a co=
mmitment on-chain, if it contains OP_RETURN at the beginning of the TapScri=
pt.
=C2=A0
> If there was no need for people in this list to discuss it before I don't=
 see why a BIP is needed now.
=C2=A0
It is needed, but for a different reason. There should be a BIP, but not to=
 promote Ordinals, but to handle them properly, and to provide regular user=
s a way, to compete with the currently posted Ordinals, in this fee-based c=
ompetition. Which means, regular users should have a way, to turn their Ord=
inals into proper commitments. They should be hidden behind some R-value, i=
nstead of being posted as a TapScript, and fully revealed in the witness. T=
hat would make it smaller, cheaper, and will provide more room for more reg=
ular payments, while preserving the strong cryptographical proof, that a gi=
ven data is connected with a given transaction input.
=C2=A0
Also, it would allow them to be uncensorable, because then users could deci=
de to hide any Ordinal behind their signature, in any address type (it work=
s even on P2PK), and then reveal it later, but not on-chain, to not take a =
room of other regular payments. In general, transactions should always cont=
ain payments, and Ordinals could be attached as a feature, and not the othe=
r way around, when the actual payment is just a feature to be discarded, an=
d the posted data is what people care about. Bitcoin is a payment system fi=
rst, and not a P2P cloud storage, so it should work as "always a payment, a=
nd optionally also an Ordinal", and not "just a data push, and unfortunatel=
y a payment, because the protocol forced us to include some satoshis".
--===============6943333024461161345==
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<div>
<div>&gt; Since it is spent it does not bloat the mempool.</div>
<div>&nbsp;</div>
<div>This is not the case. If you post some 100 kB TapScript, with some Ord=
inal, then it of course bloats mempools, because then other users could pos=
t 100 kB less, when it comes to regular payments. If you have Ordinals in t=
he current form, then they take place of regular payments. Which means, you=
 can include some payment, or some data. You cannot include both, because y=
ou can produce 4 MB block per 10 minutes. It is always a choice: confirm th=
is payment, or confirm that data.</div>
<div>&nbsp;</div>
<div>&gt; Regardless of OP_RETURN the data will be on chain. What am I miss=
ing?</div>
<div>&nbsp;</div>
<div>If you have regular OP_RETURN, the data is pushed on-chain. However, i=
f your OP_RETURN is part of your TapScript, then you cannot provide any val=
id input to satisfy that kind of TapScript, so it cannot be pushed on-chain=
. Which means, you have to use another TapScript branch, without OP_RETURN,=
 or simply spend by key. Note that regular OP_RETURNs are placed in transac=
tion outputs, but in that case, TapScript is revealed in transaction input =
(and to be more specific, in the witness part), which prevents from posting=
 a commitment on-chain, if it contains OP_RETURN at the beginning of the Ta=
pScript.</div>
<div>&nbsp;</div>
<div>&gt; If there was no need for people in this list to discuss it before=
 I don't see why a BIP is needed now.</div>
<div>&nbsp;</div>
<div>It is needed, but for a different reason. There should be a BIP, but n=
ot to promote Ordinals, but to handle them properly, and to provide regular=
 users a way, to compete with the currently posted Ordinals, in this fee-ba=
sed competition. Which means, regular users should have a way, to turn thei=
r Ordinals into proper commitments. They should be hidden behind some R-val=
ue, instead of being posted as a TapScript, and fully revealed in the witne=
ss. That would make it smaller, cheaper, and will provide more room for mor=
e regular payments, while preserving the strong cryptographical proof, that=
 a given data is connected with a given transaction input.</div>
<div>&nbsp;</div>
<div>Also, it would allow them to be uncensorable, because then users could=
 decide to hide any Ordinal behind their signature, in any address type (it=
 works even on P2PK), and then reveal it later, but not on-chain, to not ta=
ke a room of other regular payments. In general, transactions should always=
 contain payments, and Ordinals could be attached as a feature, and not the=
 other way around, when the actual payment is just a feature to be discarde=
d, and the posted data is what people care about. Bitcoin is a payment syst=
em first, and not a P2P cloud storage, so it should work as "always a payme=
nt, and optionally also an Ordinal", and not "just a data push, and unfortu=
nately a payment, because the protocol forced us to include some satoshis".=
</div>
</div>

--===============6943333024461161345==--