Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9B5B0C002B for ; Wed, 1 Feb 2023 08:37:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 836AA60BDE for ; Wed, 1 Feb 2023 08:37:05 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 836AA60BDE Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=SRRH65uU 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 smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-usLM8fK_wo for ; Wed, 1 Feb 2023 08:37:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 35F6760BB5 Received: from mail-yw1-x1129.google.com (mail-yw1-x1129.google.com [IPv6:2607:f8b0:4864:20::1129]) by smtp3.osuosl.org (Postfix) with ESMTPS id 35F6760BB5 for ; Wed, 1 Feb 2023 08:37:04 +0000 (UTC) Received: by mail-yw1-x1129.google.com with SMTP id 00721157ae682-506609635cbso236588447b3.4 for ; Wed, 01 Feb 2023 00:37:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Evj34jMX8euWK/OMnSx2quEdO7wGczA1tdKZgHzwIoo=; b=SRRH65uU4lQsdFYVXZManqopZKOGKauDj0ICfacL+kUhKswi3PQeLU3ODk2Vwjd5DZ HC5+f2LjiAC/nwlfXSFm85u1EoyQe0QX90tL9VpaHZootg+Tnee1M7cmGzfFAC6b63g1 6JPXFjStmmJ8Vu5P5zrBd5Jd0Icaw9/BtGGaMyz9497iZCnxQSfyDCRL2EprzXB9BrEf nUxhpKlpzEz1Pcd7g1mfgbw19jpBl2ky5IUhr2+51LqHNMi4HBRI72ce5+flIxcT/d3m Khqhd/kVtcLW31jgzqvTiYhQLHSbQK2pf+UbHBa73zjKqmgODagmOs6NYqXtT4Ji8stb 9A9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=Evj34jMX8euWK/OMnSx2quEdO7wGczA1tdKZgHzwIoo=; b=kVuzSpHDBEkdRxx6wkc58NbcG56U0tpv+93Nmq+PRwXkYJg2M0wbeAGZ5xSTxKnLdh a7B0CI5lIgPz5g7P3dLKT4jnnBVSl27qEtpt6IZ7diROyGxTGVkNLCKu8yxnjzcLGoNG Tm4mjriCwiJv2wXwYN/V2RatKOzXVQuDnV4iq1qOW3C2JG4qEW3hFP451hRncHo07POK 4y+ZV/q8f2J5UXMjW1ZfUmYpf++cApehfG+uJqchCgd6U9je7nLAaFHsABvU6cTjff9f +bu9XjTaCMzs4GWz/kvU4lsS8pYuV7XFinQXGb+SfgFqNWcnfo0XPgysWJdSIXVcHRh1 flqQ== X-Gm-Message-State: AO0yUKUiJRy0J3wWqz9vAVOt2D1gO8Wh3Fz3tJSPkhNCbeVVJv5umLCU XLYXjyWyjQt78BIa1IKbbdIhwpkhcFuuXarEBEM= X-Google-Smtp-Source: AK7set+RsiTNV78tEgyOq6Z8nx1turbYbbSadS8x+ZQD+1PuDt4bF9lMk+zi6L1ZV8Ywscbd3zTCyPJSo2xmuCqYZ0k= X-Received: by 2002:a81:6541:0:b0:4d7:eb11:6bf7 with SMTP id z62-20020a816541000000b004d7eb116bf7mr175330ywb.235.1675240622952; Wed, 01 Feb 2023 00:37:02 -0800 (PST) MIME-Version: 1.0 References: <764E460B-C0C6-47B8-A97E-F7CBC81FD645@petertodd.org> In-Reply-To: From: Kostas Karasavvas Date: Wed, 1 Feb 2023 10:36:52 +0200 Message-ID: To: Christopher Allen , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000003e96ad05f39f5a90" X-Mailman-Approved-At: Wed, 01 Feb 2023 14:08:38 +0000 Subject: Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH 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, 01 Feb 2023 08:37:05 -0000 --0000000000003e96ad05f39f5a90 Content-Type: text/plain; charset="UTF-8" With OP_RETURN you publish some data that are immediately visible in the blockchain. I would consider this better (more straightforward) for things like time-stamping. With Taproot you need to spend the utxo to make the script visible. This seems better when you don't want the data public but you need to be able to reveal the data when the time comes. Unless it is important to reveal later, it seems to me that for 80 bytes or less OP_RETURN is still the way to go post-taproot. On Wed, 1 Feb 2023, 04:30 Christopher Allen via bitcoin-dev, < bitcoin-dev@lists.linuxfoundation.org> wrote: > I don't have a concrete proposal in mind, I'm just trying to understand > various tradeoffs in post-taproot bitcoin in more detail. > > On Tue, Jan 31, 2023 at 6:07 PM Peter Todd wrote: > >> >> >OP_FALSE >> >OP_IF >> >OP_PUSH my64bytes >> >OP_ENDIF >> >> What's wrong with OpPush OpDrop? >> > > I'm not sure pro or con of either. I just saw that proposal above recently. > > >> Also, it is incorrect to say that OpReturn outputs "clog UTXO space". The >> whole point of OpReturn is to standardize a way to keep such outputs out of >> the UTXO set. There is the 75% discount to using witness space. But >> considering the size of a transaction as a whole using taproot instead of >> OpReturn doesn't save much. >> > > There are OP_RETURN tricks in production that do clog UTXO space. I was > trying to avoid consideration of those by just saying to compare apples vs. > apples, by presuming that any form of these transactions holding the 64 > bytes is a spent transaction. > > Finally, _64_ bytes is more than a mere 32 byte commitment. What specific >> use case do you actually have in mind here? Are you actually publishing >> data, or simply committing to data? If the latter, you can use ECC >> commitments and have no extra space at all. >> > > I chose 64 bytes for this exercise, as I know there are tricks hiding 32 > bytes as keys. As almost every op_return live out there is >32 bytes, I > wanted an example that could be a signature, two hashes, a hash plus some > metadata, etc. I also considered 96 bytes (for instance a hash and a > signature), but as that doesn't fit into OP_RETURN's 80 bytes, that choice > prohibits comparing the different approaches side-by-side. > > To come back to my question another way, if you ignore the people who say > "never put anything except data facilitating coin transactions into the > bitcoin blockchain", but if you also are not trying to use the bitcoin > blockchain as a world database (ala ETH), what is the most pragmatic way to > do so that minimizes any potential harm? The answer pre-taproot was > OP_RETURN. What is it now? > > -- Christopher Allen > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000003e96ad05f39f5a90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
With OP_RETURN you publish some data that are immedi= ately visible in the blockchain. I would consider this better (more straigh= tforward) for things like time-stamping.

