path: root/86/fc81884d6e265e19234e0237cb3f703e42b432

Delivery-date: Tue, 20 May 2025 16:41:24 -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+bncBCJNLJPWXAIBBGVGWTAQMGQEDT6RCOY@googlegroups.com>)
	id 1uHWaJ-000337-0s
	for bitcoindev@gnusha.org; Tue, 20 May 2025 16:41:24 -0700
Received: by mail-oa1-f64.google.com with SMTP id 586e51a60fabf-2d9552202b1sf3562927fac.1
        for <bitcoindev@gnusha.org>; Tue, 20 May 2025 16:41:23 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1747784477; cv=pass;
        d=google.com; s=arc-20240605;
        b=IX1h1qX9yR9yFNOzmc/NfGab48+eSZlCjnwFDiw8LsIKw0wVONyxaGM2kUdtSTlYef
         WbPtOsxgeRVu9wIuC4+VuHK2c403e+0VMGdbMeci/klqpjRxjH9bAMOEkGxrNpkW+E3g
         q/Q7BUfUzPr18jv23K8k5akvL9F6k2TDqBxncpPmCIH0Zr8tCgsST+C4AbN0KLCJTjhO
         YQVJT0CSuWZBXRoHHEX2EDZU4azua+484pihz3cvKDmnjKRmGboBuUQdrcWCMGWVQ71G
         ZFBFc48lYuBUdmuPX8WKGxi6xE/S7tK4kOu+MxeEUkNrBUxQRiwiUpQcOY2Qz+qytdSC
         n/Pg==
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:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=2+JwcN6wIHZ9JPQ4dPOQTbzFunhwrKgNOgIahA4SzXM=;
        fh=UIdIxs0f+ZsnQBxPFhZXy8D5ujLTqlnWpOol7g9WfcU=;
        b=Fld3ZEbCdC5Z0z+TJSD2Pf/0Zgv3LJlM1t6d86duzz4IZPkozt+DzXVCLKNLsWnory
         OuaCtDFN7wyZaUfFjWth0i1GASXX1u/vK3uyjZpGPhR1Skc6ex5N4xOoTzyWJbWQZ298
         eQmaT3WOTn5HkBRir7kBUrrOLTIcjyuD5QADggAxIU88K/h3uD0AE6LtW8Giz2to0bs1
         irYtfxvP1RTXpp8+xP13wopcPIiAKa+2J8NqFThMGmUJNvtW0hPhJAhOFa9LBwg8OdSm
         +vMXV7tQOJOy7HZF9yj/k9YNQdhsT0kF1yoyYCOqSL/Z95YhSbS1EWNBmVbERbkU2yKe
         /YVg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=TFZpOr5d;
       spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::533 as permitted sender) smtp.mailfrom=gmaxwell@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=1747784477; x=1748389277; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=2+JwcN6wIHZ9JPQ4dPOQTbzFunhwrKgNOgIahA4SzXM=;
        b=qcYG1T/FZZqqB3WdGP8nK6uZu996TxrGw8F9/QSgEYsuoi/ElaQHIvHBAD7gwNPG4F
         w/UuL6ueAkCkPMcS8U9DPr3nvavF2qyTN2KgQqXJ2Ae7D1kDnE7ElDkVBsVM0JgGCz3h
         HSgYS64QyB1hQ4wclrz7BuTxC18T0CKttEvFVPosdfLHqUaJ1iVPaIdjdB5waoRDy2ys
         0i7GtRDTw2laLpWNuUokEOL3SgK1RTuhPuhmuYS1JWBQ1SQlC2HZLuPaI6+xrYaVn9D+
         InaTkHWdj3/hxWkKMEBIfW8TektDqai9PUPoxpIqMK+9KPvKFAk8yQiXColihLLLRASU
         i4gg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1747784477; x=1748389277; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=2+JwcN6wIHZ9JPQ4dPOQTbzFunhwrKgNOgIahA4SzXM=;
        b=dBJlDI1EewVgVM7he9UPrP9FrBuFmlU3yrH0DgkdCN25HHsU4r3YVQZ6usBosDedqQ
         XFffQfYqgPxqiXAYHMFLR5K0WcHLuo1CPcZ2M0ukYl0poRsbOChTDI5GW3RuGRAu8TBO
         RwCz58gaj2L35IQIFEJ2qbkuX6d1bJbdEgD7HAe7nY5pWvwXkeLFgJkHqIYuOgiNADhV
         YX1rc/OU5tLJ+UEAxANjMXYKZCHiCoSxI0pejqv7eBduJJyl5UpSGryfITQxfpT5XztD
         nZqjAzNuuCXX8KnSJewCaB2y8Tj0OII+KtIwbBg77LNx+lVL2hfmub6gELt4BEpdcWdW
         P6DA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1747784477; x=1748389277;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc: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=2+JwcN6wIHZ9JPQ4dPOQTbzFunhwrKgNOgIahA4SzXM=;
        b=ekla1tIRhlU7umNVxmrXd5V7XRg1/RVUuEdP8npS4cz9NCxUBTuIhj3nLEBpFRRdz2
         92T9OXQCrGZIY7A2rMbcL5mJnd/c62soggFDLzZiabSwCjqByGAaiR/QzbT4gOO3Dqxn
         UR19KZ+/jxCCvjI7OpvVS+wZt1LMcLgFZUe72GVWyWMJMWKNwahQM+C1lvGO8RQa0Q4F
         vqDqdsUb7iccvDrjbM51uGQok58nGlXklyeS1MCjao/bXF7jeYCK5dbviL6+XYsy5mRB
         eDqX7xuP4WFiwFOV7KcMKBxut0e4uDNc9H/qohVP8YuEj5OuJ+KdF8ApPV424qR1OPYx
         E8yA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVVChY5jTnL0k9kGuyOjJyGAzgdHCEYUEjC6HM0cW777jxBfrms1vd1+6+ny3ErTXWW4dfRFizEtpWC@gnusha.org
