From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 31511C0039 for ; Wed, 22 Nov 2023 11:27:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id ED26E4036E for ; Wed, 22 Nov 2023 11:27:20 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org ED26E4036E Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=CnRwch29 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tkapob0qJ1Er for ; Wed, 22 Nov 2023 11:27:19 +0000 (UTC) Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) by smtp2.osuosl.org (Postfix) with ESMTPS id 64C3A40138 for ; Wed, 22 Nov 2023 11:27:19 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 64C3A40138 Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-5cc3dd21b0cso8163577b3.3 for ; Wed, 22 Nov 2023 03:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700652438; x=1701257238; darn=lists.linuxfoundation.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cF5kDXkJzQb9j6n9LV+PBcIzTIoInTMe3TjOIxYVnwE=; b=CnRwch29jgPpS1iQg62fFgq+CucjMZAyWZaqw4PQZ7RmTpY/vC/x6/hkX0I1VWglgb JBPYcxqG+tcGR6XVQJ0PcgES791FJ1rE9ADDc9coyxRLsZS2cWLRR3uhcNuQEz7ARFEq s7+UrWcCrOi12Uj0je/dyoRT/Hptzgajm2smxjiXtv2jsJAH9xuT9AdK0gXN3l2sE6lF bigYZ778ZLRw+A7g9MtQLpjcbJtsUnfPihP/IxMKhjHA9NgD9VLb3euTxvvMtE1dJSTO wPcKdrxtXKN9Mmmifx6jsuR+d/QhEZOTkf3HMF4bKiFtSCdhRzC5oEhabhYZlpnGd2JX AD7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700652438; x=1701257238; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cF5kDXkJzQb9j6n9LV+PBcIzTIoInTMe3TjOIxYVnwE=; b=pvV4oiVqA+yRCOYICmQh4UDpcjzg1oNo3wDhhSrrlLW4WWlI3+w7lKTwWIkbLPKzuk II+sNIWJ8PsP7YK1TvJyrjgOWz/OOA/hdh40iEunN1kO9jDSZ5BRe/4s60e2H96rX0W3 V1y3XMRE+6rPiQO4qwq4SUMwUBHXMwFdVOL/lgKVRYgaJmDwPOzSQ9TjbKIv4VaV31z3 eIlXXk5KOfBWBgFTchGLncryFIVY0JTOK0OA11E4RUG1mZ5jgxUWm1OWhhKzeug9fyXQ 7PLgk7P8qPkfnpdHe08EhReLQkOBJ0qKP5LDcSl4SHJHBWRvpsBczCagbUAZZti4zEJn K5Vw== X-Gm-Message-State: AOJu0YyyBLBIxonl0TGaiLgFZK1jm+udaNfFVRzo5q5vh1CSZwfRcz+R KvYqKHmnBCAvK6E2OVY3NSUwaEkf7BXgyXi+SHU= X-Google-Smtp-Source: AGHT+IHkYO9uXvDqCTDCvcWjGNDGHO6b6EjYeYxkiD3xW565ZbrdipwC2vjOSZ4F1Ru9xez63s6pEC3bbmo309z3ZEU= X-Received: by 2002:a05:690c:408a:b0:5cc:8f6f:39c0 with SMTP id gb10-20020a05690c408a00b005cc8f6f39c0mr841126ywb.28.1700652438157; Wed, 22 Nov 2023 03:27:18 -0800 (PST) MIME-Version: 1.0 References: <196658683-e78610e544d8c89fc4432671990127cb@pmq1v.m5r2.onet> In-Reply-To: <196658683-e78610e544d8c89fc4432671990127cb@pmq1v.m5r2.onet> From: Kostas Karasavvas Date: Wed, 22 Nov 2023 13:27:03 +0200 Message-ID: To: vjudeu@gazeta.pl Content-Type: multipart/alternative; boundary="000000000000767e46060abc00ab" X-Mailman-Approved-At: Wed, 22 Nov 2023 11:37:07 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Nov 2023 11:27:21 -0000 --000000000000767e46060abc00ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 22, 2023 at 1:11=E2=80=AFAM wrote: > > Since it is spent it does not bloat the mempool. > > 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 coul= d > post 100 kB less, when it comes to regular payments. If you have Ordinals > in the current form, then they take place of regular payments. Which mean= s, > you can include some payment, or some data. You cannot include both, > because you can produce 4 MB block per 10 minutes. It is always a choice: > confirm this payment, or confirm that data. > > I meant the UTXO set, not the mempool. But still, even for the mempool, since tx fees are paid I don't see it as bloat. It is competing with the other txs and won. The bloat is of course in storage since the blocks are 'fuller' with ordinals... but that is the whole point of ordinals (see below). > > Regardless of OP_RETURN the data will be on chain. What am I missing? > > If you have regular OP_RETURN, the data is pushed on-chain. However, if > 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 > transaction outputs, but in that case, TapScript is revealed in transacti= on > 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 TapScript. > I see, thanks. > > If there was no need for people in this list to discuss it before I > don't see why a BIP is needed now. > > 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 > users a way, to compete with the currently posted Ordinals, in this > fee-based competition. Which means, regular users should have a way, to > turn their Ordinals into proper commitments. They should be hidden behind > some R-value, instead of being posted as a TapScript, and fully revealed = in > the witness. That would make it smaller, cheaper, and will provide more > room for more regular payments, while preserving the strong cryptographic= al > proof, that a given data is connected with a given transaction input. > > Also, it would allow them to be uncensorable, because then users could > decide to hide any Ordinal behind their signature, in any address type (i= t > works 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 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 > discarded, and the posted data is what people care about. Bitcoin is a > payment system first, and not a P2P cloud storage, so it should work as > "always a payment, and optionally also an Ordinal", and not "just a data > push, and unfortunately a payment, because the protocol forced us to > include some satoshis". > The whole point of ordinals is supposed to have the data on-chain (the ordinals team can correct me). You are not suggesting merely a technical design change, you are suggesting a completely different design and business logic, which I believe would never be accepted by the ordinals team*, and thus no point for this BIP now. We'll just have to wait for their reply and see. * This is fair game for a new competing project. However, the 'on-chain' part is the main ordinals selling point so a new project would not even be competing. --000000000000767e46060abc00ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Nov 22, 2023 at 1:11=E2=80=AFAM &= lt;vjudeu@gazeta.pl> wrote:
<= /div>
> 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 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.
=C2=A0

I meant the UTXO se= t, not the mempool. But still, even for the mempool, since tx fees are paid= I don't see it as bloat. It is competing with the other txs and won. T= he bloat is of course in storage since the blocks are 'fuller' with= ordinals... but that is the whole point of ordinals (see below).
=
=C2=A0
> Regardless of OP_RETURN the data will be on chain. What am I miss= ing?
=C2=A0
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.
=C2=A0
I see, thanks.
=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 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.
=C2=A0
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 = payment, and optionally also an Ordinal", and not "just a data pu= sh, and unfortunately a payment, because the protocol forced us to include = some satoshis".

The whole point of ordinals is suppo= sed to have the data on-chain (the ordinals team can correct me). You are n= ot suggesting merely a technical design change, you are suggesting a comple= tely different design and business logic, which I believe would never be ac= cepted by the ordinals team*, and thus no point for this BIP now. We'll= just have to wait for their reply and see.

* = This is fair game for a new competing project. However, the 'on-chain&#= 39; part is the main ordinals selling point so a new project would not even= be competing.

--000000000000767e46060abc00ab--