path: root/f2/3a764804ec233b14ac153a604502beaeaab50b

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 47682C0039
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Nov 2023 23:11:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 1CEAC60F93
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Nov 2023 23:11:11 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 1CEAC60F93
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl
 header.a=rsa-sha256 header.s=2013 header.b=Sr4g//76
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level: 
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5
 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id JB4A79IONOwD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Nov 2023 23:11:09 +0000 (UTC)
Received: from smtpo45.poczta.onet.pl (smtpo45.poczta.onet.pl
 [213.180.142.176])
 by smtp3.osuosl.org (Postfix) with ESMTPS id A620060F91
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Nov 2023 23:11:08 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org A620060F91
Received: from pmq1v.m5r2.onet (pmq1v.m5r2.onet [10.174.32.67])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4SZg902rs7zlgF2V;
 Wed, 22 Nov 2023 00:11:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1700608260; bh=4eohNE5Z8yzuhb6380A3XhcH8LTExQlFvfIk+Ug3tJg=;
 h=From:To:Date:Subject:From;
 b=Sr4g//76KtWuF9EYoPqAPcDZNha+ZejZzVy3iM5vXM21kL0xvJzQRm4eKYF/UM51b
 CkNNXVlLnOvym+djyeOwbgQ1v/auH974qNkMjQim5iUbN2/qNlDdvjsq6Gviw+ckCJ
 2LLyN+5gF8YXn/V9ZzO8GHeqY2xKvqusn/Ko+EB4=
Content-Type: multipart/alternative;
 boundary="===============6943333024461161345=="
MIME-Version: 1.0
Received: from [5.173.233.111] by pmq1v.m5r2.onet via HTTP id ;
 Wed, 22 Nov 2023 00:11:00 +0100
From: vjudeu@gazeta.pl
X-Priority: 3
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>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.233.111;PL;2
X-Mailman-Approved-At: Wed, 22 Nov 2023 11:37:07 +0000
Subject: Re: [bitcoin-dev] Ordinals BIP PR
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Nov 2023 23:11:11 -0000

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==--