X-Gm-Message-State: AOJu0YwPp+9bFfP5a3+amqRs1CZhW05EDc9z21ovdxD26FsohHnJ7Y7p
	ZktC0bgpRidQ3HZx83kTgM3U+ngfrj+c+WHFBCL10r0mioaRevEL2mrm
X-Google-Smtp-Source: AGHT+IGCtoDWTVVd6EEfjBrdUCWIW1riOGBoBTRa+AEWe0pKX8B4Zk6LXcqOVqsU7YsOgtLQviIXuw==
X-Received: by 2002:a05:6870:1d3:b0:287:471:41eb with SMTP id 586e51a60fabf-2e3c1b6789cmr10885077fac.6.1747784477262;
        Tue, 20 May 2025 16:41:17 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBEwXV8BpjP9u/BZQOPpCKkn8de3i/c9Uvz/AJha3zlJ+Q==
Received: by 2002:a05:6870:2f01:b0:2c1:8546:7864 with SMTP id
 586e51a60fabf-2e39cd021f4ls3550090fac.2.-pod-prod-07-us; Tue, 20 May 2025
 16:41:14 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCUjF67YCOIh96M1qsNjwSeEXxKhybJkgK6fii6j78fFfOm+ij6qCJg2F/wfYMzANOoKduaA8yvpnmm+@googlegroups.com
X-Received: by 2002:a05:6808:821a:b0:400:be08:f6e5 with SMTP id 5614622812f47-404d863ce00mr10504053b6e.7.1747784473888;
        Tue, 20 May 2025 16:41:13 -0700 (PDT)
Received: by 2002:a05:6808:82c7:b0:3f6:a384:eb6f with SMTP id 5614622812f47-404da00d5efmsb6e;
        Tue, 20 May 2025 16:13:00 -0700 (PDT)
