Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 13E76C0032 for ; Wed, 9 Aug 2023 13:13:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id ACA1D812AE for ; Wed, 9 Aug 2023 13:13:33 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org ACA1D812AE X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cn3jMfL3mH-2 for ; Wed, 9 Aug 2023 13:13:33 +0000 (UTC) X-Greylist: delayed 400 seconds by postgrey-1.37 at util1.osuosl.org; Wed, 09 Aug 2023 13:13:32 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 812D581289 Received: from farbauti.uberspace.de (farbauti.uberspace.de [185.26.156.235]) by smtp1.osuosl.org (Postfix) with ESMTPS id 812D581289 for ; Wed, 9 Aug 2023 13:13:32 +0000 (UTC) Received: (qmail 31884 invoked by uid 989); 9 Aug 2023 13:06:49 -0000 Authentication-Results: farbauti.uberspace.de; auth=pass (plain) Message-ID: <03551f0f-272e-2607-e95a-8ec671cbb9f3@murch.one> Date: Wed, 9 Aug 2023 15:06:49 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Content-Language: en-US To: bitcoin-dev@lists.linuxfoundation.org References: <00feb0f1-ec5a-4fc2-8bff-5acf8616e458@app.fastmail.com> From: Murch In-Reply-To: <00feb0f1-ec5a-4fc2-8bff-5acf8616e458@app.fastmail.com> Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Bar: -- X-Rspamd-Report: BAYES_HAM(-3) MIME_HTML_ONLY(0.2) X-Rspamd-Score: -2.8 Received: from unknown (HELO unkown) (::1) by farbauti.uberspace.de (Haraka/3.0.1) with ESMTPSA; Wed, 09 Aug 2023 15:06:49 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=murch.one; s=uberspace; h=from; bh=ynZ2RtArmJdMqS8sTFGcmOFWBEcrYq/NlGp4dpEf+ps=; b=H7SPW9vy4N9U2tYmqthn6fll78fI9/gwfnIzjpBj70EIkTdiTW5lQk5nOFJe+3moWPt9WUN0G6 tl4TofO6fLMDJzb12ui1q+rVMqRI26Hva7AxDBLnaS0Jsfh7SwKQa+aEjFKudg1x5uezhKZpl647 PmLuErPT0fZBTATAO81JY+68Fg5S0M4w2adkHuTqGmOGtAQaePgd2B7FyoK8lZzGuNY7XvhBzWtI GDWeThHRZdFRQBV5Cs6ZySs79Vzw/vl4fojHvRIT9ludOSOuBCR67OHhofEC9xh9YdXyCQU09Uts rEB9EOJPz7pysRcCj6xmu8fZBAPSAC10jNNaUp7eOawbqBbHl4I053n2c4wzjO3v+LlhXQkgkG4w ZnPAv+hmeqJSqaNhlCKAJw8oXa5wfChxF6oR2sOT+pQdU7QkcTU6WTZf8un1Tx/2fBnb5wwd5tHX Ok6x6hRxZt4EY8/M0899Df2JRx47ap0ME32BjHDsFpexjRmEff0aoH9ifP8l4/n8XJfyU55QBGCo fouIGGKY8xBPMPdBRG5wSBW9l+Z1F5VZyvs2VANe2KJl/gze/3hfPr31Evvxge6ZovIe3I1BGbOr msDyuW2rkBuF5VaUAoZf2y/1OZnN9bgW2hBVUD4865rvd1EvE62FHqb/w9a8SYVvCOmSC/38ISXn s= Subject: Re: [bitcoin-dev] Pull-req to remove the arbitrary limits on OP_Return outputs 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, 09 Aug 2023 13:13:34 -0000 Hi John,

On 2023-08-06 16:35, John Light via bitcoin-dev wrote:

is there ever a case where using OP_RETURN to embed data actually results in fewer bytes onchain than embedding the same data using the segwit/taproot witness space
Yes, a back-of-the-envelope calculation has me thinking that only payloads of 135 bytes would be cheaper with transcriptions than with nulldata outputs. In detail:

An OP_RETURN output has an overhead of 10 bytes: 8 bytes for the amount, and a byte each for output script length and OP_RETURN.

An inscription envelope requires a P2TR output and a P2TR scriptpath input as overhead. A P2TR output weighs 43 vB, a cursory glance suggests that the prevalent inscription input seems to be a depth 0 P2TR scriptpath spend where the leaf script consumes a signature via a CHECKSIG to be followed by the payload envelope. Compared to a P2TR keypath spend this adds something like 8 WU for the leaf script and envelope as well as 34 WU for the controlblock. A keypath spend takes 230 WU, so the total overhead of an inscription lands somewhere around 111 vB (the additional =E2=80=98ord=E2=80=99 label a= nd meta header with encoding information are considered part of the payload here). After that, the payload gets a discount of 75%.

Solving

=C2=A0=C2=A0 =C2=A0111 + 0.25*payload_size =3D 10 + payload_size
=

we learn that nulldata outputs are cheaper up to a payload size of 134 bytes, only above that inscriptions become a more blockspace efficient data carrier.

Further, tooling for OP_RETURNs should be more broadly available than software that creates inscriptions, so it seems to me that dropping this limit would make it cheaper to publish certain data payload sizes to the blockchain, and also make publication of larger payloads significantly more accessible. Anyway, it=E2=80=99s= not obvious to me why we should relax restrictions on publication mechanisms just because it=E2=80=99s already happening in a differe= nt manner (that also only uses blockspace but doesn=E2=80=99t add to t= he UTXO set). At that point this proposal neither seems to be a trivial mempool policy change, nor a clear or significant improvement. Especially it=E2=80=99s not clear to me, why we should encourage fu= rther data publication on the blockchain.

On 2023-08-06 16:35, John Light via bitcoin-dev wrote:

Are there any tools available that a full node operator could use to prune this data from their nodes?
Yes. Running your Bitcoin Core node in prune mode will discard nulldata outputs when it discards the block.

On 2023-08-06 16:35, John Light via bitcoin-dev wrote:

=C2=A0i) Is the unspendable output pruning implemented in PR #2791 on by default or is this a flag that needs to be enabled by full node operators? If it's a flag, what is the flag called and how can it be enabled? If it's on by default, how can it be disabled?

No other special pruning methods beyond pruning of blockchain data have been implemented in Bitcoin Core. Nor am I aware of any that have significant benefits over just pruning blockchain data.

On 2023-08-06 16:35, John Light via bitcoin-dev wrote:

=C2=A0=C2=A0 ii) If a full node operator do= es prune OP_RETURN outputs, does that in any way impair their ability to help a new node do IBD to validate the blockchain? And would that answer be any different if we were talking about pruning Taproot witness space (i.e. "envelopes" or "inscriptions") instead of OP_RETURN outputs?

A transaction from which inscription data or OP_RETURN data has been removed is incomplete and cannot be validated. If a node operator were to discard either data, they would not be able to serve complete blocks and therefore would no longer be able to assist in IBD.

Given that the proposal is obviously controversial, and the social media attention this and a few related pull requests have gotten is already causing brigading, I don=E2=80=99t think it=E2=80= =99s going to be a priority for me to further engage with this proposal.
Cheers,
Murch