path: root/9f/e0c189ba569e60b0bf856663e56e5daf35383f

Delivery-date: Sun, 20 Apr 2025 05:25:19 -0700
Received: from mail-yb1-f186.google.com ([209.85.219.186])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBI6PSPAAMGQETRH2WYQ@googlegroups.com>)
	id 1u6TjZ-0005K7-T1
	for bitcoindev@gnusha.org; Sun, 20 Apr 2025 05:25:19 -0700
Received: by mail-yb1-f186.google.com with SMTP id 3f1490d57ef6-e726d127b99sf3748683276.1
        for <bitcoindev@gnusha.org>; Sun, 20 Apr 2025 05:25:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1745151912; x=1745756712; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=k4B9dSfDpRJYAM7oQhYa+Z0pw+1aAFXYsSB6TFZIJEI=;
        b=v1oqlR/s2RVpjUgSpo4UTLrrzk4sf10d2HlKNnZ74XVLB7lJk4azIJP6ABxyoqQIdj
         60tbuLvbjfLX5FkbUc3Btt2HcCsYEI0ho94EPhPKNhDfzUGIvyXP5cSU9ZtJ+f935hAE
         kDkvvYrRSj8/Kg1MeiRnv3ts+AaTZJJApShNr5yI7v+vjthf7514E5biQ/1PTvbJJngn
         MbmAKv+BE44nXlk0ckttbpVoCUWK3nH5ALVWeyyZbKXPmfYkMwyNBOB4mKI7+Bj4TsJB
         3M9m0LOSpTqa070G0lQKWSstoBnO9vRWYQbpsQGpMiCNfTCyMRA7SBCRmR4g4sW9exON
         wpOQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1745151912; x=1745756712; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=k4B9dSfDpRJYAM7oQhYa+Z0pw+1aAFXYsSB6TFZIJEI=;
        b=ilWAJYEnimn5eKOpM8qbwImkRLkiQPlq7LTnVSHWzKaQ1mjPmTov8N5BEWfyB7fGVh
         NdTgk1bSAaR51zbGg3CYgW3ua9QQ7prTiewT8noSZYvoIGmTzn+LaUyjqAhBWIZPmH2E
         osw8vXl7q/MXm+uD94nDrwoRmhvC95rgYYvPCdh5nVs5fs/rS+cLWMYPFJdXZMI06cdb
         aPvcQQB4UQ9bsMxlXvWpbF3ZPEnaf3touJeSX7UB/lSPAeQZ2lEHCavgK9FepzPlxeeY
         VwnWMI5VEsLbNOVFnlwmM+c/ziKC7eQhjeMSEIw17DOOzpiwt6Dx2pDgNyzsGoDinnp6
         uGhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1745151912; x=1745756712;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=k4B9dSfDpRJYAM7oQhYa+Z0pw+1aAFXYsSB6TFZIJEI=;
        b=f1GaC3EY/iLTfVaqy+eQudklsplO7sX8lKRTvT/7QWzo0SEe4hN4zTNyS8BGmWOk2F
         /OZ9kxySeCSKDw6tnMQ9usmDBWI9YoTkIGcazFT+Qr8YNns6ka8M3XwZ/Wd2u5wWFvnE
         bT1TSnX05aV5Cs9wCndUIRrUndlwwBcmrePiAEMl0v2iDiE8yStaTMiKCxFf9NX75uZU
         ndtMX1im0grICCzMikAoMgIFIsWPer2dLWMkdccdHbBSvdZjNBsh1LTMQ6CcuRYmL36l
         kGDYAmdmMFXtDRtPHpHcsuzSSgAXUSB76y1+1CeiAmqGn4DSV+YeE0RmHnea9PLuofz2
         SmsA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUSW812s4dSwMAT9epQuGGwT5srrPRyRYHbKkwlL1eesfyEnMNDzjgdxff0l54MYOtpbv5Ih53lasRq@gnusha.org
X-Gm-Message-State: AOJu0YwEVzNXO65olTUgyi1nOaUe5yoFcNV8lvsFUmQdxtm2D5ac/EOU
	EldwrqxanB9dzfdV5UTlbzI7dhlMrx9tDwu8zBNIVYL8Dslz8ugz