X-Forwarded-Encrypted: i=2; AJvYcCUzKpx2v2BoEKDcyaedX2K/J8raXRRzpPg5XZ3pdNVo4Prw3aHG2kDvQstDEcjjF06ydbsmcREtqGY3@googlegroups.com
X-Received: by 2002:a05:6808:2f11:b0:3fe:aecb:5c49 with SMTP id 5614622812f47-404d8763b82mr13776860b6e.21.1747782780247;
        Tue, 20 May 2025 16:13:00 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1747782780; cv=none;
        d=google.com; s=arc-20240605;
        b=iQHjEDdlMrcOgNca6ZjbeYCDSz9mMf9WpPkYXyr/R3LkMvplBHI357oGggCG80A4Nz
         ewzXM3h+sr+DltyGRRSpEWu9CmscomKijqY4yYZBCNj01c3C0J8h1Ds0puPmPSE5VSOn
         63eZM+FU8PtTg+OdT+IzjCUdRXoJl79wSC9nr5eVGomAh7G0atyHR4GPvkTKqYR42E84
         D3gEuW4lZBMGEU+sCmjqZuWtm4u00yc9sM4kJ5AQeMMsm3QjKpYiCP0/F8hikNf0Gvqf
         KnDtCBL9U8Jv7k56+cZaC/2cRndtH/TxMVdRReooiupBIlZAKHQR36WbwePPAAZNoYuO
         ZZwQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=vTgkG3es/d1hiihhmPrVt3+9wu4BdijDYAsDQ8faTKs=;
        fh=QTf3ZOg2ldtu5Jni5/zxU/Jg+KCsDnTYOKHOzzulCC8=;
        b=OTqLaQ2mBPyyfE/DVkbvBu7nr4Fjs2JqmJ0H1v6GMIK4ZFkbKR1Sr2yFwFjDkTNaMo
         JJ9V3kEiTMQbGjiWzgGCE0yMlF1sMv97T+fhu5ha8d+IsWmXEYMekEXodQ+DaMel0iiX
         7GzAjKV+RkFuggdnw2f3n64Rkoh1U5QgpHHyiCrdaEP8ZxZCzvWZoMIaiUOr3pAWW+c/
         DihvNkTcjD6qcTJRENdb4xXS6YUh8yKHylNcuxNd/azz1l1hLwGn8/S8zU3MKQIN8511
         uiTan2bYYQHBXPn1mUWJad0+5xDzH8wMLhMZ4dnITdyWWYSLt0tKnOFp3LNOkAVhUU5c
         JQ1A==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=TFZpOr5d;
       spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::533 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com. [2607:f8b0:4864:20::533])
        by gmr-mx.google.com with ESMTPS id 5614622812f47-404d987f710si507843b6e.3.2025.05.20.16.13.00
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Tue, 20 May 2025 16:13:00 -0700 (PDT)
Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::533 as permitted sender) client-ip=2607:f8b0:4864:20::533;
Received: by mail-pg1-x533.google.com with SMTP id 41be03b00d2f7-b1396171fb1so3603379a12.2
        for <bitcoindev@googlegroups.com>; Tue, 20 May 2025 16:13:00 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCUwL1sbJJtx37rTokD22yO6hEy8h1VLQlhOqFFvAg/qYFd7qrxuC4QSHSXRG6PEv6KJ8LCvzjYEmJo3@googlegroups.com
X-Gm-Gg: ASbGncuTpOwIJC4GrM25eSuCPWGJL+ux/MQaXDoTIXrS8Cde+NgL1cYfidGScybpOVa
	EcA0WecKPzfoHVYBBHOTpjc3w304bjV2WCuAbWzoIdZ8A7Ep11kPK6ooRlpR9D4PpLLsDyYaQri
	TszP/oe40XliBjjgPYgbT9hxEMtfmKDh1s
X-Received: by 2002:a17:902:f68f:b0:232:4417:537e with SMTP id
 d9443c01a7336-2324426997cmr130613255ad.21.1747782779211; Tue, 20 May 2025
 16:12:59 -0700 (PDT)
MIME-Version: 1.0
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <IpyzvdqFhM_40OKYdilNrHU9u_cIx7BKlYKBUgTGPW6idPAItRiza5tq8B1jEs141ypieLGkR2UMRIxg0qdxBMl6DQ3UKaQsID0gBjWLXtY=@protonmail.com>
 <aBUlEOBqqrOIGHWC@petertodd.org> <7Q6uglccxrI_LPvP2bKeTwFcBAKJ5u8u6NHtDl-dNev_kplv2lfh46r-z2iflmtnnsa8YWgn1A2M8S0jLORI2GxwNQ7qmfyM2jqQiB6JTiw=@protonmail.com>
In-Reply-To: <7Q6uglccxrI_LPvP2bKeTwFcBAKJ5u8u6NHtDl-dNev_kplv2lfh46r-z2iflmtnnsa8YWgn1A2M8S0jLORI2GxwNQ7qmfyM2jqQiB6JTiw=@protonmail.com>
From: Greg Maxwell <gmaxwell@gmail.com>
Date: Tue, 20 May 2025 23:12:48 +0000
X-Gm-Features: AX0GCFv0sQr58HIYbsRx-FOduPNAV81pa7roz7gGg-B3AsbPQ6ksPO8uVloxLX0
Message-ID: <CAAS2fgRyu1HKHDk_aCyHXqe+sgYpcApjmXx3Ps4ChpBAxeBcpw@mail.gmail.com>
Subject: Re: [bitcoindev] Re: Removing OP_Return restrictions: Devil's
 Advocate Position
