path: root/c1/39e5f227259d88b136edc924ee12e4960634a0

Delivery-date: Fri, 18 Apr 2025 06:52:10 -0700
Received: from mail-oi1-f189.google.com ([209.85.167.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDL4XL646QOBBAFSRHAAMGQE4UQ2H2A@googlegroups.com>)
	id 1u5m8X-0002wD-9M
	for bitcoindev@gnusha.org; Fri, 18 Apr 2025 06:52:10 -0700
Received: by mail-oi1-f189.google.com with SMTP id 5614622812f47-3feb1dce9cesf553151b6e.1
        for <bitcoindev@gnusha.org>; Fri, 18 Apr 2025 06:52:09 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1744984323; cv=pass;
        d=google.com; s=arc-20240605;
        b=OU19GApyecG76XQzs6FuDsEBIYrGaHg5oavrJbfhpIWfYyzemhmLTgjrA7tHzMAYQz
         QAlq4GARRsg8uWoWuMz1ZVV3yQnff9Nt2Jb+RVUK/3Ok9gvs/UPvt/2M5kxIKbRP8T2Z
         Hlcl/ATupHi446gpHVbbYRtBEcqb4SV8FaypxJi8+VmB7MEP6V+dBp6Mx8jmSb2rICOp
         TBRdTIAbycKmFbTEHrd2ptkjOUJ7NTbqgb54A4b2hqA5c5ubWKDeV0XUYJSvAyLvDv9y
         dYCWLlL88mRCQkUjT6okhurvyzSeYzRKrpYwls8WobmjJ6igV4L31tNhHtiDu5SIhNAy
         JbUg==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id
         :references:in-reply-to:message-id:subject:cc:from:to:date
         :dkim-signature;
        bh=tz6srgtk3AzGLEqhTGenyXkOOQ/LBFjcRoNnZ+PetsY=;
        fh=rqGqoVsiET2MzVWUhQs9DwFf9DR86zAwXTT/423sN44=;
        b=SOkaVQ26/B6JMUWhf2Y/ClX65pjyI/gf8K2i3JcrtNQGhlw6tiDLskKdOczedRm9V3
         W7EdZphKldvVJaJRd4SmWqZ/CrDLZ54aF54f5CwjImbOAIRqyhla6Tw8VHu5T580LMID
         dFE359BJbrvpNOkmwPMS482WUeXcumfeH5t0NIwCEl6DDKROYu20xKs43CWHu4n+E7gG
         JOUPzXjBB9Q6W9pPQC0Iss5byGx5p7M7iRdI+jOgVcfVvpRxlETae8ZvwCN14wHQmdB5
         l/4i8nTXN59JNjHTHda6gcLlkl25rP6s/L6kSTAgD4Tb+SwvmMYIiWwp/Pso3z5Lo9Y3
         Y+kw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=g5KNVrUA;
       spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.28 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1744984323; x=1745589123; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=tz6srgtk3AzGLEqhTGenyXkOOQ/LBFjcRoNnZ+PetsY=;
        b=g8eAeiPN7uisFyxW9fqyKlZqlXImzsmqkG2Ay29n7MuEB55d2IVT9E8ANnoPAqKaXe
         labLzAVdXA/ksZYQbUCF0YtYtF++jLfoz9FXotl5d2b6eTMHHUbyCxTzVfdziTCA1kmA
         S3hVb0dZx50uiARtxwCkpqfFlzWUbwp79oAy5MQPI+e0iEhebzTDlQoFwHVfTSSmFHfy
         9zlkakdhwn559uvSjRkvvMaLJk76z4cphoGSTeq7i6inshpsxEI4Ai3F6QiDvIcl/vDF
         xAxqHS2w+rtLVMRo3hRppMKgBD6QNYIOiGqTioqm60bpOIIdmLqbsd0r8zqbv7ghuJp3
         W07g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1744984323; x=1745589123;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=tz6srgtk3AzGLEqhTGenyXkOOQ/LBFjcRoNnZ+PetsY=;
        b=gdZGxtEnhS6QvEva/6WOko14rgVKY5rGDlc4zzQCPW3rYNlWSjTAtEJtnCpM0AMjdS
         319gL9nQqVfrLzJhm4kiAt/E8E1iBCaQtOYHWCuZrW1to5Nlicb3XzOw/JMeLzXO0F/5
         4MIY09CB2NUi8rEMyZm9zaJOk7bH7l4+sC4I0NzGZjcp96JGeVzGgwdTQNa+stN1p0lx
         AvC/BEtgnI/LDyQnw276RVTnmnUbyHxmniEkscmGAc2JSOJP5lxVnN0JyNx95GfauqPp
         XUgKQVXse1r3HIF/vrm0IYvS04Mm0iBz/WCDx4Zi+Omt4ORDwd8oOrp6eK9Pjeyb27pM
         vRpQ==
X-Forwarded-Encrypted: i=2; AJvYcCWJc5Zb19tRyXLDBIPQ9dn6iDGz037miuiV2oJ5bdIeG7SD7vtvJi9dXs+4i8LTj6ZdwWZ1HNjvvSVt@gnusha.org
X-Gm-Message-State: AOJu0YxUHAMUsbfW1qpnZItVvHQVt1hKnnY76GRqL/ZiKN7WkMjtXn6S
	5P4blLOqTWfzt0K3fBojOMmAaflP8Ib9u0MCggt9J57+lxec10yh
X-Google-Smtp-Source: AGHT+IG+F5CmHzC6Fwp+xaxwl401PqQL9s4qA96+9f7FrhaLKDx+w0EzLKQZnmYP+mDeTXQpR7Qnjw==
X-Received: by 2002:a05:6808:318c:b0:3f6:ab0d:8dc0 with SMTP id 5614622812f47-401c0c11efbmr1199777b6e.24.1744984323508;
        Fri, 18 Apr 2025 06:52:03 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAJjmGnG3dFMr0fLTxPHD94lbrVT8hQKD4RRthOqfPqvvA==
Received: by 2002:a4a:cb95:0:b0:602:8f09:24d8 with SMTP id 006d021491bc7-604dab57f65ls520429eaf.2.-pod-prod-06-us;
 Fri, 18 Apr 2025 06:52:00 -0700 (PDT)
X-Received: by 2002:a05:6808:4486:b0:3f7:8f77:2a97 with SMTP id 5614622812f47-401c0c64deemr1431514b6e.34.1744984319941;
        Fri, 18 Apr 2025 06:51:59 -0700 (PDT)
Received: by 2002:a05:600c:3b13:b0:43c:fe31:d01d with SMTP id 5b1f17b1804b1-44069ee67e7ms5e9;
        Fri, 18 Apr 2025 06:29:20 -0700 (PDT)
X-Received: by 2002:a05:6000:18a5:b0:38f:2766:759f with SMTP id ffacd0b85a97d-39efbad2c1cmr2006486f8f.41.1744982958005;
        Fri, 18 Apr 2025 06:29:18 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1744982957; cv=none;
        d=google.com; s=arc-20240605;
        b=iGT3zuIct8v/jyayuPggh0yZmmIpbzrBivO368uNtN42SdMV0uQobVYekEnXcfuwOF
         2FnGN+oOQpPYenYh/RHpNsuPn9ms7qvHMQ+rOceq6K4T2uXTh5tr4qS966vZXhCV0dbI
         QpOpRjWVqLeFqtzOovh5chWmF8XgsvyeNH4kWE3+nmMR28uEe/GwrspNYJDmNrUnAd8A
         6F84BDH709le484UKs3oRAp9aNE6kqCdNaCOVdPFXVAAltB1k4eQApAzNk0Y1jCUVvEy
         V9/Td4FYeTrVIJJPwYHF77XzehlpCKD+lbk3V3Y10y2uY92zOLBM847uYe3ihd9X2RFi
         CR4g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=3yfhQgGOpHL7ad+P5loS1AwhvigdNvmbNtZU0v84ng4=;
        fh=leQLboTUdScs1e0Il1Cl2LB8GMiH49J/SwH9CHDWNGM=;
        b=kCIjyv8GdQ9zN0bIwi2rZOKpgDZXk7MtvpCHW1e2oDajw2SyabTYUpzQwSOD67BjTw
         fgXoL0vor53UERSnuzL7xzs8Jd6+at1JBpY2dMm65C87GGp7oU5H5OEqLUyONIInyLxm
         hYqwf3u/e1KqmppP1hhBq1VWVE8kNy+4BAErqzaJL9C/1eNg0z/PRsN57dG0YuiL5gHy
         PNY9AcTRVmdITSuaVpIkUgE0rW7vgsXlY5FCwUYRd90B+mm+XVanonkTt0VMUK4LZjM7
         mn7B5EtC4pALpL/fxDz3mXIV8YtvEYnVNiKCfUfUSv0qi6JhzTsB0369uVMyxaByYYSl
         32TA==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=g5KNVrUA;
       spf=pass (google.com: domain of darosior@protonmail.com designates 79.135.106.28 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-10628.protonmail.ch (mail-10628.protonmail.ch. [79.135.106.28])
        by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-39efa488ce6si39316f8f.5.2025.04.18.06.29.17
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Fri, 18 Apr 2025 06:29:17 -0700 (PDT)
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 79.135.106.28 as permitted sender) client-ip=79.135.106.28;
Date: Fri, 18 Apr 2025 13:29:12 +0000
To: Greg Sanders <gsanders87@gmail.com>, Sjors Provoost <sjors@sprovoost.nl>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
Message-ID: <8nHXu-p_oewEJ1P95eVG57v_qugup8KrgFCQ5sSM88TKMumrjwIdk9cRs3cPon6cEwxSgSiE2OWnoU2xCfa6DtrnT2SSWRsJmT1wkpWh9k0=@protonmail.com>
In-Reply-To: <b51b952c-b8ba-4f13-a216-c29095c39d00n@googlegroups.com>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com> <C7E2D805-E70A-455C-BDA1-224024BE93B3@sprovoost.nl> <b51b952c-b8ba-4f13-a216-c29095c39d00n@googlegroups.com>
Feedback-ID: 7060259:user:proton
X-Pm-Message-ID: 975a5f31fba51f9e9eab3d35424b1574c4967d69
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1=_n2XVMvsXoSViApXSqxhhlflCCIQbMzDRMk8oZnoCdps"
X-Original-Sender: darosior@protonmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@protonmail.com header.s=protonmail3 header.b=g5KNVrUA;
       spf=pass (google.com: domain of darosior@protonmail.com designates
 79.135.106.28 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
X-Original-From: Antoine Poinsot <darosior@protonmail.com>
Reply-To: Antoine Poinsot <darosior@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -1.0 (-)

--b1=_n2XVMvsXoSViApXSqxhhlflCCIQbMzDRMk8oZnoCdps
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> IIUC [..] The size of a single OP_RETURN is limited only by the maximum t=
ransaction size, i.e. 100 kvB.

Yes.

>>> is there ever a case where using OP_RETURN to embed data actually resul=
ts in fewer bytes onchain than embedding the same data using the segwit/tap=
root witness space> Yes, a back-of-the-envelope calculation [..]

>

For reference Vojt=C4=9Bch Strnad also has a good StackExchange answer with=
 details about this here: https://bitcoin.stackexchange.com/a/122322/101498=
. TL;DR: OP_RETURN is cheaper for data smaller than 143 bytes. I don't thin=
k this is sufficient reason not to drop the limit.

> we *could have* reserved multi-output as some sort of signaling mechanism=
 [..] though I can't imagine what that would be. Additional OP_RETURNs woul=
d be an expensive signal.

Exactly, and it's not like we would be running out of upgrade hooks anytime=
 soon.
On Friday, April 18th, 2025 at 8:54 AM, Greg Sanders <gsanders87@gmail.com>=
 wrote:

>> From perusing the Citrea paper (page 18) it seems a single output is eno=
ugh, and they only need 144 bytes.
>
> From discussion in person it seems as though they could adapt their use t=
o batch publish these transactions as SIGHASH_SINGLE|ACP transactions, with=
 each output being a 144-byte OP_RETURN. It's a less pressing issue perhaps=
, but if we can derive additional efficiency and don't want to revisit this=
 conversation again later, may be worth doing.
>
> The only drawback I can see to the second step would be that we *could ha=
ve* reserved multi-output as some sort of signaling mechanism since it's pr=
eviously not relayable on Bitcoin Core, even with knob fiddling, though I c=
an't imagine what that would be. Additional OP_RETURNs would be an expensiv=
e signal.
>
> Greg
> On Friday, April 18, 2025 at 8:16:00=E2=80=AFAM UTC-4 Sjors Provoost wrot=
e:
>
>>> Op 17 apr 2025, om 20:52 heeft 'Antoine Poinsot' via Bitcoin Developmen=
t Mailing List <bitco...@googlegroups.com> het volgende geschreven:
>>
>>> Developers are now designing constructions that work around these limit=
ations. An example is Clementine, the recently-announced Citrea bridge, whi=
ch uses unspendable Taproot outputs to store data in its "WatchtowerChallen=
ge" transaction due to the standardness restrictions on the size of OP_RETU=
RNs[^0]. Meanwhile, we have witnessed in recent years that the nudge is ine=
ffective to deter storing data onchain.
>>>
>>> Since the restrictions on the usage of OP_RETURN outputs encourage harm=
ful practices while being ineffective in deterring unwanted usage, i propos=
e to drop them. I suggest to start by lifting the restriction on the size o=
f the scriptPubKey for OP_RETURN outputs, as a first minimal step to stop e=
ncouraging harmful behaviour, and to then proceed to lift the restriction o=
n the number of OP_RETURN outputs per transactions.
>>
>> It might be better to do both, if only to avoid repeating the discussion=
 in a year.
>>
>> From perusing the Citrea paper (page 18) it seems a single output is eno=
ugh, and they only need 144 bytes.
>>
>> 1. Regarding size
>>
>> The current ~80 byte limit was based on Counterparty needing it [0], and=
 otherwise using bare multisig. A similar argument would apply here. At the=
 time there was discussion about how much space Counterparty really needed =
if their protocol was well implemented.
>>
>> The 144 bytes consist of a Groth16 proof and the total chain work. Along=
 similar lines we could pick a number based on various cryptographic commit=
ment schemes, and then only raise the limit by that much.
>>
>> But that just guarantees repeating the argument in a year when some prot=
ocol needs a slightly higher limit. In a post-inscription world that seems =
pointless. My preference is to drop the size limit entirely.
>>
>> 2. Regarding count
>>
>> IIUC there's no consensus limit on the size of an OP_RETURN [1] and ther=
e's also no standardness rule on the size of a scriptPubKey. The size of a =
single OP_RETURN is limited only by the maximum transaction size, i.e. 100 =
kvB.
>>
>> Without a size restriction on individual OP_RETURN outputs, there's no p=
oint in limiting their number.
>>
>> That said, it would be interesting to know if any protocols are thinking=
 of using multiple OP_RETURN outputs.
>>
>> 3. Reminder why we didn't do this earlier
>>
>> In the August 2023 discussion [2] Murch wrote, in response to John Light=
:
>>
>>>> is there ever a case where using OP_RETURN to embed data actually resu=
lts in fewer bytes onchain than embedding the same data using the segwit/ta=
proot witness space
>>>
>>> Yes, a back-of-the-envelope calculation has me thinking that only paylo=
ads of 135 bytes would be cheaper with transcriptions than with nulldata ou=
tputs. In detail:
>> [...]
>>> 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.
>>
>> Since we're discussing raising the limit to at least 144 bytes, the abov=
e argument would no longer be relevant.
>>
>> And from what I recall at the time that was the only remaining reason to=
 keep the OP_RETURN restrictions around a bit longer, despite heavy use of =
inscriptions.
>>
>> 4. PS - on liveliness assumptions
>>
>> The paper [3] states the following assumption:
>>
>>> We consider a secure ledger, i.e., a ledger that is safe and live. Safe=
ty and liveness are defined as follows:
>>>
>>> ...
>>>
>>> Definition 2 (Liveness). A distributed ledger protocol is live with liv=
eness parameter u if all transactions written by any correct party at round=
 r, appear in the ledgers of all correct parties by round r + u.
>>
>> For standard transactions this already not trivially true. See all of Li=
ghtning pinning discussions.
>>
>> For non-standard transactions, does BitVM2 keep all its transactions und=
er 100 kvB?
>>
>> Otherwise your liveness assumption requires a direct connection to at le=
ast one miner / pool that is trusted to not censor (though you can shop aro=
und until the deadline).
>>
>> Conversely, having actively used protocols that frequently require going=
 over some standardises limit puts pressure on that limit for the reasons A=
ntoine outlined. So for anyone working on such protocols, please let this l=
ist know, since these discussions can take a while.
>>
>> - Sjors
>>
>> [0] [https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the=
_counterparty_developers/?rdt=3D53592](https://www.reddit.com/r/btc/comment=
s/80ycim/a_few_months_after_the_counterparty_developers/)
>> [1] https://bitcoin.stackexchange.com/a/117595/4948
>> [2] [https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607...@murch.one/#t=
](https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607-e95a-8ec671cbb9f3@mur=
ch.one/#t) (click on the html attachment)
>> [3] https://citrea.xyz/clementine_whitepaper.pdf
>
> --
> You received this message because you are subscribed to the Google Groups=
 "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/bitcoinde=
v/b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegroups.com.

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
8nHXu-p_oewEJ1P95eVG57v_qugup8KrgFCQ5sSM88TKMumrjwIdk9cRs3cPon6cEwxSgSiE2OW=
noU2xCfa6DtrnT2SSWRsJmT1wkpWh9k0%3D%40protonmail.com.

--b1=_n2XVMvsXoSViApXSqxhhlflCCIQbMzDRMk8oZnoCdps
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<blockquote style=3D"border-left: 3px solid rgb(200, 200, 200); border-colo=
r: rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"><div=
 style=3D"font-family: Arial, sans-serif; font-size: 14px;">IIUC [..] The s=
ize of a single OP_RETURN is limited only by the maximum transaction size, =
i.e. 100 kvB.
<br></div></blockquote><div style=3D"">Yes.<br></div>
<div class=3D"protonmail_signature_block protonmail_signature_block-empty" =
style=3D"font-family: Arial, sans-serif; font-size: 14px;">
    <div class=3D"protonmail_signature_block-user protonmail_signature_bloc=
k-empty">
       =20
            </div>
   =20
            <div class=3D"protonmail_signature_block-proton protonmail_sign=
ature_block-empty">
       =20
            </div>
</div><div style=3D"font-family: Arial, sans-serif; font-size: 14px; color:=
 rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></div><div style=
=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); b=
ackground-color: rgb(255, 255, 255);"><span></span><blockquote style=3D"bor=
der-left: 3px solid rgb(200, 200, 200); border-color: rgb(200, 200, 200); p=
adding-left: 10px; color: rgb(102, 102, 102);"><div><span>&gt;&gt;
 is there ever a case where using OP_RETURN to embed data actually=20
results in fewer bytes onchain than embedding the same data using the=20
segwit/taproot witness space</span><br></div><span><span>&gt; Yes, a back-o=
f-the-envelope calculation [..]</span></span></blockquote></div><blockquote=
 style=3D"border-left: 3px solid rgb(200, 200, 200); border-color: rgb(200,=
 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"></blockquote><d=
iv style=3D"">For reference <span>Vojt=C4=9Bch Strnad</span> also has a goo=
d StackExchange answer with details about this here: <span><a target=3D"_bl=
ank" rel=3D"noreferrer nofollow noopener" href=3D"https://bitcoin.stackexch=
ange.com/a/122322/101498">https://bitcoin.stackexchange.com/a/122322/101498=
</a></span>. TL;DR: OP_RETURN is cheaper for data smaller than 143&nbsp;byt=
es. I don't think this is sufficient reason not to drop the limit.<br></div=
><div style=3D""><br></div><blockquote style=3D"border-left: 3px solid rgb(=
200, 200, 200); border-color: rgb(200, 200, 200); padding-left: 10px; color=
: rgb(102, 102, 102);"><div style=3D"">we *could have* reserved multi-outpu=
t as some sort of signaling mechanism [..] though I can't imagine what that=
 would be. Additional OP_RETURNs would be an expensive signal.</div></block=
quote><div style=3D"">Exactly, and it's not like we would be running out of=
 upgrade hooks anytime soon.</div><div class=3D"protonmail_quote">
        On Friday, April 18th, 2025 at 8:54 AM, Greg Sanders &lt;gsanders87=
@gmail.com&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" type=3D"cite">
            &gt; From perusing the Citrea paper (page 18) it seems a single=
 output is enough, and they only need 144 bytes.<div><br></div><div>From di=
scussion in person it seems as though they could adapt their use to batch p=
ublish these transactions as SIGHASH_SINGLE|ACP transactions, with each out=
put being a 144-byte OP_RETURN. It's a less pressing issue perhaps, but if =
we can derive additional efficiency and don't want to revisit this conversa=
tion again later, may be worth doing.</div><div><br></div><div>The only dra=
wback I can see to the second step would be that we *could have* reserved m=
ulti-output as some sort of signaling mechanism since it's previously not r=
elayable on Bitcoin Core, even with knob fiddling, though I can't imagine w=
hat that would be. Additional OP_RETURNs would be an expensive signal.</div=
><div><br></div><div>Greg<br><br></div><div class=3D"gmail_quote"><div clas=
s=3D"gmail_attr" dir=3D"auto">On Friday, April 18, 2025 at 8:16:00=E2=80=AF=
AM UTC-4 Sjors Provoost wrote:<br></div><blockquote style=3D"margin: 0 0 0 =
0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=
=3D"gmail_quote">
<br>&gt; Op 17 apr 2025, om 20:52 heeft 'Antoine Poinsot' via Bitcoin Devel=
opment Mailing List &lt;<a rel=3D"noreferrer nofollow noopener" data-email-=
masked=3D"" href=3D"" style=3D"pointer-events: none;">bitco...@googlegroups=
.com</a>&gt; het volgende geschreven:
<br>
<br>&gt; Developers are now designing constructions that work around these =
limitations. An example is Clementine, the recently-announced Citrea bridge=
, which uses unspendable Taproot outputs to store data in its "WatchtowerCh=
allenge" transaction due to the standardness restrictions on the size of OP=
_RETURNs[^0]. Meanwhile, we have witnessed in recent years that the nudge i=
s ineffective to deter storing data onchain.
<br>&gt;
<br>&gt; Since the restrictions on the usage of OP_RETURN outputs encourage=
 harmful practices while being ineffective in deterring unwanted usage, i p=
ropose to drop them. I suggest to start by lifting the restriction on the s=
ize of the scriptPubKey for OP_RETURN outputs, as a first minimal step to s=
top encouraging harmful behaviour, and to then proceed to lift the restrict=
ion on the number of OP_RETURN outputs per transactions.
<br>
<br>It might be better to do both, if only to avoid repeating the discussio=
n in a year.
<br>
<br>From perusing the Citrea paper (page 18) it seems a single output is en=
ough, and they only need 144 bytes.
<br>
<br>1. Regarding size
<br>
<br>The current ~80 byte limit was based on Counterparty needing it [0], an=
d otherwise using bare multisig. A similar argument would apply here. At th=
e time there was discussion about how much space Counterparty really needed=
 if their protocol was well implemented.
<br>
<br>The 144 bytes consist of a Groth16 proof and the total chain work. Alon=
g similar lines we could pick a number based on various cryptographic commi=
tment schemes, and then only raise the limit by that much.
<br>
<br>But that just guarantees repeating the argument in a year when some pro=
tocol needs a slightly higher limit. In a post-inscription world that seems=
 pointless. My preference is to drop the size limit entirely.
<br>
<br>2. Regarding count
<br>
<br>IIUC there's no consensus limit on the size of an OP_RETURN [1] and the=
re's also no standardness rule on the size of a scriptPubKey. The size of a=
 single OP_RETURN is limited only by the maximum transaction size, i.e. 100=
 kvB.
<br>
<br>Without a size restriction on individual OP_RETURN outputs, there's no =
point in limiting their number.
<br>
<br>That said, it would be interesting to know if any protocols are thinkin=
g of using multiple OP_RETURN outputs.
<br>
<br>3. Reminder why we didn't do this earlier
<br>
<br>In the August 2023 discussion [2] Murch wrote, in response to John Ligh=
t:
<br>
<br>&gt;&gt; is there ever a case where using OP_RETURN to embed data actua=
lly results in fewer bytes onchain than embedding the same data using the s=
egwit/taproot witness space
<br>&gt;
<br>&gt; Yes, a back-of-the-envelope calculation has me thinking that only =
payloads of 135 bytes would be cheaper with transcriptions than with nullda=
ta outputs. In detail:
<br>[...]
<br>&gt; 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.
<br>
<br>Since we're discussing raising the limit to at least 144 bytes, the abo=
ve argument would no longer be relevant.
<br>
<br>And from what I recall at the time that was the only remaining reason t=
o keep the OP_RETURN restrictions around a bit longer, despite heavy use of=
 inscriptions.
<br>
<br>4. PS - on liveliness assumptions
<br>
<br>The paper [3] states the following assumption:
<br>
<br>&gt; We consider a secure ledger, i.e., a ledger that is safe and live.=
 Safety and liveness are defined as follows:
<br>&gt;
<br>&gt; ...
<br>&gt;
<br>&gt; Definition 2 (Liveness). A distributed ledger protocol is live wit=
h liveness parameter u if all transactions written by any correct party at =
round r, appear in the ledgers of all correct parties by round r + u.
<br>
<br>For standard transactions this already not trivially true. See all of L=
ightning pinning discussions.
<br>
<br>For non-standard transactions, does BitVM2 keep all its transactions un=
der 100 kvB?
<br>
<br>Otherwise your liveness assumption requires a direct connection to at l=
east one miner / pool that is trusted to not censor (though you can shop ar=
ound until the deadline).
<br>
<br>Conversely, having actively used protocols that frequently require goin=
g over some standardises limit puts pressure on that limit for the reasons =
Antoine outlined. So for anyone working on such protocols, please let this =
list know, since these discussions can take a while.
<br>
<br>- Sjors
<br>
<br>[0] <a data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=
=3Dhttps://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_coun=
terparty_developers/?rdt%3D53592&amp;source=3Dgmail&amp;ust=3D1745067074218=
000&amp;usg=3DAOvVaw0MM9KbUgUA64--SjzlgQr3" rel=3D"noreferrer nofollow noop=
ener" target=3D"_blank" href=3D"https://www.reddit.com/r/btc/comments/80yci=
m/a_few_months_after_the_counterparty_developers/">https://www.reddit.com/r=
/btc/comments/80ycim/a_few_months_after_the_counterparty_developers/?rdt=3D=
53592</a>
<br>[1] <a data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=
=3Dhttps://bitcoin.stackexchange.com/a/117595/4948&amp;source=3Dgmail&amp;u=
st=3D1745067074218000&amp;usg=3DAOvVaw2wTRloeMwvq964MmuqlpS9" rel=3D"norefe=
rrer nofollow noopener" target=3D"_blank" href=3D"https://bitcoin.stackexch=
ange.com/a/117595/4948">https://bitcoin.stackexchange.com/a/117595/4948</a>
<br>[2] <a data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=
=3Dhttps://gnusha.org/pi/bitcoindev/03551f0f-272e-2607-e95a-8ec671cbb9f3@mu=
rch.one/%23t&amp;source=3Dgmail&amp;ust=3D1745067074218000&amp;usg=3DAOvVaw=
1na06VOwQurnkkZIWQep3O" rel=3D"noreferrer nofollow noopener" target=3D"_bla=
nk" href=3D"https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607-e95a-8ec671=
cbb9f3@murch.one/#t">https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607...=
@murch.one/#t</a> (click on the html attachment)
<br>[3] <a data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=
=3Dhttps://citrea.xyz/clementine_whitepaper.pdf&amp;source=3Dgmail&amp;ust=
=3D1745067074218000&amp;usg=3DAOvVaw3AsJFVA9H3QVl_yPci8EBx" rel=3D"noreferr=
er nofollow noopener" target=3D"_blank" href=3D"https://citrea.xyz/clementi=
ne_whitepaper.pdf">https://citrea.xyz/clementine_whitepaper.pdf</a></blockq=
uote></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" rel=3D"n=
oreferrer nofollow noopener">bitcoindev+unsubscribe@googlegroups.com</a>.<b=
r>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegroups.com" target=
=3D"_blank" rel=3D"noreferrer nofollow noopener">https://groups.google.com/=
d/msgid/bitcoindev/b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegroups.com=
</a>.<br>

        </blockquote><br>
    </div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/8nHXu-p_oewEJ1P95eVG57v_qugup8KrgFCQ5sSM88TKMumrjwIdk9cRs3cPon6c=
EwxSgSiE2OWnoU2xCfa6DtrnT2SSWRsJmT1wkpWh9k0%3D%40protonmail.com?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/=
8nHXu-p_oewEJ1P95eVG57v_qugup8KrgFCQ5sSM88TKMumrjwIdk9cRs3cPon6cEwxSgSiE2OW=
noU2xCfa6DtrnT2SSWRsJmT1wkpWh9k0%3D%40protonmail.com</a>.<br />

--b1=_n2XVMvsXoSViApXSqxhhlflCCIQbMzDRMk8oZnoCdps--