X-Google-Smtp-Source: AGHT+IHxhBYM3SLzUgwVktuQC2FOrpOHRo0iskGVQFbIueVb2kBkpSbCtRTLN5C8MOGlYo9oHXE2tg==
X-Received: by 2002:a05:6902:2747:b0:e6b:8023:500f with SMTP id 3f1490d57ef6-e7298577b87mr10748303276.11.1745151911572;
        Sun, 20 Apr 2025 05:25:11 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPALRQk9lKhDZKXtMjfRuHK27mUVYziBjSUA10YrZnWNZ/A==
Received: by 2002:a25:5382:0:b0:e72:70cd:502e with SMTP id 3f1490d57ef6-e72804b3653ls191571276.1.-pod-prod-00-us;
 Sun, 20 Apr 2025 05:25:07 -0700 (PDT)
X-Received: by 2002:a05:690c:3193:b0:702:5886:7804 with SMTP id 00721157ae682-706ca549480mr109823977b3.19.1745151907386;
        Sun, 20 Apr 2025 05:25:07 -0700 (PDT)
Received: by 2002:a05:690c:6e82:b0:6ef:590d:3213 with SMTP id 00721157ae682-706cad98cfbms7b3;
        Fri, 18 Apr 2025 14:34:50 -0700 (PDT)
X-Received: by 2002:a05:690c:450f:b0:6f9:492e:94db with SMTP id 00721157ae682-706dc28ccaamr50773687b3.2.1745012089493;
        Fri, 18 Apr 2025 14:34:49 -0700 (PDT)
Date: Fri, 18 Apr 2025 14:34:49 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <0fe3d145-826b-4c0b-a420-fa683a2a34a7n@googlegroups.com>
In-Reply-To: <8nHXu-p_oewEJ1P95eVG57v_qugup8KrgFCQ5sSM88TKMumrjwIdk9cRs3cPon6cEwxSgSiE2OWnoU2xCfa6DtrnT2SSWRsJmT1wkpWh9k0=@protonmail.com>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <C7E2D805-E70A-455C-BDA1-224024BE93B3@sprovoost.nl>
 <b51b952c-b8ba-4f13-a216-c29095c39d00n@googlegroups.com>
 <8nHXu-p_oewEJ1P95eVG57v_qugup8KrgFCQ5sSM88TKMumrjwIdk9cRs3cPon6cEwxSgSiE2OWnoU2xCfa6DtrnT2SSWRsJmT1wkpWh9k0=@protonmail.com>
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_183268_1165994557.1745012089237"
X-Original-Sender: antoine.riard@gmail.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: -0.5 (/)

------=_Part_183268_1165994557.1745012089237
Content-Type: multipart/alternative; 
	boundary="----=_Part_183269_1061213772.1745012089237"

------=_Part_183269_1061213772.1745012089237
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Darosior,

Generally, I'm +1 on relaxing OP_RETURN standardness restrictions.

Few links that can be relevant for the discussions:
- https://github.com/petertodd/bitcoin/pull/6
- https://github.com/ordinals/ord/issues/2405

For adding a `-datacarrierenum`, this might be re-considered, e.g if you're
running a bitcoin full-node with an extended number of op_return outputs,=
=20
and
you have callback action when you're seeing said snarg proofs is in the=20
op_return.

This is assuming that of course additional software is running on top of
the full-node, e.g a custom block explorer, though it could be a source of
DoS, if callbacks are triggered before inclusion in op_return outputs (--
and some might do before inclusion, just for latency gains in their=20
use-cases).

I think there is one downside I can see of relaxing OP_RETURN standardness
restrictions, namely that a single transaction output "exogeneous" value
might be worth more than the block reward yields in fees (`blockReward`).

That could be an issue where a single transaction output owner with an
"exogeneous" value braodcast a tx for a double-spend where this condition
can only be included if the block is reorged-out (e.g a bridge where 2=20
withdrawal are valid at the same time to different owners). Somehow=20
linearity of chain advances is a good property to have.

One can have a look on the ordinals markets at the last halving blocks,
to see it's already can be a concern, as something like ordinals mined
by the coinbase pubkey was trading for a high price.

This is not a problem for now with multi-party transactiosn or contracting
protocols (e.g coinjoins or lightning), as it's always a coin exchanged, or
fees that must be committed to settle an off-chain state.

Best,
Antoine
OTS hash: a3264eaedf79b15d5e9cd32a20d1d82c6981f49a34256d6c961fd39c976ff2c2