To: Antoine Poinsot <darosior@protonmail.com>
Cc: Peter Todd <pete@petertodd.org>, 
	Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000b316750635996336"
X-Original-Sender: gmaxwell@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=TFZpOr5d;       spf=pass
 (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::533
 as permitted sender) smtp.mailfrom=gmaxwell@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 (/)

--000000000000b316750635996336
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> Certainly it makes sense to go for instance up to 1 KB. But what is the
rationale for going from 1 KB to 99 KB?

Because major miners already allow the  1KB to 99KB, limiting in relay what
miners easily mine only causes harm: It doesn't prevent the usage except to
the extent that the user prefers to not submit directly (even though
web-centric developers generally *prefer* the APIs to the p2p network), it
keeps miners in the business of having to adjust the software for their own
needs, encourages private submission, etc.  Essentially a policy limit that
miners are already bypassing is merely performative.

And then if/when someone *would* want to embed between 1kb and 99kb in
outputs, they'll just go ahead and do it with fake outputs to the great
detriment of the system.

I would flip this argument the other way: With a small increase failing to
actually achieve consistency with mining policy?  Why do it at all?  For
the benefit of some single user's narrow use that doesn't even seem to
really care?  I don't find that compelling.

> It is easy to relax a standardness limit, but very hard to go back

It's already been relaxed.


On Tue, May 20, 2025 at 9:54=E2=80=AFPM 'Antoine Poinsot' via Bitcoin Devel=
opment
Mailing List <bitcoindev@googlegroups.com> wrote:

> > 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:
>
> Let me add a steel man for another argument against the change as propose=
d.
>
> # Lifting the limit *entirely* is unnecessary
>
> Bitcoin Core's standardness rules fail to deter unwanted Bitcoin usage in
> the 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
> start using competing direct
> submission services.
>
> That said they can be an effective barrier to bootstrapping such demand i=
n
> the first place. If we
> take the example of inscriptions, it is not hard to imagine that if the
> leaf 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 i=
s
> due to newfound evidence
> that people attempting to use the transaction relay network are working
> around the limitation by
> using fake public keys in forever-unspendable outputs, which impose a muc=
h
> greater cost to node
> runners than simple OP_RETURN outputs. This was illustrated by Citrea's
> BitVM 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
> need to consider forward
> compatibility in changing the limit, as tailoring it to the very specific
> instance of Citrea may not
> be a good fit for future usecases. We may not notice the publication of a
> future design until it is
> actively being used, at which point its developers might understandably b=
e
> reluctant to go back and
> make the change. Another possibility is that developers of a future
> application might just not be
> interested in engaging with our negative externality concerns after the
> fact, 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
> compatibility with yet-unknown
> usecases. However if we think on the margin it is not a convincing for
> going all the way to the
> maximum standard transaction size. Certainly it makes sense to go for
> instance 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
> sense, what we want for
> standardness rules is the opposite of what we want for consensus. Relaxin=
g
> 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
> limit.
>
> 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:
>
> >
> >
> > On Thu, May 01, 2025 at 10:40:19PM +0000, 'Antoine Poinsot' via Bitcoin
> Development Mailing List wrote:
> >
> > > 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
> have 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_policy_drama.
> >
> >
> > 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).
> >
> > 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:
> >
> >
> > # Uninterrupted Illicit Data
> >
> > 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.
> >
> > 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 dat=
a
> > in witnesses; Martin Habov=C5=A1tiak already brought this up on this ve=
ry
> > list).
> >
> > 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 file=
s
> > by default (chainstate is also XOR "encrypted").
> >
> > 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.
> >
> >
> > # Setting Policy Expectations For a Consensus Change
> >
> > 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 a=
s
> > follows:
> >
> > 1) Limit all data in the chain to be either hash digests, signatures,
> > pubkeys, or trivial values like true and false.
> >
> > 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.
> >
> > 3) Phase out non-compliant transactions, e.g. applying a block-weight
> > multiplier that increases over time to eventually make them entirely
> > unaffordable.
> >
> > 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.
> >
> > Also note that even this consensus change still won't entirely
> > prevent people from publishing data! No-matter what we do you can alway=
s
> > grind pubkeys and hashes to set the first 4-6 bytes of them to the valu=
e
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > --
> > https://petertodd.org 'peter'[:-1]@petertodd.org
>
> --
> 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/7Q6uglccxrI_LPvP2bKeTwFcBAKJ=
5u8u6NHtDl-dNev_kplv2lfh46r-z2iflmtnnsa8YWgn1A2M8S0jLORI2GxwNQ7qmfyM2jqQiB6=
JTiw%3D%40protonmail.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/=
CAAS2fgRyu1HKHDk_aCyHXqe%2BsgYpcApjmXx3Ps4ChpBAxeBcpw%40mail.gmail.com.

