path: root/a5/d11aa62686b7a25e70ec8f69b4f9bc911406ee

Delivery-date: Fri, 18 Apr 2025 06:52:07 -0700
Received: from mail-oa1-f64.google.com ([209.85.160.64])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCKY5RHCWANBB65RRHAAMGQEHWAZMGA@googlegroups.com>)
	id 1u5m8U-0002w4-3F
	for bitcoindev@gnusha.org; Fri, 18 Apr 2025 06:52:07 -0700
Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-2cca2c52dd9sf1369225fac.3
        for <bitcoindev@gnusha.org>; Fri, 18 Apr 2025 06:52:06 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1744984320; cv=pass;
        d=google.com; s=arc-20240605;
        b=b/Oad+gAhZ2rt1yoC1anToayFVoqYzeA0IKf8CQPUooIYVKtuIzqKNbKz2OOa3ufK9
         qaj6xGJ5HQAqyu7UCx4y5BLxH8RWsu2zMR+t2YpSY1c4xJzX0i0Lth7ICtVujQALV6SF
         L21ZD8sQILVk1vL26ii1Lt3JQc+DyW7cqSDM/iv5io/7BmSMm2zVutE+WXSVgCNX5mWT
         rkvZIE+EkTcsZzvuqjZua4Hx7c9Mukw+W3h+NK6i/ZTiBC/CkIgeVSadj0wabZgEJXZI
         IPssRnY2fsechhgMz3ZSOuMY7jYsFPZlegGpVXmBhqtSODA7W1ca8udqQ+S06l4XBiJb
         NaYQ==
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:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=emm1AVfVsK6Q1kwZs5ai4aJiiwwB2FF07FWsXUaBsbI=;
        fh=sNWf8GZTG41DFyKUe4hStGSqAgN6mgghj7s+wVStZvg=;
        b=LA2wv9B8zUQJ0NnYNZ5YBEXEsJAmL46/EGkroG8NFKTPz3PDsDI+LwM+UeNpJE55yd
         jGyyRjc0YMUJW+PnWC++bbpBhCQyHBx3xQZV+3TcCEkZWSjkjojFpmnZN9TbnI27DIqz
         1VlOdkoZi9XIksmVHFhC33GpqqrdKx9Oe3eMv9xiwHwtTlKHcy/jo/Pl/Bczw1OaUZ0h
         Vx8aYA67hfPtTOezOxqHkhGZ6VUX0JEl2i8wUhEj0rOJg2sckGrIE1IhZ2VSZI6apfn4
         Xh5v8+LQGWIDxqoP4f0PXI/slKBDbADRrY5lB/O/bLs1DEk2wsNap/Psjmj3VU09GYx4
         rILQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=Y1PbEcvX;
       spf=pass (google.com: domain of vojta.strnad@gmail.com designates 2a00:1450:4864:20::32e as permitted sender) smtp.mailfrom=vojta.strnad@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1744984320; x=1745589120; 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:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=emm1AVfVsK6Q1kwZs5ai4aJiiwwB2FF07FWsXUaBsbI=;
        b=L3BJcBsTN7tGfChoYzBzxftusRSJuIVFjZumeXEdZXaBAsuVt4aEwiG4H2Jb5T1d8F
         PxZW8qLAzUNHPlfGVl2uj8BQHJZbQL1JxN78c/T5tWgYT5NxFlbJWni+ISwHv0hNEtY6
         7uHTsxqvk3llgpzobex/XcB0Zm729UWfztvJ5/Pf80Ksn+n3nEmKP5jIlcr9Gpr7AK+6
         FSCesUyyA2T/wptYUYGBoQTU3yIhMMarK75OnCP/ShH1brYA88POJ7OOB3H117ndmUhA
         sUaWDSeB9PHM5d28jcz8h+4Q1DXfLAsAfmTCRpc2qFygls1UWfkJse/dk78muo2xKecY
         VqMg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1744984320; x=1745589120; 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:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=emm1AVfVsK6Q1kwZs5ai4aJiiwwB2FF07FWsXUaBsbI=;
        b=ZIGMSy8iERvRM3n2zVVZuDpBkgKAOcDAOL8dYmHiw2EqbarJ08YCdBC7vMxqj7uqYJ
         ThEEruUYYvNjs/0VaZz28bYEa1PQsw9zipHW5Ahggq4ZVZIedF1YdwCiygZR22aP/wcV
         VeTBdyZy7EppCFeFpUlDxa0leAk2zx1Y3cdJzKR9j4TSicebpOS9GdKZiyGZt5auFjvV
         9c6AEeHOAJPMgsUcSahqGty1rYBxnRuCS8cboZgIa2AfytcNTVueUAXmKWfqDpIm9sZf
         KbEuFd6Seq/EmRbcjY5iLwpvvNZc2TOqJHbzHGmOgtzkOB8u3pTSvG2jERkM6b8NTd7G
         7pWw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1744984320; x=1745589120;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=emm1AVfVsK6Q1kwZs5ai4aJiiwwB2FF07FWsXUaBsbI=;
        b=szLd9OV0CcENUhWK7pKpIljhHHjWFTy2FvzVwyI9TWuFPOLfdNdv/Ftcex/LHpTbTQ
         1joJjKcwteKcPS7E2YIq3IrDce67ZcGF5k/3dh9w+i9T/aRfvRKfRsXLN+jvOaqrx29A
         IFb0wnb9OopRf6wsPichH+PrZU8oDFGMfXyGuqPcr46uVJ1Mev0NM8Z1KWYx4iJzgErB
         /vngAtadSt1xsGIbQ76J6wMV7zBR7YSI8lAbXDb1EX5R8NhJ3zZtDFZqj/zkUi/PnCkS
         z/jIZXuWbLS9qlR3yOr4rtV6zqUovNYgQ/FaIrZG5DLB7XXvykTlu9B65KyfrpWFwQ4B
         OmdA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCUjNUaRgEYw/x+g8X2M5Utzk6yORKe+GiG3P8EzHOifxxOs5TuAZvpR/Sux78iOqNAjuRtNMdddr2NX@gnusha.org