Le vendredi 18 avril 2025 =C3=A0 14:52:03 UTC+1, Antoine Poinsot a =C3=A9cr=
it :

> IIUC [..] The size of a single OP_RETURN is limited only by the maximum=
=20
> transaction size, i.e. 100 kvB.=20
>
> Yes.
>
> >> 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
>
> > Yes, a back-of-the-envelope calculation [..]
>
> For reference Vojt=C4=9Bch Strnad also has a good StackExchange answer wi=
th=20
> details about this here: https://bitcoin.stackexchange.com/a/122322/10149=
8.=20
> TL;DR: OP_RETURN is cheaper for data smaller than 143 bytes. I don't thin=
k=20
> this is sufficient reason not to drop the limit.
>
> we *could have* reserved multi-output as some sort of signaling mechanism=
=20
> [..] though I can't imagine what that would be. Additional OP_RETURNs wou=
ld=20
> be an expensive signal.
>
> Exactly, and it's not like we would be running out of upgrade hooks=20
> anytime soon.
> On Friday, April 18th, 2025 at 8:54 AM, Greg Sanders <gsand...@gmail.com>=
=20
> wrote:
>
> > From perusing the Citrea paper (page 18) it seems a single output is=20
> enough, and they only need 144 bytes.
>
> From discussion in person it seems as though they could adapt their use t=
o=20
> batch publish these transactions as SIGHASH_SINGLE|ACP transactions, with=
=20
> each output being a 144-byte OP_RETURN. It's a less pressing issue perhap=
s,=20
> but if we can derive additional efficiency and don't want to revisit this=
=20
> conversation again later, may be worth doing.
>
> The only drawback I can see to the second step would be that we *could=20
> have* reserved multi-output as some sort of signaling mechanism since it'=
s=20
> previously not relayable on Bitcoin Core, even with knob fiddling, though=
 I=20
