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

+

+