path: root/44/0e6c18d5a75844fde658a972bc7f75eb984eb5

Delivery-date: Tue, 20 May 2025 14:54:35 -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+bncBDL4XL646QOBBD7UWPAQMGQERP7CIMY@googlegroups.com>)
	id 1uHUuw-00009z-6M
	for bitcoindev@gnusha.org; Tue, 20 May 2025 14:54:35 -0700
Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-2d50f1673ddsf3572680fac.3
        for <bitcoindev@gnusha.org>; Tue, 20 May 2025 14:54:33 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1747778068; cv=pass;
        d=google.com; s=arc-20240605;
        b=BknjZAUfhn0Q9rC9aMDtgNNXTAQ9PhmI3aU8G8ZXoTQGqOpJgYTS0aiXYXfU8AoVXw
         qV270ywS+N8FI4TG3rhULsMijAY/163PEwP69Oa8Jt5PgqX+qEq8y92ROuI7myCLQUnQ
         e4B6J/FfkdeMk+Rt3JgZwOwBh6a2mgkHhQSGYTJQB1JRFAadnY9Q2tNeNBdF9HSjB4WC
         wPQimMfym7S3wz/0mF+V//wFOK/Zz5/RoiCfgPUGbSp267uKY29lAgmVZtoVZsx2d1tw
         3X0DVIdDg3ZRkELQ1Wnxg2uhpWjnbo5qBNXr2mhZOIiXlz78YFeWGc7dBrBOv7qYj9oq
         98wA==
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:content-transfer-encoding
         :mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=zNR7iTIdndeGVOYvHVm8ZHzAYyCh/1jOG50q0LvTeKw=;
        fh=0+akn6Fj5VYtzYT9n/ry5+VW3OtYXBcyKQx9g8hW2gY=;
        b=fqJ6Q9UcTYVZ4e0F2VLSFc9nlFdUZwSgla99KXEp+MGWW6DJH+C3XuvqKFNJcG3Zdr
         1AybL1HaCH8KcFVob4j9GYx/aHY+axtRJwarAfRKL+uYcK+Gq/VOv69iLfAWHkZaEjL2
         NKpUQdUXiAQTxzhsy2+X2zwarkD9+QbZkkZL4u4wFkTJK9m9x8olx4Gqr0afkyyCWSYD
         UvQwTXM2k/gln7XzW5CR5bowTDwQgTO6cGGwDCSdOeiW3SP3BWlATbX+nIlo1AzOACkE
         l5iINaajn2oeiKhSPEthbehZhkYAubfTvQz7Wx0mReUwBg7gQ3zGpAp/2+jcc76jZXAS
         OsrA==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=JlCh5Yy7;
       spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.16 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=1747778068; x=1748382868; 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
         :content-transfer-encoding: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=zNR7iTIdndeGVOYvHVm8ZHzAYyCh/1jOG50q0LvTeKw=;
        b=rBuFovL+NnSazuciNcLiTMwSWNpfJ0h81lC1RGX8ZsD/nIvVoxIn8NiW3nWe5BREUH
         XebVwoRKdGhG1LK2nMZMTPmr0iGYf8Db4VNv+kmZhmYUJdVx7LMbNsj3969KA1HeBn5P
         865Q4US1mrwHPjQAm7rYaqZs/XpefS7THUU8xsxRIyc7cJZr/w83vSKfNBkLCSxXCqBL
         qNWRy8Sp3YyHhL2Zd0aNDmUaf4fnv4eXsVM/yfM8+iBvRR2Zaew3fsyxOiToOED504jD
         r+fHVZ2Je3p7XXkj24LgkVZws2mu+/3wr/s0bqd11zA2V1FAw/VmXKxZWe32z3ctOx0+
         HVFw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747778068; x=1748382868;
        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
         :content-transfer-encoding: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=zNR7iTIdndeGVOYvHVm8ZHzAYyCh/1jOG50q0LvTeKw=;
        b=m174WDYXFa4rplSy8Pw0XUstdGa6SSwrCafOytAEUiLh8dMoh9eGBsY4nkLypRrFml
         37Z/JimWrGDzcAHlNmcQm0GfZA/snUVAeEZ5wMfWfYUPR+yNlVQvrjbJ4vXVku5Rz2dh
         3S3l+Zc/60w7dEIJrcNXf5tzkqsQJKpXcqFMCtvxnX9AY7+cjnMycadI123CtgeCQifM
         w3iBULQzNcMIKyL/nijcWTtLvDKj0mJTSc+ELqhp1dsKeJba+mjMcsnFklNE+EOP6H14
         sFrXuDfjs8VbMHfSSiig7wfA1yi1lv/QSh17hBK2BmANW/S61FcFSzN64KcOtSR7BKDl
         yQyQ==