> can't imagine what that would be. Additional OP_RETURNs would be an=20
> expensive 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=20
>> Development Mailing List <bitco...@googlegroups.com> het volgende=20
>> geschreven:=20
>>
>> > Developers are now designing constructions that work around these=20
>> limitations. An example is Clementine, the recently-announced Citrea=20
>> bridge, which uses unspendable Taproot outputs to store data in its=20
>> "WatchtowerChallenge" transaction due to the standardness restrictions o=
n=20
>> the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years=
=20
>> that the nudge is ineffective to deter storing data onchain.=20
>> >=20
>> > Since the restrictions on the usage of OP_RETURN outputs encourage=20
>> harmful practices while being ineffective in deterring unwanted usage, i=
=20
>> propose to drop them. I suggest to start by lifting the restriction on t=
he=20
>> size of the scriptPubKey for OP_RETURN outputs, as a first minimal step =
to=20
>> stop encouraging harmful behaviour, and to then proceed to lift the=20
>> restriction on the number of OP_RETURN outputs per transactions.=20
>>
>> It might be better to do both, if only to avoid repeating the discussion=
=20
>> in a year.=20
>>
>> From perusing the Citrea paper (page 18) it seems a single output is=20
>> enough, and they only need 144 bytes.=20
>>
>> 1. Regarding size=20
>>
>> The current ~80 byte limit was based on Counterparty needing it [0], and=
=20
>> otherwise using bare multisig. A similar argument would apply here. At t=
he=20
>> time there was discussion about how much space Counterparty really neede=
d=20
>> if their protocol was well implemented.=20
>>
>> The 144 bytes consist of a Groth16 proof and the total chain work. Along=
=20
>> similar lines we could pick a number based on various cryptographic=20
>> commitment schemes, and then only raise the limit by that much.=20
>>
>> But that just guarantees repeating the argument in a year when some=20
>> protocol needs a slightly higher limit. In a post-inscription world that=
=20
>> seems pointless. My preference is to drop the size limit entirely.=20
>>
>> 2. Regarding count=20
>>
>> IIUC there's no consensus limit on the size of an OP_RETURN [1] and=20
>> there's also no standardness rule on the size of a scriptPubKey. The siz=
e=20
>> of a single OP_RETURN is limited only by the maximum transaction size, i=
.e.=20
>> 100 kvB.=20
>>
>> Without a size restriction on individual OP_RETURN outputs, there's no=
=20
>> point in limiting their number.=20
>>
>> That said, it would be interesting to know if any protocols are thinking=
=20
>> of using multiple OP_RETURN outputs.=20
>>
>> 3. Reminder why we didn't do this earlier=20
>>
>> In the August 2023 discussion [2] Murch wrote, in response to John Light=
:=20
>>
>> >> 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=20
>> >=20
>> > Yes, a back-of-the-envelope calculation has me thinking that only=20
>> payloads of 135 bytes would be cheaper with transcriptions than with=20
>> nulldata outputs. In detail:=20
>> [...]=20
>> > we learn that nulldata outputs are cheaper up to a payload size of 134=
=20
>> bytes, only above that inscriptions become a more blockspace efficient d=
ata=20
>> carrier.=20
>>
>> Since we're discussing raising the limit to at least 144 bytes, the abov=
e=20
>> argument would no longer be relevant.=20
>>
>> And from what I recall at the time that was the only remaining reason to=
=20
>> keep the OP_RETURN restrictions around a bit longer, despite heavy use o=
f=20
>> inscriptions.=20
>>
>> 4. PS - on liveliness assumptions=20
>>
>> The paper [3] states the following assumption:=20
>>
>> > We consider a secure ledger, i.e., a ledger that is safe and live.=20
>> Safety and liveness are defined as follows:=20
>> >=20
>> > ...=20
>> >=20
>> > Definition 2 (Liveness). A distributed ledger protocol is live with=20
>> liveness parameter u if all transactions written by any correct party at=
=20
>> round r, appear in the ledgers of all correct parties by round r + u.=20
>>
>> For standard transactions this already not trivially true. See all of=20
>> Lightning pinning discussions.=20
>>
>> For non-standard transactions, does BitVM2 keep all its transactions=20
>> under 100 kvB?=20
>>
>> Otherwise your liveness assumption requires a direct connection to at=20
>> least one miner / pool that is trusted to not censor (though you can sho=
p=20
>> around until the deadline).=20
>>
>> Conversely, having actively used protocols that frequently require going=
=20
>> over some standardises limit puts pressure on that limit for the reasons=
=20
>> Antoine outlined. So for anyone working on such protocols, please let th=
is=20
>> list know, since these discussions can take a while.=20
>>
>> - Sjors=20
>>
>> [0]=20
>> https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_coun=
terparty_developers/?rdt=3D53592=20
>> <https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_cou=
nterparty_developers/>=20
>> [1] https://bitcoin.stackexchange.com/a/117595/4948=20
>> [2] https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607...@murch.one/#t=
=20
>> <https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607-e95a-8ec671cbb9f3@m=
urch.one/#t>=20
>> (click on the html attachment)=20
>> [3] https://citrea.xyz/clementine_whitepaper.pdf
>
> --=20
>
> You received this message because you are subscribed to the Google Groups=
=20
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to bitcoindev+...@googlegroups.com.
> To view this discussion visit=20
> https://groups.google.com/d/msgid/bitcoindev/b51b952c-b8ba-4f13-a216-c290=
95c39d00n%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/=
0fe3d145-826b-4c0b-a420-fa683a2a34a7n%40googlegroups.com.

------=_Part_183269_1061213772.1745012089237
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello Darosior,<br /><br />Generally, I'm +1 on relaxing OP_RETURN standard=
ness restrictions.<br /><br />Few links that can be relevant for the discus=
sions:<br />- https://github.com/petertodd/bitcoin/pull/6<br />- https://gi=
thub.com/ordinals/ord/issues/2405<br /><br />For adding a `-datacarrierenum=
`, this might be re-considered, e.g if you're<br />running a bitcoin full-n=
ode with an extended number of op_return outputs, and<br />you have callbac=
k action when you're seeing said snarg proofs is in the op_return.<br /><br=
 />This is assuming that of course additional software is running on top of=
<br />the full-node, e.g a custom block explorer, though it could be a sour=
ce of<br />DoS, if callbacks are triggered before inclusion in op_return ou=
tputs (--<br />and some might do before inclusion, just for latency gains i=
n their use-cases).<br /><br />I think there is one downside I can see of r=
elaxing OP_RETURN standardness<br />restrictions, namely that a single tran=
saction output "exogeneous" value<br />might be worth more than the block r=
eward yields in fees (`blockReward`).<br /><br />That could be an issue whe=
re a single transaction output owner with an<br />"exogeneous" value braodc=
ast a tx for a double-spend where this condition<br />can only be included =
if the block is reorged-out (e.g a bridge where 2 <br />withdrawal are vali=
d at the same time to different owners). Somehow <br />linearity of chain a=
dvances is a good property to have.<br /><br />One can have a look on the o=
rdinals markets at the last halving blocks,<br />to see it's already can be=
 a concern, as something like ordinals mined<br />by the coinbase pubkey wa=