--000000000000b316750635996336
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; Certainly it makes sense to go for instance up to 1 K=
B. But what is the rationale for going from 1 KB to 99 KB?<div><br></div><d=
iv>Because major miners already allow the=C2=A0 1KB to 99KB, limiting in re=
lay what miners easily mine only causes harm: It doesn&#39;t prevent the us=
age except to the extent that the user prefers to not submit directly (even=
 though web-centric developers generally *prefer* the APIs to the p2p netwo=
rk), it keeps miners in the business of having to adjust the software for t=
heir own needs, encourages private submission, etc.=C2=A0 Essentially a pol=
icy limit that miners are already bypassing is merely performative.</div><d=
iv><br></div><div>And then if/when someone *would* want to embed between 1k=
b and 99kb in outputs, they&#39;ll just go ahead and do it with fake output=
s to the great detriment of the system. <br></div><div><br></div><div>I wou=
ld flip this argument the other way: With a small increase failing to actua=
lly achieve consistency with mining policy?=C2=A0 Why do it at all?=C2=A0 F=
or the benefit of some single user&#39;s narrow use that doesn&#39;t even s=
eem to really care?=C2=A0 I don&#39;t find that compelling.</div><div><br><=
/div><div>&gt; It is easy to relax a standardness limit, but very hard to g=
o back</div><div><br></div><div>It&#39;s already been relaxed.</div><div><b=
r></div></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr" class=3D"gmail_attr">On Tue, May 20, 2025 at 9:54=E2=80=AFPM &#39;=
Antoine Poinsot&#39; via Bitcoin Development Mailing List &lt;<a href=3D"ma=
ilto:bitcoindev@googlegroups.com">bitcoindev@googlegroups.com</a>&gt; 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-left:1ex">&gt; With that=
 in mind, I thought it&#39;d be worthwhile to Devil&#39;s Advocate the chan=
ge, and go through<br>
&gt; some technically valid arguments against it:<br>
<br>
Let me add a steel man for another argument against the change as proposed.=
<br>
<br>
# Lifting the limit *entirely* is unnecessary<br>
<br>
Bitcoin Core&#39;s standardness rules fail to deter unwanted Bitcoin usage =
in the presence of sustained<br>
economic demand. They may only cause a minor and temporary inconvenience to=
 users of such<br>
transactions until they set up a separate transaction relay network or star=
t using competing direct<br>
submission services.<br>
<br>
That said they can be an effective barrier to bootstrapping such demand in =
the first place. If we<br>
take the example of inscriptions, it is not hard to imagine that if the lea=
f script size had been<br>
limited by standardness from the get go (which may be undesirable for other=
 reasons) inscriptions<br>
would have never really taken off.<br>
<br>
The renewed discussion around relaxing the OP_RETURN standardness limit is =
due to newfound evidence<br>
that people attempting to use the transaction relay network are working aro=
und the limitation by<br>
using fake public keys in forever-unspendable outputs, which impose a much =
greater cost to node<br>
runners than simple OP_RETURN outputs. This was illustrated by Citrea&#39;s=
 BitVM bridge design which<br>
