Delivery-date: Fri, 18 Apr 2025 06:52:10 -0700
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
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1=_n2XVMvsXoSViApXSqxhhlflCCIQbMzDRMk8oZnoCdps"
Reply-To: Antoine Poinsot <darosior@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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