X-Gm-Message-State: AOJu0YzhT9ypJ0gqiDwg2tRPM9SFsb4XXAc9JG7YFMqpHnxUr+UerFtN
	rUDFQv3cjLQpIdzeHBT2TutXTNonI7AyGoPk6z6e75lyTxna0mXY
X-Google-Smtp-Source: AGHT+IHsFyZH7NGLKVzoutPJsWG7z4dsArPbr47S/PNEYEbV3t30xyjUUlN3cMsgsFAiANaZYWbmAQ==
X-Received: by 2002:a05:6870:fe82:b0:2c7:6ad3:fe56 with SMTP id 586e51a60fabf-2d526bc91demr1399332fac.15.1744984320210;
        Fri, 18 Apr 2025 06:52:00 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAJWAr8NdOrWGuvjYBrYeF5ngJnCSaG0flBjHdqmiH29pQ==
Received: by 2002:a05:6820:828b:b0:604:989b:b46 with SMTP id
 006d021491bc7-604d07d9b5cls973026eaf.1.-pod-prod-03-us; Fri, 18 Apr 2025
 06:51:55 -0700 (PDT)
X-Received: by 2002:a05:6808:448e:b0:400:b832:c61d with SMTP id 5614622812f47-401c0c55f84mr1589678b6e.31.1744984314857;
        Fri, 18 Apr 2025 06:51:54 -0700 (PDT)
Received: by 2002:a05:600c:3b13:b0:43c:fe31:d01d with SMTP id 5b1f17b1804b1-44069ee67e7ms5e9;
        Fri, 18 Apr 2025 06:07:00 -0700 (PDT)