X-Forwarded-Encrypted: i=2; AJvYcCX7kamoZXdhh7rwK4MsH4zayPr6SIHc3F8Go47X1Xr/OvbrpFwHdVl0UpplZUJ5EdWWvngQjLeUwySt@gnusha.org
X-Gm-Message-State: AOJu0YxjmdaoSDg6D4xQv5OATpy+eadRIbsyRgoIYf4xJiTGIEZaiqSo
	7yaZxRFxMxcESwqCFiCeHzghUsXoNnxH6m4tyafpS6kD0l6VZYCDIfR0
X-Google-Smtp-Source: AGHT+IGhpNAmvMdk0ftSWR3QZoF+ie6XfEJUE8X9fEGHUUgtGcSNwWRf2UW7yYowLCI8RDbAmk/bbw==
X-Received: by 2002:a05:6870:de12:b0:29e:2d18:2718 with SMTP id 586e51a60fabf-2e3c1e6b6a0mr11291773fac.28.1747778067955;
        Tue, 20 May 2025 14:54:27 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBEByI2K1sZPagWl2B7by97dXAyLNrW0626mVUqa9oQdsA==
Received: by 2002:a05:6871:20c5:b0:2da:fbc:5e7 with SMTP id
 586e51a60fabf-2e39c84e483ls3172863fac.0.-pod-prod-07-us; Tue, 20 May 2025
 14:54:23 -0700 (PDT)
X-Received: by 2002:a05:6808:3a14:b0:3fc:1f7b:c39f with SMTP id 5614622812f47-404d874a88amr12363634b6e.18.1747778063401;
        Tue, 20 May 2025 14:54:23 -0700 (PDT)
Received: by 2002:a05:6808:6389:b0:3fa:da36:efcd with SMTP id 5614622812f47-404da18c90emsb6e;
        Tue, 20 May 2025 09:26:12 -0700 (PDT)
