From mboxrd@z Thu Jan 1 00:00:00 1970 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>> Since it is spent it does not bloat the mempool.</div> <div> </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> </div> <div>> Regardless of OP_RETURN the data will be on chain. What am I miss= ing?</div> <div> </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> </div> <div>> 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> </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> </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==--