s trading for a high price.<br /><br />This is not a problem for now with m=
ulti-party transactiosn or contracting<br />protocols (e.g coinjoins or lig=
htning), as it's always a coin exchanged, or<br />fees that must be committ=
ed to settle an off-chain state.<br /><br />Best,<br />Antoine<br />OTS has=
h: a3264eaedf79b15d5e9cd32a20d1d82c6981f49a34256d6c961fd39c976ff2c2<br /><b=
r /><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">Le ve=
ndredi 18 avril 2025 =C3=A0 14:52:03 UTC+1, Antoine Poinsot a =C3=A9crit=C2=
=A0:<br/></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8=
ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockqu=
ote style=3D"border-left:3px solid rgb(200,200,200);border-color:rgb(200,20=
0,200);padding-left:10px;color:rgb(102,102,102)"><div style=3D"font-family:=
Arial,sans-serif;font-size:14px">IIUC [..] The size of a single OP_RETURN i=
s limited only by the maximum transaction size, i.e. 100 kvB.
<br></div></blockquote><div>Yes.<br></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
    <div>
       =20
            </div>
   =20
            <div>
       =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-famil=
y:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255=
,255,255)"><span></span><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></div><div style=3D"font-family:Arial,sans-serif;font-si=
ze:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><blockquote sty=
le=3D"border-left:3px solid rgb(200,200,200);border-color:rgb(200,200,200);=
padding-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></blockquote></div><div style=
=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background=
-color:rgb(255,255,255)"><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)"><span><span>&gt; Yes, a back-of-the-envelope calculation [..]</span>=
</span></blockquote></div><blockquote style=3D"border-left:3px solid rgb(20=
0,200,200);border-color:rgb(200,200,200);padding-left:10px;color:rgb(102,10=
2,102)"></blockquote><div>For reference <span>Vojt=C4=9Bch Strnad</span> al=
so has a good StackExchange answer with details about this here: <span><a r=
el=3D"noreferrer nofollow noopener" href=3D"https://bitcoin.stackexchange.c=
om/a/122322/101498" target=3D"_blank" data-saferedirecturl=3D"https://www.g=
oogle.com/url?hl=3Dfr&amp;q=3Dhttps://bitcoin.stackexchange.com/a/122322/10=
1498&amp;source=3Dgmail&amp;ust=3D1745098463721000&amp;usg=3DAOvVaw0WvmU_D5=
FuN3Nkx64BnuW-">https://bitcoin.stackexchange.com/a/122322/101498</a></span=
>. TL;DR: OP_RETURN is cheaper for data smaller than 143=C2=A0bytes. I don&=
#39;t think this is sufficient reason not to drop the limit.<br></div><div>=
<br></div><blockquote style=3D"border-left:3px solid rgb(200,200,200);borde=
r-color:rgb(200,200,200);padding-left:10px;color:rgb(102,102,102)"><div>we =
*could have* reserved multi-output as some sort of signaling mechanism [..]=
 though I can&#39;t imagine what that would be. Additional OP_RETURNs would=
 be an expensive signal.</div></blockquote><div>Exactly, and it&#39;s not l=
ike we would be running out of upgrade hooks anytime soon.</div><div></div>=
<div>
        On Friday, April 18th, 2025 at 8:54 AM, Greg Sanders &lt;<a href da=
ta-email-masked rel=3D"nofollow">gsand...@gmail.com</a>&gt; wrote:<br>
        </div><div><blockquote 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&#39;s a less pressing issue perhaps, but=
 if we can derive additional efficiency and don&#39;t want to revisit this =