requires storing some data specifically in the output(s) of a transaction.<=
br>
<br>
Such design only needs to store a small amount of data there. However we ne=
ed to consider forward<br>
compatibility in changing the limit, as tailoring it to the very specific i=
nstance of Citrea may not<br>
be a good fit for future usecases. We may not notice the publication of a f=
uture design until it is<br>
actively being used, at which point its developers might understandably be =
reluctant to go back and<br>
make the change. Another possibility is that developers of a future applica=
tion might just not be<br>
interested in engaging with our negative externality concerns after the fac=
t, but would have just<br>
used OP_RETURN outputs in the first place if there were an available option=
.<br>
<br>
This is a valid argument for leaving some wiggle room for forward compatibi=
lity with yet-unknown<br>
usecases. However if we think on the margin it is not a convincing for goin=
g all the way to the<br>
maximum standard transaction size. Certainly it makes sense to go for insta=
nce up to 1 KB. But what<br>
is the rationale for going from 1 KB to 99 KB?<br>
<br>
It is easy to relax a standardness limit, but very hard to go back. In a se=
nse, what we want for<br>
standardness rules is the opposite of what we want for consensus. Relaxing =
the limit on the size of<br>
OP_RETURN outputs may enable unforeseen usages that we would not be able to=
 prevent anymore once it<br>
is done. For this reason, we need to be conservative in picking the new lim=
it.<br>
<br>
Lifting the limit is desirable. Lifting the limit *entirely* is unnecessary=
. Instead of the implicit<br>
~100 KB limit, a more conservative limit of 1 KB should be preferred.<br>
<br>
<br>
<br>
On Friday, May 2nd, 2025 at 4:03 PM, Peter Todd &lt;<a href=3D"mailto:pete@=
petertodd.org" target=3D"_blank">pete@petertodd.org</a>&gt; wrote:<br>
<br>
&gt; <br>
&gt; <br>
&gt; On Thu, May 01, 2025 at 10:40:19PM +0000, &#39;Antoine Poinsot&#39; vi=
a Bitcoin Development Mailing List wrote:<br>
&gt; <br>
&gt; &gt; 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 have also written my point of view and reasons for proposing this chang=
e in a blog post which goes into more details: <a href=3D"https://antoinep.=
com/posts/relay_policy_drama" rel=3D"noreferrer" target=3D"_blank">https://=
antoinep.com/posts/relay_policy_drama</a>.<br>
&gt; <br>
&gt; <br>
&gt; I agree with the linked write-up: the quality of debate has been<br>
&gt; atrocious. We&#39;ve had a bunch of people who should know better, mak=
ing<br>
&gt; points that don&#39;t make technical sense, and a bunch of passerby&#3=
9;s<br>
&gt; repeating that nonsense (as well as even more nonsensical arguments).<=
br>
&gt; <br>
&gt; With that in mind, I thought it&#39;d be worthwhile to Devil&#39;s Adv=
ocate the<br>
&gt; change, and go through some technically valid arguments against it:<br=
>
&gt; <br>
&gt; <br>
&gt; # Uninterrupted Illicit Data<br>
&gt; <br>
&gt; Credit where credit is due, this was the only reasonable argument<br>
&gt; against that was actually brought up on GitHub. In short, OP_Return,<b=
r>
&gt; unlike other standard ways of embedding data in Bitcoin transactions,<=
br>
&gt; allows for long uninterrupted, arbitrary, messages to be embedded<br>
&gt; verbatim.<br>
&gt; <br>
&gt; The claimed risk is that this data could then end up peoples&#39; hard=
<br>
&gt; drives, complicating forensics analysis in the future and potentially<=
br>
&gt; falsely incriminating people. (if you can encode your illicit data suc=
h<br>
&gt; that the right bytes happen to match Bitcoin opcodes, you can already<=
br>
&gt; embed it verbatim, uninterrupted, as seen by how inscriptions embed da=
ta<br>
&gt; in witnesses; Martin Habov=C5=A1tiak already brought this up on this v=
ery<br>
&gt; list).<br>
&gt; <br>
&gt; We already have this issue with dumb virus detection software. Which i=
s<br>
&gt; why a few years ago code was added to XOR &quot;encrypt&quot; the bloc=
k*.dat files<br>
&gt; by default (chainstate is also XOR &quot;encrypted&quot;).<br>
&gt; <br>
&gt; The only remaining argument here is if we should go to the trouble of<=
br>
&gt; adding code to Bitcoin Core to convert existing block*.dat files to th=
e<br>
&gt; XOR scheme, without re-downloading.<br>
&gt; <br>
&gt; <br>
&gt; # Setting Policy Expectations For a Consensus Change<br>
&gt; <br>
&gt; While it is clearly infeasible to prevent people from publishing data<=
br>
&gt; with Bitcoin&#39;s existing consensus rules, it is hypothetically poss=
ible<br>
&gt; to make data publication somewhat more expensive with consensus change=
s.<br>
&gt; Gregory Maxwell outlined how to do so on this mailing list years ago<b=
r>
&gt; (I&#39;m not going to dig up the reference). Basically his approach wo=
rks as<br>
&gt; follows:<br>
&gt; <br>
&gt; 1) Limit all data in the chain to be either hash digests, signatures,<=
br>
&gt; pubkeys, or trivial values like true and false.<br>
&gt; <br>
&gt; 2) Require transactions to prove that every item of data is what it<br=
>
&gt; claims to be with, e.g. a hash digest pre-image, a valid signature (fo=
r<br>
&gt; a pubkey), or the fact that a signature was valid. I may be wrong. But=
 I<br>
