Delivery-date: Fri, 18 Apr 2025 06:52:07 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of vojta.strnad@gmail.com designates 2a00:1450:4864:20::32e as permitted sender) client-ip=2a00:1450:4864:20::32e;
MIME-Version: 1.0
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <C7E2D805-E70A-455C-BDA1-224024BE93B3@sprovoost.nl> <b51b952c-b8ba-4f13-a216-c29095c39d00n@googlegroups.com>
In-Reply-To: <b51b952c-b8ba-4f13-a216-c29095c39d00n@googlegroups.com>
From: =?UTF-8?Q?Vojt=C4=9Bch_Strnad?= <vojta.strnad@gmail.com>
Date: Fri, 18 Apr 2025 15:06:41 +0200
Message-ID: <CADnN-1U1JcbgeWAyMJ7zzbMzYRVy_Gd6fTrRu3wPVg+gxo4Vvw@mail.gmail.com>
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000005e876206330d31d7"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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

 Hi all,

Regarding the size of an OP_RETURN output, I made a calculation [0] a while
ago to compare it to the all too commonly used "inscription envelope"
(<pubkey> OP_CHECKSIG OF_FALSE OP_IF <data> OP_ENDIF). The result was that
OP_RETURN is cheaper for data smaller than 143 bytes or 158 bytes,
depending on whether you count the overhead of the transaction revealing
the inscription.

Personally, I've never been a fan of the OP_RETURN standardness rules. They
could always be easily bypassed in more or less harmful ways with only a
small loss of data encoding efficiency (the most harmful being adding many
unspendable outputs to a transaction, which some protocols do even today).

[0] https://bitcoin.stackexchange.com/q/122321/121614

On Fri, Apr 18, 2025 at 2:58=E2=80=AFPM Greg Sanders <gsanders87@gmail.com>=
 wrote:

> > From perusing the Citrea paper (page 18) it seems a single output is
> enough, 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 perhap=
s,
> 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
> have* reserved multi-output as some sort of signaling mechanism since it'=
s
> previously not relayable on Bitcoin Core, even with knob fiddling, though=
 I
