From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 18 Apr 2025 05:16:07 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1u5kda-0000NT-5J for bitcoindev@gnusha.org; Fri, 18 Apr 2025 05:16:07 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-2c855402a6dsf1114541fac.3 for ; Fri, 18 Apr 2025 05:16:06 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1744978560; cv=pass; d=google.com; s=arc-20240605; b=j7omQe1GeNoVpfpN1TgL0BrXxGRU24M9rZnSyuXtYx+rS5f9hMRtzSyaaeFC2JeTWg 8xl2of462rY5K6NdLuo70kSH0sFn6DM2MxKEltcNNjL3jPPllEGgw2cwTTj5joWuE1As h9ibmSHjSHyvah/s+05leLXPE57JLVKJPQIQm2OGasWwxj0Hy1/WWcxirLGcLQSMWbt5 a7hjkVyui+z6CboG94ViLA8ZAcjKy4tIUIG102j+YFtRu0Bgg6QR/pSCsGb6i0LF/YQ5 pXdZRDrS+6Np0q4GU9slHMbTqxdLPBxlUA3Q+BL2RP4MfnVC6cSGdtQZQocwxzQT0wiN 7fzg== 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:message-id:in-reply-to:to :references:date:subject:mime-version:content-transfer-encoding:from :feedback-id:sender:dkim-signature; bh=gJquMVploTOOl6DGY2oOoRHb0MMBpvFzRXNEJrWSY+E=; fh=zOvdCvQrkHLBAeAB2TkywPtDFT2z0RGamG8mFLpTDKg=; b=XV3aLJxyM4GWLyC6/WUx55Ln8/NrV5NojtTCxi+Ton3JOVKJiVUmObbjgx7sMVju/J ilOz7lW4gjrLmKryKYrShPlSAv+NK1GUeXp5wIOLiE9w0iTzbmEQyn9fa8U+dVP9YRJJ Uts2dDrA+H5cv564Bjead1+GG7Qft/SMJ12x1xTI4s9mrbkDN61BGRVEEbzGKX6fnedq yqbUMXw/ubMWaqGzpGtBBLGZNCjH4LKVSOLhjePSXu1EYmUs19UcQ9xNfK+7gKwX+seW lniwWFSovAJbtvtX7+ouRw2kaQ39VlVnsF7QTfzROQZffqpblldflGsairHWIrfdQHyM EP4g==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@sprovoost.nl header.s=fm3 header.b=L8Vcwje3; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=KwrBloYf; spf=pass (google.com: domain of sjors@sprovoost.nl designates 202.12.124.158 as permitted sender) smtp.mailfrom=sjors@sprovoost.nl; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sprovoost.nl DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1744978560; x=1745583360; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:message-id:in-reply-to:to:references:date:subject :mime-version:content-transfer-encoding:from:feedback-id:sender:from :to:cc:subject:date:message-id:reply-to; bh=gJquMVploTOOl6DGY2oOoRHb0MMBpvFzRXNEJrWSY+E=; b=UhRgD3WZViRKfZql1BDhT4BrEASNJXgb3i0utUgZ+cqTG/3x5S4nhPvPPWjQM4GcY3 nGJZzVsgJcvG4yGXG8QoixQSrkxNYK0xv1VKIaGnJOs8b3tJ8gfOGsa1OEVKPPNJDiJv 93kirg9XX+tX67Lx9/tjRVdMVv2vf8VCqfoDeTkKPZSYn57PQ+nmgYClN0GpVi1Q/rKZ QAm813jps+ldQk6iFW4xxxWlcyFB0pGwqWkRs0iq6x90Y+VTAHdJEM4M+iBX/qbgbkZP pLYl9Gc0AMO56K9wrUyrBPcAJ6INFWuZoD5j/N299SK2sUkWMxYpCR8So+ltJBi8WhkH Z99A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744978560; x=1745583360; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:message-id:in-reply-to:to:references:date:subject :mime-version:content-transfer-encoding:from:feedback-id:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=gJquMVploTOOl6DGY2oOoRHb0MMBpvFzRXNEJrWSY+E=; b=C6FGqWzngECWy0owIVmM2dZmFHUTkS16o1zHVOImQFpVDUeHALKupmHUKfFobJfsp5 EvzLkzEcCuBGgTrGz3Ux0Nvafr6CctKJ7An7lLKHBiMGT+TEyraVuL1KJANlB0c8QtUh I8btwwyJYrKTKSdwj/6Mgi2BY6MyHeTrwcexVm+T34sx/40TTROJL6bSVK+B1LWe0iKl /Ga3jjaAPVnffTUG8BWJUSoQQf44G+xRIHIajs9+ywTK5zzJ22AADt0m+5oat/vBoYAy AGZRKCRyI0AMNbkg2p/x+KBO+Zp68YI3xeYf3CFrwKvbb84t5FxUZCgnnaZddw/tkadC Vtog== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUq/5EZAt8QpYGMD9XoX+PXGs/XhbX2O50euCdQm/t/940zHOjanZg29p9de2dO5ARnKHuF44iFtJiA@gnusha.org X-Gm-Message-State: AOJu0Yxs8WVQfjzQkRWdXhjtpTheadZunnw/AFffr1yiTC+lSG7+hMSg lfmrolsCQhyIH+MnxqllLfD5zrL0DSfrXWnKFiyMmvWRkx4B1YxO X-Google-Smtp-Source: AGHT+IGq54r4h4HQV5Bfgo/CoyLoXMtqR1Je+z982RiAKX3ffdHXAiD7oXJ10QmGdv6IgXEVKb4Ohw== X-Received: by 2002:a05:6870:af87:b0:2c2:c92a:5789 with SMTP id 586e51a60fabf-2d52697472amr1388526fac.5.1744978560212; Fri, 18 Apr 2025 05:16:00 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAKhvPz9AyN+fj9GLcnSPOxQAOfWKNTAqRu337wLFYN1uw== Received: by 2002:a05:6871:788d:b0:2c2:33d9:946e with SMTP id 586e51a60fabf-2d4ebf02eb1ls873984fac.1.-pod-prod-08-us; Fri, 18 Apr 2025 05:15:55 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCXTty2DrehlHubKUUjFSX5O1cetzPLh2ZE8iZTuFTzjeC8s6ZCzPIAIPFH4E+wSERoq0p8hGjuVdhXA@googlegroups.com X-Received: by 2002:a05:6808:318b:b0:3f9:d5a2:899b with SMTP id 5614622812f47-401c0cadd25mr1189762b6e.38.1744978555432; Fri, 18 Apr 2025 05:15:55 -0700 (PDT) Received: by 2002:a05:6808:d0:b0:3f9:f009:458e with SMTP id 5614622812f47-401be5f4b9bmsb6e; Fri, 18 Apr 2025 05:03:24 -0700 (PDT) X-Forwarded-Encrypted: i=2; AJvYcCU/bwZMiBqSQ8+PAcUpqc3XolNw9+uSdESigqEiaceEUcok3GACRAzX6LmfJFJNPouMqfrb0FobyqXN@googlegroups.com X-Received: by 2002:a17:90b:57e6:b0:2ff:5016:7fd2 with SMTP id 98e67ed59e1d1-3087bbbfcb1mr3918177a91.24.1744977803066; Fri, 18 Apr 2025 05:03:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1744977803; cv=none; d=google.com; s=arc-20240605; b=kuwacq0N746YnS92g5D9XCQ2OXqCWA2+Z3hUsFj7gMj6zDiOtIAA8pFx4PMkmKVvSV v41iiYT8hBvhD0svzHZmsVI5hZWtfoCdWc6a8GgAR7XlEqU/AtyocG/ngnfXqJOhAciJ 7kEB9w1TA6MswJ11GuCXNljpGo1f3uNMfqnPSHKkLqGtla1C4lNDtneM38J+vW6YSpX8 lCCtWF7NWbNHiui08o2OaIssmwPsnO+9u8nvLa8l0y6pSV9TeyISLopC9Buok00PHQiE O874cX1/31XrMaMmsIGI1v6gUdDew1WVbWMYOKtcW4gNyOg5MES+0lPibyOTJQyxHw39 S84g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=message-id:in-reply-to:to:references:date:subject:mime-version :content-transfer-encoding:from:feedback-id:dkim-signature :dkim-signature; bh=rsMDQpXgWIos3/oSWHw2zcHGPdP4bPLBCVQ+sCNu98k=; fh=02nJZxx48b/TyKrcvewNiN7FJtTrEjLEvj+vPN5r4s8=; b=dwyWXhHG7Xu42DWs3bC6/stE4zcPOljSfbfCrqRykNoLZacv9qNASjZ1kdmXzdcyQu XdD8WPchQwqB3kSl24PB8xcPaZZLS2AbWvl8KcsijC4+5EdFc8k3A1zeA2WkNfXD/I/I rYBLs9i7mfbCO3YbG9H4TB6DdO46TDalkNaOQVVuHLG+L2yRgMnCgaysRPxEdSg9RJUL v8eAvcWAsnniZlsWM/jZXiN1u9jgZjbspvhLzBK0QWqXFQ/q5wE5Q2GDoyHMVV8XMpWT gw8PgCx2zwRi06WYfFLA0HIkOHEIPAEgeA19FJ11arDrTXYwnJYY7L6ZyIXJuT6U04NW TNMw==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@sprovoost.nl header.s=fm3 header.b=L8Vcwje3; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=KwrBloYf; spf=pass (google.com: domain of sjors@sprovoost.nl designates 202.12.124.158 as permitted sender) smtp.mailfrom=sjors@sprovoost.nl; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sprovoost.nl Received: from fhigh-b7-smtp.messagingengine.com (fhigh-b7-smtp.messagingengine.com. [202.12.124.158]) by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-3087dddd5d6si46904a91.0.2025.04.18.05.03.22 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 18 Apr 2025 05:03:22 -0700 (PDT) Received-SPF: pass (google.com: domain of sjors@sprovoost.nl designates 202.12.124.158 as permitted sender) client-ip=202.12.124.158; Received: from phl-compute-11.internal (phl-compute-11.phl.internal [10.202.2.51]) by mailfhigh.stl.internal (Postfix) with ESMTP id 40E7F25400A5; Fri, 18 Apr 2025 08:03:21 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-11.internal (MEProxy); Fri, 18 Apr 2025 08:03:21 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvfedvuddtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih gvnhhtshculddquddttddmnegfrhhlucfvnfffucdludejmdenucfjughrpefhtgfgggfu ffhfvfgjkffosehtqhhmtdhhtddvnecuhfhrohhmpefujhhorhhsucfrrhhovhhoohhsth cuoehsjhhorhhssehsphhrohhvohhoshhtrdhnlheqnecuggftrfgrthhtvghrnhepgeeh ieettdeiheelhfefgfejtddtfedtvddvueejheffjeduiefhjeduudfgveejnecuffhomh grihhnpehrvgguughithdrtghomhdpshhtrggtkhgvgigthhgrnhhgvgdrtghomhdpghhn uhhshhgrrdhorhhgpdgtihhtrhgvrgdrgiihiienucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehsjhhorhhssehsphhrohhvohhoshhtrdhnlhdp nhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepuggrrh hoshhiohhrsehprhhothhonhhmrghilhdrtghomhdprhgtphhtthhopegsihhttghoihhn uggvvhesghhoohhglhgvghhrohhuphhsrdgtohhm X-ME-Proxy: Feedback-ID: ie5e042df:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 18 Apr 2025 08:03:20 -0400 (EDT) From: Sjors Provoost Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\)) Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions Date: Fri, 18 Apr 2025 14:03:08 +0200 References: To: Antoine Poinsot , Bitcoin Development Mailing List In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3826.500.181.1.5) X-Original-Sender: sjors@sprovoost.nl X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@sprovoost.nl header.s=fm3 header.b=L8Vcwje3; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=KwrBloYf; spf=pass (google.com: domain of sjors@sprovoost.nl designates 202.12.124.158 as permitted sender) smtp.mailfrom=sjors@sprovoost.nl; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sprovoost.nl 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.8 (/) > Op 17 apr 2025, om 20:52 heeft 'Antoine Poinsot' via Bitcoin Development = Mailing List het volgende geschreven: > Developers are now designing constructions that work around these limitat= ions. 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 on the size of OP_RETURN= s[^0]. Meanwhile, we have witnessed in recent years that the nudge is ineff= ective to deter storing data onchain. >=20 > Since the restrictions on the usage of OP_RETURN outputs encourage harmfu= l practices while being ineffective in deterring unwanted usage, i propose = to drop them. I suggest to start by lifting the restriction on the size of = the scriptPubKey for OP_RETURN outputs, as a first minimal step to stop enc= ouraging 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 ot= herwise using bare multisig. A similar argument would apply here. At the ti= me 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 si= milar lines we could pick a number based on various cryptographic commitmen= t schemes, and then only raise the limit by that much. But that just guarantees repeating the argument in a year when some protoco= l needs a slightly higher limit. In a post-inscription world that seems poi= ntless. 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 size of a sin= gle 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 poin= t 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 result= s in fewer bytes onchain than embedding the same data using the segwit/tapr= oot witness space >=20 > Yes, a back-of-the-envelope calculation has me thinking that only payload= s of 135 bytes would be cheaper with transcriptions than with nulldata outp= uts. In detail: [...] > we learn that nulldata outputs are cheaper up to a payload size of 134 by= tes, only above that inscriptions become a more blockspace efficient data c= arrier. Since we're discussing raising the limit to at least 144 bytes, the above a= rgument would no longer be relevant. And from what I recall at the time that was the only remaining reason to ke= ep the OP_RETURN restrictions around a bit longer, despite heavy use of ins= criptions. 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 with liven= ess 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 Light= ning 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 shop around= until the deadline). Conversely, having actively used protocols that frequently require going ov= er some standardises limit puts pressure on that limit for the reasons Anto= ine 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/comments/80ycim/a_few_months_after_the_cou= nterparty_developers/?rdt=3D53592 [1] https://bitcoin.stackexchange.com/a/117595/4948 [2] 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 --=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/= C7E2D805-E70A-455C-BDA1-224024BE93B3%40sprovoost.nl.