&gt; believe that with protocol changes it is possible for Lightning and<br=
>
&gt; Ark to work in this model.<br>
&gt; <br>
&gt; 3) Phase out non-compliant transactions, e.g. applying a block-weight<=
br>
&gt; multiplier that increases over time to eventually make them entirely<b=
r>
&gt; unaffordable.<br>
&gt; <br>
&gt; Note that such a scheme will require massive ecosystem wide change:<br=
>
&gt; even existing address standards will need to be modified (and made<br>
&gt; larger) to prove that you are paying to a real address rather than<br>
&gt; something encoding data.<br>
&gt; <br>
&gt; Also note that even this consensus change still won&#39;t entirely<br>
&gt; prevent people from publishing data! No-matter what we do you can alwa=
ys<br>
&gt; grind pubkeys and hashes to set the first 4-6 bytes of them to the val=
ue<br>
&gt; that you want. Thus if you&#39;re pushing 32 bytes of data, encoded as=
 33<br>
&gt; bytes including the serialized length, and get 5 bytes per push, you<b=
r>
&gt; have an overhead of about 6.6x. Existing data encoders have been happy=
<br>
&gt; to pay even more money than that in terms of increased fees during fee=
<br>
&gt; spikes; the difference in cost between witness space and txout space i=
s<br>
&gt; already 4x, and some are happy to publish data that way anyway.<br>
&gt; <br>
&gt; A tricky thing here is upgrade paths. If we make these rules apply to<=
br>
&gt; all transactions, with any version number, we&#39;ve radically limited=
 our<br>
&gt; ability to upgrade the Bitcoin protocol in the future. We probably can=
<br>
&gt; make this not apply to transactions and taproot script types with<br>
&gt; unknown version numbers. However we&#39;d have to do something like en=
sure<br>
&gt; it only applies to insecure transactions without signatures. And even<=
br>
&gt; then some miners will bypass this by mining that stuff anyway for a fe=
e.<br>
&gt; That&#39;s pretty ugly. Maybe we can make a mechanism where miners sig=
nal<br>
&gt; support to allow new version numbers first, prior to an upgrade. But<b=
r>
&gt; that also adds plenty of complexity.<br>
&gt; <br>
&gt; That said, if the Luke&#39;s of the world want to make a reasonable<br=
>
&gt; technical argument, come up with a reasonable scheme like the above an=
d<br>
&gt; show that it has a chance of actually getting implemented.<br>
&gt; <br>
&gt; --<br>
&gt; <a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank"=
>https://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd=
.org" rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
<br>
-- <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%2Bunsubscribe@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/7Q6uglccxrI_LPvP2bKeTwFcBAKJ5u8u6NHtDl-dNev_kplv2lfh46r-z2iflmtn=
nsa8YWgn1A2M8S0jLORI2GxwNQ7qmfyM2jqQiB6JTiw%3D%40protonmail.com" rel=3D"nor=
eferrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/7Q6=
uglccxrI_LPvP2bKeTwFcBAKJ5u8u6NHtDl-dNev_kplv2lfh46r-z2iflmtnnsa8YWgn1A2M8S=
0jLORI2GxwNQ7qmfyM2jqQiB6JTiw%3D%40protonmail.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/CAAS2fgRyu1HKHDk_aCyHXqe%2BsgYpcApjmXx3Ps4ChpBAxeBcpw%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAAS2fgRyu1HKHDk_aCyHXqe%2BsgYpcApjmXx3Ps4ChpBAxeBcpw%40ma=
il.gmail.com</a>.<br />

--000000000000b316750635996336--