X-Received: by 2002:a05:6830:3908:b0:72c:10d5:783e with SMTP id 46e09a7af769-734f6ae8ab6mr12587858a34.10.1747758371152;
        Tue, 20 May 2025 09:26:11 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1747758371; cv=none;
        d=google.com; s=arc-20240605;
        b=QpxV1rdlx4h7eHNhpW6bwnBoo7RW/yP5sXlnr5By4lAkcKlDu8RtFsUFTmu3vEiv5s
         1S8gC9WnEPc/mVJbb0vHCnRRiymA/l71BS3SQi0V9pYdBUD67hHIGIyQZMTzSm0vfQiC
         u6kZ9Z0fMcwEUzqDl9ZXU8S6d/IS2lR+ZP4A4jNbfBb/a1vqPnDdIVmLit4spxjLfTq/
         qENZ4GtxFg3iPSj/v58pLbqOc8/cW8vmhmNFkfl4dSpFaFbylzHc7A+ffrVIdORddTDQ
         uQep/3WeFGqMIHYZvG+Bom51Dq5Y9oQ4ehknatCGSDYMZwifi5AQeU7B8/0OCFE61Jb5
         t7zw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=content-transfer-encoding:mime-version:feedback-id:references
         :in-reply-to:message-id:subject:cc:from:to:date:dkim-signature;
        bh=JfzHZzGdLtkiR6p6ZkytN/Gcr70piMNzCxIhyBR37XY=;
        fh=yPd8HNyAt94w6+9mawPnFhKq8crEnOt8R5D/kg3m3ro=;
        b=HJI8VpbW+Eux/65m6VlNEN6wQ86SZs3Csh/AG3JPGsJC6FxE4R33d/ttSp0iKePhYJ
         YtD1o6oJkgz6NMT1l5o/m/Fe+Ny1+dwvktt6f60nE+pr5W07XFy+Mi1+7JHe2cK7GKVn
         bKAYrjs9JlzPCdWuY2nkPhCuIXD0C5XVcFikmitK6mrsEwYayCMHaToRxvgIOCnUbI2Z
         ba14Eb20DCwXgyHB8tX6OlyQNzyvGwEa+WscTkUO0r8apPP/gkffzreesYBj0wfn5Hcp
         N2c+VxE2uymcegJL9ynzpKsAkrqsQBrMUQqSiMSn/Iw8Y4WNLlcP2BPXaDW5yKhp35z9
         d51g==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=JlCh5Yy7;
       spf=pass (google.com: domain of darosior@protonmail.com designates 109.224.244.16 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-24416.protonmail.ch (mail-24416.protonmail.ch. [109.224.244.16])
        by gmr-mx.google.com with ESMTPS id 46e09a7af769-734f6a3e497si458965a34.1.2025.05.20.09.26.10
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Tue, 20 May 2025 09:26:11 -0700 (PDT)
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 109.224.244.16 as permitted sender) client-ip=109.224.244.16;
Date: Tue, 20 May 2025 16:26:06 +0000
To: Peter Todd <pete@petertodd.org>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Removing OP_Return restrictions: Devil's Advocate Position
Message-ID: <7Q6uglccxrI_LPvP2bKeTwFcBAKJ5u8u6NHtDl-dNev_kplv2lfh46r-z2iflmtnnsa8YWgn1A2M8S0jLORI2GxwNQ7qmfyM2jqQiB6JTiw=@protonmail.com>
In-Reply-To: <aBUlEOBqqrOIGHWC@petertodd.org>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com> <IpyzvdqFhM_40OKYdilNrHU9u_cIx7BKlYKBUgTGPW6idPAItRiza5tq8B1jEs141ypieLGkR2UMRIxg0qdxBMl6DQ3UKaQsID0gBjWLXtY=@protonmail.com> <aBUlEOBqqrOIGHWC@petertodd.org>
Feedback-ID: 7060259:user:proton
X-Pm-Message-ID: 43b9ce9dc80ab00a01121428c73a810c436d7ff7
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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=JlCh5Yy7;
       spf=pass (google.com: domain of darosior@protonmail.com designates
 109.224.244.16 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 (-)

> With that in mind, I thought it'd be worthwhile to Devil's Advocate the c=
hange, and go through
> some technically valid arguments against it:

Let me add a steel man for another argument against the change as proposed.

# Lifting the limit *entirely* is unnecessary

Bitcoin Core's standardness rules fail to deter unwanted Bitcoin usage in t=
he presence of sustained
economic demand. They may only cause a minor and temporary inconvenience to=
 users of such
transactions until they set up a separate transaction relay network or star=
t using competing direct
submission services.

That said they can be an effective barrier to bootstrapping such demand in =
the first place. If we
take the example of inscriptions, it is not hard to imagine that if the lea=
f script size had been
limited by standardness from the get go (which may be undesirable for other=
 reasons) inscriptions
would have never really taken off.

The renewed discussion around relaxing the OP_RETURN standardness limit is =
due to newfound evidence
that people attempting to use the transaction relay network are working aro=
und the limitation by
using fake public keys in forever-unspendable outputs, which impose a much =
greater cost to node
runners than simple OP_RETURN outputs. This was illustrated by Citrea's Bit=
VM bridge design which
requires storing some data specifically in the output(s) of a transaction.

Such design only needs to store a small amount of data there. However we ne=
ed to consider forward
compatibility in changing the limit, as tailoring it to the very specific i=
nstance of Citrea may not
be a good fit for future usecases. We may not notice the publication of a f=
uture design until it is
actively being used, at which point its developers might understandably be =
reluctant to go back and
make the change. Another possibility is that developers of a future applica=
tion might just not be
interested in engaging with our negative externality concerns after the fac=
t, but would have just
used OP_RETURN outputs in the first place if there were an available option=
.

This is a valid argument for leaving some wiggle room for forward compatibi=
lity with yet-unknown
usecases. However if we think on the margin it is not a convincing for goin=
g all the way to the
maximum standard transaction size. Certainly it makes sense to go for insta=
nce up to 1 KB. But what
is the rationale for going from 1 KB to 99 KB?

It is easy to relax a standardness limit, but very hard to go back. In a se=
nse, what we want for
standardness rules is the opposite of what we want for consensus. Relaxing =
the limit on the size of
OP_RETURN outputs may enable unforeseen usages that we would not be able to=
 prevent anymore once it
is done. For this reason, we need to be conservative in picking the new lim=
it.

Lifting the limit is desirable. Lifting the limit *entirely* is unnecessary=
. Instead of the implicit
~100 KB limit, a more conservative limit of 1 KB should be preferred.



On Friday, May 2nd, 2025 at 4:03 PM, Peter Todd <pete@petertodd.org> wrote:

>=20
>=20
> On Thu, May 01, 2025 at 10:40:19PM +0000, 'Antoine Poinsot' via Bitcoin D=
evelopment Mailing List wrote:
>=20
> > As i have repeatedly asked people to take conceptual discussions to the=
 mailing list, i am circling back to this thread to answer objections. I ha=
ve also written my point of view and reasons for proposing this change in a=
 blog post which goes into more details: https://antoinep.com/posts/relay_p=
olicy_drama.
>=20
>=20
> I agree with the linked write-up: the quality of debate has been
> atrocious. We've had a bunch of people who should know better, making
> points that don't make technical sense, and a bunch of passerby's
> repeating that nonsense (as well as even more nonsensical arguments).
>=20
> With that in mind, I thought it'd be worthwhile to Devil's Advocate the
> change, and go through some technically valid arguments against it:
>=20
>=20
> # Uninterrupted Illicit Data
>=20
> Credit where credit is due, this was the only reasonable argument
> against that was actually brought up on GitHub. In short, OP_Return,
> unlike other standard ways of embedding data in Bitcoin transactions,
> allows for long uninterrupted, arbitrary, messages to be embedded
> verbatim.
>=20
> The claimed risk is that this data could then end up peoples' hard
> drives, complicating forensics analysis in the future and potentially
> falsely incriminating people. (if you can encode your illicit data such
> that the right bytes happen to match Bitcoin opcodes, you can already
> embed it verbatim, uninterrupted, as seen by how inscriptions embed data
> in witnesses; Martin Habov=C5=A1tiak already brought this up on this very
> list).
>=20
> We already have this issue with dumb virus detection software. Which is
> why a few years ago code was added to XOR "encrypt" the block*.dat files
> by default (chainstate is also XOR "encrypted").
>=20
> The only remaining argument here is if we should go to the trouble of
> adding code to Bitcoin Core to convert existing block*.dat files to the
> XOR scheme, without re-downloading.
>=20
>=20
> # Setting Policy Expectations For a Consensus Change
>=20
> While it is clearly infeasible to prevent people from publishing data
> with Bitcoin's existing consensus rules, it is hypothetically possible
> to make data publication somewhat more expensive with consensus changes.
> Gregory Maxwell outlined how to do so on this mailing list years ago
> (I'm not going to dig up the reference). Basically his approach works as
> follows:
>=20
> 1) Limit all data in the chain to be either hash digests, signatures,
> pubkeys, or trivial values like true and false.
>=20
> 2) Require transactions to prove that every item of data is what it
> claims to be with, e.g. a hash digest pre-image, a valid signature (for
> a pubkey), or the fact that a signature was valid. I may be wrong. But I
> believe that with protocol changes it is possible for Lightning and
> Ark to work in this model.
>=20
> 3) Phase out non-compliant transactions, e.g. applying a block-weight
> multiplier that increases over time to eventually make them entirely
> unaffordable.
>=20
> Note that such a scheme will require massive ecosystem wide change:
> even existing address standards will need to be modified (and made
> larger) to prove that you are paying to a real address rather than
> something encoding data.
>=20
> Also note that even this consensus change still won't entirely
> prevent people from publishing data! No-matter what we do you can always
> grind pubkeys and hashes to set the first 4-6 bytes of them to the value
> that you want. Thus if you're pushing 32 bytes of data, encoded as 33
> bytes including the serialized length, and get 5 bytes per push, you
> have an overhead of about 6.6x. Existing data encoders have been happy
> to pay even more money than that in terms of increased fees during fee
> spikes; the difference in cost between witness space and txout space is
> already 4x, and some are happy to publish data that way anyway.
>=20
> A tricky thing here is upgrade paths. If we make these rules apply to
> all transactions, with any version number, we've radically limited our
> ability to upgrade the Bitcoin protocol in the future. We probably can
> make this not apply to transactions and taproot script types with
> unknown version numbers. However we'd have to do something like ensure
> it only applies to insecure transactions without signatures. And even
> then some miners will bypass this by mining that stuff anyway for a fee.
> That's pretty ugly. Maybe we can make a mechanism where miners signal
> support to allow new version numbers first, prior to an upgrade. But
> that also adds plenty of complexity.
>=20
> That said, if the Luke's of the world want to make a reasonable
> technical argument, come up with a reasonable scheme like the above and
> show that it has a chance of actually getting implemented.
>=20
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org

--=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/=
7Q6uglccxrI_LPvP2bKeTwFcBAKJ5u8u6NHtDl-dNev_kplv2lfh46r-z2iflmtnnsa8YWgn1A2=
M8S0jLORI2GxwNQ7qmfyM2jqQiB6JTiw%3D%40protonmail.com.