X-Received: by 2002:a05:600c:4f12:b0:43d:300f:fa51 with SMTP id 5b1f17b1804b1-4406ab950admr20460015e9.9.1744981617633;
        Fri, 18 Apr 2025 06:06:57 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1744981617; cv=none;
        d=google.com; s=arc-20240605;
        b=ebhwhwOwOTUMZT+zTVTiT2uNYjqS24QCgJfOyLGZA4FlJZFNWIZ02Rj/cPUow60ZlR
         pZlektHDKDA4SoUJ591oHtd04A9g2GPoxMjqqFv5bL4RRSu+VXvFB2ZQKvI0ocxTle43
         E0sUkJPQCt8yF4GUdsXhopRCCQHnXi+Tq7/ElDKlwWTPlAX0Urvfd+rXKNjMfH0HNarB
         x2js1LEf+tcN1DRjg3bI9ncQUG/WqvYkPcG/ZfMVIMmu0HxMNtY2YTMPLCgwZkAk4ruu
         LTqHEeMRWYr/VkRetH/CH6aRTQRvEXOSkhjlwlY6LhJGZgQP9p5PXHoBiEjajrGaObco
         TUaw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=to:subject:message-id:date:from:in-reply-to:references:mime-version
         :dkim-signature;
        bh=JQrW+Ld9a6XS3H8Pl6nT6tu3stoqf+I3pReVUJi9ozY=;
        fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=;
        b=fQTqhx8zqGcxya2Iq42ol/+MkvuPgxpBMmzwjTDX4DZVZ/SJZOvdBxlPGyHUnkm/z8
         RnTY2TmHwwq906TGbMXws30oexdIrXT4QeQ1EyBBPW2D8ef9R4fmbcLEKXwGVxTXbZCY
         M1MG5q1liA7bSYCDBpjM+fKC7Q8l5NQPeY0+yqyZuXWWFQFZiizfHsezVaL3sa6RuwO+
         tJDHsRhtt+OSZLTcxT3K7IPJJ4pPlCm/LnbnDY4kMTHYrm3RNDOBkB+LEIves36rakQc
         9ma9WiPPcX/xSzidQGf1AxMjj4uxNlnEZzAqH8cFQuzDtJ7g1LE2mQNQYCH7fdYqsTEZ
         noDg==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=Y1PbEcvX;
       spf=pass (google.com: domain of vojta.strnad@gmail.com designates 2a00:1450:4864:20::32e as permitted sender) smtp.mailfrom=vojta.strnad@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com. [2a00:1450:4864:20::32e])
        by gmr-mx.google.com with ESMTPS id ffacd0b85a97d-39efa488fe2si32454f8f.6.2025.04.18.06.06.57
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 18 Apr 2025 06:06:57 -0700 (PDT)
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;
Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-43cfdc2c8c9so10179705e9.2
        for <bitcoindev@googlegroups.com>; Fri, 18 Apr 2025 06:06:57 -0700 (PDT)
X-Gm-Gg: ASbGncv2lYH2dynYGn8DzcFN6Yhe3BvVNGazMSo2Sz5K9FkIp8aM7N9g8FNzhwqS4No
	Kd0K0y9NxxUvZfZVLKj1/Ax7DQo3jTSK7+O+cl/Gs1C+gs/BZpC2oT9XJHgPolqe8Rdpy17YuSB
	ygrj7JDtbgheij1b+0kZW8
X-Received: by 2002:a05:600c:1383:b0:43c:f16a:641e with SMTP id
 5b1f17b1804b1-4406ab6c6e8mr22042745e9.6.1744981616131; Fri, 18 Apr 2025
 06:06:56 -0700 (PDT)
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
X-Gm-Features: ATxdqUHFhBi1UAgqyfUz3Vjw4i262h3P9tgBl-4lsoXJBUpUn8xclhMOVZE6Rwc
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"
X-Original-Sender: vojta.strnad@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=Y1PbEcvX;       spf=pass
 (google.com: domain of vojta.strnad@gmail.com designates 2a00:1450:4864:20::32e
 as permitted sender) smtp.mailfrom=vojta.strnad@gmail.com;       dmarc=pass
 (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;       dara=pass header.i=@googlegroups.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: -0.5 (/)

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