From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 18 Apr 2025 05:58:09 -0700 Received: from mail-yw1-f186.google.com ([209.85.128.186]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1u5lIF-0001BX-V1 for bitcoindev@gnusha.org; Fri, 18 Apr 2025 05:58:09 -0700 Received: by mail-yw1-f186.google.com with SMTP id 00721157ae682-7075bbaa916sf6533147b3.1 for ; Fri, 18 Apr 2025 05:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1744981082; x=1745585882; 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=clS9jaxTSvuwkasTtMe+DMv0V7ALb/2Xje7qQsE7ws8=; b=GkMAOtze3WyE+f8kv6QvzHzrgZR2ybd0MBYnWhH1oMPEFRBNM++pCEij7QwK0gNz5s ThatGW+u6kYWlf90dYQcRODKQfZqgxDCT0170FnOPofx21Rp5ZbtfUw6cTabw2RyDbl8 dnjeg44Gckl7T2Lsmr27Nnky2ZE+amlb5dYWPk4Qbgyev/1H7FquPDbMa+jkTcUEdTth X2+8jMJVoxXmW0TR6aHy3psiVJ/0Rwnrx0YBm6k/FCgE8sQ9GuPQDCAkpheOmubcrJY+ KX0u28y/dF6gmMNLQCHsjIfhL4p/aebkt5SdwftoRcSakpAKrhcvDp3bDRjVAtGXDgUg 2vWA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1744981082; x=1745585882; 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=clS9jaxTSvuwkasTtMe+DMv0V7ALb/2Xje7qQsE7ws8=; b=fStXzfFxF1BRqTweTUIuv+gNqzInwstxTNX8Vw7btugat1j9c5iggAjPkBLLOjD8V5 D5gXftZXt5pTXzBAtK/ZrzRVU+TYT1Ffh/oY/XWDYlEbI0y3XJQsSTXIA0rs+ZMYntyJ fhpj1cVU+vEtHG7v+eQhWwHsVYaE7ibz/9P7tcGENhyIxbNEhk40s0vflRKSvcWlw8t8 Slzh1Z9nIWVf/wbeat1CJIXex/DKcBl8yo8Gj3meG+g2oZHqE61DbKVBNh6UPdgZpKiF qTFsmiI7W9eNIueRYbnjoQ7lrax1JS+L3sQkOLMBBt7nhh/jte4z9fubA91oOQqEiALi 6rqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744981082; x=1745585882; 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=clS9jaxTSvuwkasTtMe+DMv0V7ALb/2Xje7qQsE7ws8=; b=OdwstaALyP7oKjzMAY2X+DX4WXV0kGvaY4gdNnBfPuYz5T+riWXXPYVxJ+R9LJVDSG 5n5xCwlEyyRYxhZhNucMWW/1NbrNJdkigxbHjbbsTzj6yjWD2RLQflcEO1SbSmYH2ZqG qcO2mFXgaXmp5HzB5PetS029qmAVsHD2cHlTNLn2z/Uguf6zszqxtz+vuNmcVNitZtzs eVjzP6XHIlvwldqHvw/5+zhia6kTPTfkAQ3/rsm4uCYBCVEDGIKnkkqj//Rklsxgc/Vv aeB0YppPiSBaejg05Z8hKCWVapDWIsJYIyzH2YZ/xi+0Zs4y/WV4e28BOw8yRaD051TC 5onw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUqEamTD2ASA9xB36EZUv8vG0z4LfUke7tc0zBwIHhE/ejO5m2yQtR/O1d2uYEmonm9ZZo4Qb+/X4sF@gnusha.org X-Gm-Message-State: AOJu0YyKc2rJSKxph5Y9s7eY9KMpM1d2CjTfrEDAYkT2t38gz4aHQb6d ZJdT81dI+5DsnXCxW7UyId1XinLGubkos2vto3dhs5PvbaE+8tCm X-Google-Smtp-Source: AGHT+IF21SCBsI+USW9D/R0IRGxqL3DiLNudYClLxr8n9yYEjUKBfEUYpLLd75XKaMD3NuYriNkC2g== X-Received: by 2002:a05:6902:992:b0:e6d:fb0f:fcbf with SMTP id 3f1490d57ef6-e7297e64d5emr3287989276.39.1744981081755; Fri, 18 Apr 2025 05:58:01 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPALOmI1B7dHyHAYguIy1HdbAdUYr5YAWvi25Na5BvtI5dQ== Received: by 2002:a25:6c87:0:b0:e6d:f2c2:ec75 with SMTP id 3f1490d57ef6-e72804b4d20ls1148059276.1.-pod-prod-07-us; Fri, 18 Apr 2025 05:57:58 -0700 (PDT) X-Received: by 2002:a05:690c:3613:b0:6f4:8207:c68d with SMTP id 00721157ae682-706ccc8e812mr35111427b3.3.1744981077997; Fri, 18 Apr 2025 05:57:57 -0700 (PDT) Received: by 2002:a05:690c:6e82:b0:6ef:590d:3213 with SMTP id 00721157ae682-706cad98cfbms7b3; Fri, 18 Apr 2025 05:54:49 -0700 (PDT) X-Received: by 2002:a05:690c:9c01:b0:6ef:7f89:d906 with SMTP id 00721157ae682-706cce06c78mr33197257b3.33.1744980888727; Fri, 18 Apr 2025 05:54:48 -0700 (PDT) Date: Fri, 18 Apr 2025 05:54:48 -0700 (PDT) From: Greg Sanders To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_76168_520530924.1744980888418" X-Original-Sender: gsanders87@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_76168_520530924.1744980888418 Content-Type: multipart/alternative; boundary="----=_Part_76169_47774300.1744980888418" ------=_Part_76169_47774300.1744980888418 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > 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 to= =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 perhaps,= =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 wrote: > > > Op 17 apr 2025, om 20:52 heeft 'Antoine Poinsot' via Bitcoin Developmen= t=20 > Mailing List het volgende geschreven: > > > 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 on= =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 > > 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 th= e=20 > size of the scriptPubKey for OP_RETURN outputs, as a first minimal step t= o=20 > stop encouraging harmful behaviour, and to then proceed to lift the=20 > restriction on the number of OP_RETURN outputs per transactions. > > It might be better to do both, if only to avoid repeating the discussion= =20 > in a year. > > From perusing the Citrea paper (page 18) it seems a single output is=20 > enough, and they only need 144 bytes. > > 1. Regarding size > > 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 th= e=20 > time there was discussion about how much space Counterparty really needed= =20 > if their protocol was well implemented. > > 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. > > 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. > > 2. Regarding count > > 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 size= =20 > of a single OP_RETURN is limited only by the maximum transaction size, i.= e.=20 > 100 kvB. > > Without a size restriction on individual OP_RETURN outputs, there's no=20 > point in limiting their number. > > That said, it would be interesting to know if any protocols are thinking= =20 > 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=20 > results in fewer bytes onchain than embedding the same data using the=20 > segwit/taproot witness space > >=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: > [...] > > 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 da= ta=20 > carrier. > > Since we're discussing raising the limit to at least 144 bytes, the above= =20 > argument would no longer be relevant. > > 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 of= =20 > 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.=20 > Safety and liveness are defined as follows: > >=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. > > For standard transactions this already not trivially true. See all of=20 > Lightning pinning discussions. > > For non-standard transactions, does BitVM2 keep all its transactions unde= r=20 > 100 kvB? > > Otherwise your liveness assumption requires a direct connection to at=20 > least one miner / pool that is trusted to not censor (though you can shop= =20 > around until the deadline). > > 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 thi= s=20 > list know, since these discussions can take a while. > > - Sjors > > [0]=20 > https://www.reddit.com/r/btc/comments/80ycim/a_few_months_after_the_count= erparty_developers/?rdt=3D53592 > [1] https://bitcoin.stackexchange.com/a/117595/4948 > [2] https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607...@murch.one/#t= =20 > =20 > (click on the html attachment) > [3] https://citrea.xyz/clementine_whitepaper.pdf --=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/= b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegroups.com. ------=_Part_76169_47774300.1744980888418 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > From perusing the Citrea paper (page 18) it seems a single output is e= nough, and they only need 144 bytes.

From discussion i= n person it seems as though they could adapt their use to batch publish the= se 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 der= ive 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-out= put 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 wrote:

> Op 17 apr 2025, om 20:52 heeft 'Antoine Poinsot' via Bitco= in 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 "Watchto= werChallenge" 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.
>=20
> 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.

It might be better to do both, if only to avoid repeating the discussio= n in a year.

From perusing the Citrea paper (page 18) it seems a single output is en= ough, and they only need 144 bytes.

1. Regarding size

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.

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.

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.

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 s= ize 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 thinkin= g 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 Ligh= t:

>> 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
>=20
> 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:
[...]
> 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= above argument would no longer be relevant.

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.

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:
>=20
> ...
>=20
> 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.

For standard transactions this already not trivially true. See all of L= ightning pinning discussions.

For non-standard transactions, does BitVM2 keep all its transactions un= der 100 kvB?

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

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.

- Sjors

[0] https://www.reddit.com/r/btc/co= mments/80ycim/a_few_months_after_the_counterparty_developers/?rdt=3D53592
[1] https://bitcoin.stackexchange.com/a/117595/4948
[2] https://gnusha.org/pi/bitcoindev/03551f0f-272e-2607...@murch.one/#t (c= lick on the html attachment)
[3] ht= tps://citrea.xyz/clementine_whitepaper.pdf

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/b51b952c-b8ba-4f13-a216-c29095c39d00n%40googlegroups.com.
------=_Part_76169_47774300.1744980888418-- ------=_Part_76168_520530924.1744980888418--