With Taproot you need to spend the utxo to make the script visib= le. This seems better when you don't want the data public but you need = to be able to reveal the data when the time comes.
<= br>
Unless it is important to reveal later, it seems= to me that for 80 bytes or less OP_RETURN is still the way to go post-tapr= oot.



On Wed, 1 Feb 2023, 04:30 Christopher A= llen via bitcoin-dev, <bitcoin-dev@lists.linuxfoundation.org> wrote:
I don't have a concrete= proposal in mind, I'm just trying to understand various tradeoffs in p= ost-taproot bitcoin in more detail.

On Tue, Jan 31, 2023 at 6:07 = PM Peter Todd <pete@petertodd.org> wrote:

>OP_FALSE
>OP_IF
>OP_PUSH my64bytes
>OP_ENDIF

What's wrong with OpPush <data> OpDrop?

=
I'm not sure pro or con of either. I just saw that proposal = above recently.
=C2=A0
Also, it is incorrec= t to say that OpReturn outputs "clog UTXO space". The whole point= of OpReturn is to standardize a way to keep such outputs out of the UTXO s= et. There is the 75% discount to using witness space. But considering the s= ize of a transaction as a whole using taproot instead of OpReturn doesn'= ;t save much.

There are OP_RETURN trick= s in production that do clog UTXO space. I was trying to avoid consideratio= n of those by just saying to compare apples vs. apples, by presuming that a= ny form of these transactions holding the 64 bytes is a spent transaction.<= /div>

Finally, _64_ bytes is more than a mer= e 32 byte commitment. What specific use case do you actually have in mind h= ere? Are you actually publishing data, or simply committing to data? If the= latter, you can use ECC commitments and have no extra space at all.

I chose 64 bytes for this exercise, as I know= there are tricks hiding 32 bytes as keys. As almost every op_return live o= ut there is >32 bytes, I wanted an example that could be a signature, tw= o hashes, a hash plus some metadata, etc. I also considered 96 bytes (for i= nstance a hash and a signature), but as that doesn't fit into OP_RETURN= 's 80 bytes, that choice prohibits comparing the different approaches s= ide-by-side.

To come back to my question another w= ay, if you ignore the people who say "never put anything except data f= acilitating coin transactions into the bitcoin blockchain", but if you= also are not trying to use the bitcoin blockchain as a world database (ala= ETH), what is the most pragmatic way to do so that minimizes any potential= harm? The answer pre-taproot was OP_RETURN. What is it now?

=
-- Christopher Allen
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--0000000000003e96ad05f39f5a90--