Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

From: Kostas Karasavvas <kkarasavvas@gmail•com>
To: Christopher Allen <ChristopherA@lifewithalacrity•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH
Date: Wed, 1 Feb 2023 10:36:52 +0200	[thread overview]
Message-ID: <CABE6yHtbgD_5kCHMu9P9ThbqRHnzXMERRZsu7_6H20CAcQuEww@mail.gmail.com> (raw)
In-Reply-To: <CACrqygD8ZF-PqKuFK7-SgiPdZQ9ewt+9QGXytpf8+NYjjNjyfA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2920 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4430 bytes --]