conversation again later, may be worth doing.</div><div><br></div><div>The =
only drawback I can see to the second step would be that we *could have* re=
served multi-output as some sort of signaling mechanism since it&#39;s prev=
iously not relayable on Bitcoin Core, even with knob fiddling, though I can=
&#39;t imagine what that would be. Additional OP_RETURNs would be an expens=
ive signal.</div><div><br></div><div>Greg<br><br></div><div class=3D"gmail_=
quote"><div class=3D"gmail_attr" dir=3D"auto">On Friday, April 18, 2025 at =
8:16:00=E2=80=AFAM 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 &#39;Antoine Poinsot&#39; via Bitco=
in Development Mailing List &lt;<a rel=3D"noreferrer nofollow noopener">bit=
co...@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 &quot;Watchto=
werChallenge&quot; transaction due to the standardness restrictions on the =
size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years that t=
he nudge is 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&#39;s no consensus limit on the size of an OP_RETURN [1] and=
 there&#39;s also no standardness rule on the size of a scriptPubKey. The s=
ize 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&#39;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&#39;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&#39;re discussing raising the limit to at least 144 bytes, the=
 above 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 rel=3D"noreferrer nofollow noopener" href=3D"https://www.reddit.=
com/r/btc/comments/80ycim/a_few_months_after_the_counterparty_developers/" =
target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Df=
r&amp;q=3Dhttps://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_t=
he_counterparty_developers/&amp;source=3Dgmail&amp;ust=3D1745098463721000&a=
mp;usg=3DAOvVaw2LCgwSGpbdIWv4oaBMi_VY">https://www.reddit.com/r/btc/comment=
s/80ycim/a_few_months_after_the_counterparty_developers/?rdt=3D53592</a>
<br>[1] <a rel=3D"noreferrer nofollow noopener" href=3D"https://bitcoin.sta=
ckexchange.com/a/117595/4948" target=3D"_blank" data-saferedirecturl=3D"htt=
ps://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://bitcoin.stackexchange.com/a=
/117595/4948&amp;source=3Dgmail&amp;ust=3D1745098463721000&amp;usg=3DAOvVaw=
35CUVFSSRbhuSt15YpJZu3">https://bitcoin.stackexchange.com/a/117595/4948</a>
<br>[2] <a rel=3D"noreferrer nofollow noopener" href=3D"https://gnusha.org/=
pi/bitcoindev/03551f0f-272e-2607-e95a-8ec671cbb9f3@murch.one/#t" target=3D"=
_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3D=
https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607-e95a-8ec671cbb9f3@murch=
.one/%23t&amp;source=3Dgmail&amp;ust=3D1745098463721000&amp;usg=3DAOvVaw2JT=
O31ceZTQ6y9pVjuG0B_">https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607...=
@murch.one/#t</a> (click on the html attachment)
<br>[3] <a rel=3D"noreferrer nofollow noopener" href=3D"https://citrea.xyz/=
clementine_whitepaper.pdf" target=3D"_blank" data-saferedirecturl=3D"https:=
//www.google.com/url?hl=3Dfr&amp;q=3Dhttps://citrea.xyz/clementine_whitepap=
er.pdf&amp;source=3Dgmail&amp;ust=3D1745098463721000&amp;usg=3DAOvVaw3WRQOj=
6Fa2KMtupo2kviPT">https://citrea.xyz/clementine_whitepaper.pdf</a></blockqu=
ote></div>

<p></p></blockquote></div><div><blockquote type=3D"cite">

-- <br></blockquote></div><div><blockquote type=3D"cite">
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 rel=3D"noreferrer nofollow noopener" data-email-masked>bitc=
oindev+...@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegroups.com" rel=3D=
"noreferrer nofollow noopener" target=3D"_blank" data-saferedirecturl=3D"ht=
tps://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://groups.google.com/d/msgid/=
bitcoindev/b51b952c-b8ba-4f13-a216-c29095c39d00n%2540googlegroups.com&amp;s=
ource=3Dgmail&amp;ust=3D1745098463721000&amp;usg=3DAOvVaw2tNc3muEo7KcdHTK6d=
AEmg">https://groups.google.com/d/msgid/bitcoindev/b51b952c-b8ba-4f13-a216-=
c29095c39d00n%40googlegroups.com</a>.<br>

        </blockquote></div></blockquote></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/0fe3d145-826b-4c0b-a420-fa683a2a34a7n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/0fe3d145-826b-4c0b-a420-fa683a2a34a7n%40googlegroups.com</a>.<br />

------=_Part_183269_1061213772.1745012089237--

------=_Part_183268_1165994557.1745012089237--