> can't imagine what that would be. Additional OP_RETURNs would be an
> 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
>> Development Mailing List <bitco...@googlegroups.com> het volgende
>> geschreven:
>>
>> > 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
>> "WatchtowerChallenge" transaction due to the standardness restrictions o=
n
>> the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years
>> that the nudge is ineffective to deter storing data onchain.
>> >
>> > Since the restrictions on the usage of OP_RETURN outputs encourage
>> harmful practices while being ineffective in deterring unwanted usage, i
>> propose to drop them. I suggest to start by lifting the restriction on t=
he
>> size of the scriptPubKey for OP_RETURN outputs, as a first minimal step =
to
>> stop encouraging harmful behaviour, and to then proceed to lift the
>> restriction on 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
>> enough, 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 t=
he
>> time there was discussion about how much space Counterparty really neede=
d
>> 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
>> commitment schemes, and then only raise the limit by that much.
>>
>> But that just guarantees repeating the argument in a year when some
>> protocol 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
>> there's also no standardness rule on the size of a scriptPubKey. The siz=
e
>> 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
>> point 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
>> 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:
>> [...]
>> > we learn that nulldata outputs are cheaper up to a payload size of 134
>> bytes, only above that inscriptions become a more blockspace efficient d=
ata
>> 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 o=
f
>> 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.
>> Safety and liveness are defined as follows:
>> >
>> > ...
>> >
>> > Definition 2 (Liveness). A distributed ledger protocol is live with
>> 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.
>>
>> For standard transactions this already not trivially true. See all of
>> Lightning pinning discussions.
>>
>> For non-standard transactions, does BitVM2 keep all its transactions
>> under 100 kvB?
>>
>> Otherwise your liveness assumption requires a direct connection to at
>> least one miner / pool that is trusted to not censor (though you can sho=
p
>> around until the deadline).
>>
>> Conversely, having actively used protocols that frequently require going
>> over some standardises limit puts pressure on that limit for the reasons
>> Antoine outlined. So for anyone working on such protocols, please let th=
is
>> list know, since these discussions can take a while.
>>
>> - Sjors
>>
>> [0]
>> https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_coun=
terparty_developers/?rdt=3D53592
>> [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@m=
urch.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/bitcoindev/b51b952c-b8ba-4f13-a216-c290=
95c39d00n%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/b51b952c-b8ba-4f13-a216-c29=
095c39d00n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>

--=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/=
CADnN-1U1JcbgeWAyMJ7zzbMzYRVy_Gd6fTrRu3wPVg%2Bgxo4Vvw%40mail.gmail.com.

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

<div dir=3D"ltr">
<div dir=3D"ltr"><div>Hi all,</div><div><br></div><div>Regarding
 the size of an OP_RETURN output, I made a calculation [0] a while ago=20
to compare it to the all too commonly used &quot;inscription envelope&quot;=
=20
(&lt;pubkey&gt; OP_CHECKSIG OF_FALSE OP_IF &lt;data&gt; OP_ENDIF). The=20
result was that OP_RETURN is cheaper for data smaller than 143 bytes or=20
158 bytes, depending on whether you count the overhead of the=20
transaction revealing the inscription.</div><div><br></div><div>Personally,
 I&#39;ve never been a fan of the OP_RETURN standardness rules. They=20
could always be easily bypassed in more or less harmful ways with only a
 small loss of data encoding efficiency (the most harmful being adding=20
many unspendable outputs to a transaction, which some protocols do even=20
today).</div><div><br></div><div>[0] <a href=3D"https://bitcoin.stackexchan=
ge.com/q/122321/121614">https://bitcoin.stackexchange.com/q/122321/121614</=
a></div></div>

</div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr"=
 class=3D"gmail_attr">On Fri, Apr 18, 2025 at 2:58=E2=80=AFPM Greg Sanders =
&lt;<a href=3D"mailto:gsanders87@gmail.com">gsanders87@gmail.com</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; From p=
erusing the Citrea paper (page 18) it seems a single output is enough, and =
they only need 144 bytes.<div><br></div><div>From discussion in person it s=
eems as though they could adapt their use to batch publish these transactio=
ns as SIGHASH_SINGLE|ACP transactions, with each output being a 144-byte OP=
_RETURN. It&#39;s a less pressing issue perhaps, but if we can derive addit=
ional efficiency and don&#39;t want to revisit this conversation again late=
r, 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* reserved multi-output as =
some sort of signaling mechanism since it&#39;s previously not relayable on=
 Bitcoin Core, even with knob fiddling, though I can&#39;t imagine what tha=
t 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 dir=3D"auto=
" class=3D"gmail_attr">On Friday, April 18, 2025 at 8:16:00=E2=80=AFAM UTC-=
4 Sjors Provoost wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">
<br>&gt; Op 17 apr 2025, om 20:52 heeft &#39;Antoine Poinsot&#39; via Bitco=
in Development Mailing List &lt;<a rel=3D"nofollow">bitco...@googlegroups.c=
om</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;=20
<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;=20
<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;=20
<br>&gt; ...
<br>&gt;=20
<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 href=3D"https://www.reddit.com/r/btc/comments/80ycim/a_few_month=
s_after_the_counterparty_developers/?rdt=3D53592" rel=3D"nofollow" target=
=3D"_blank">https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after=
_the_counterparty_developers/?rdt=3D53592</a>
<br>[1] <a href=3D"https://bitcoin.stackexchange.com/a/117595/4948" rel=3D"=
nofollow" target=3D"_blank">https://bitcoin.stackexchange.com/a/117595/4948=
</a>
<br>[2] <a href=3D"https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607-e95a=
-8ec671cbb9f3@murch.one/#t" rel=3D"nofollow" target=3D"_blank">https://gnus=
ha.org/pi/bitcoindev/03551f0f-272e-2607...@murch.one/#t</a> (click on the h=
tml attachment)
<br>[3] <a href=3D"https://citrea.xyz/clementine_whitepaper.pdf" rel=3D"nof=
ollow" target=3D"_blank">https://citrea.xyz/clementine_whitepaper.pdf</a></=
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" target=
=3D"_blank">bitcoindev+unsubscribe@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?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https://groups.googl=
e.com/d/msgid/bitcoindev/b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegrou=
ps.com</a>.<br>
</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/CADnN-1U1JcbgeWAyMJ7zzbMzYRVy_Gd6fTrRu3wPVg%2Bgxo4Vvw%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CADnN-1U1JcbgeWAyMJ7zzbMzYRVy_Gd6fTrRu3wPVg%2Bgxo4Vvw%40ma=
il.gmail.com</a>.<br />

--0000000000005e876206330d31d7--