path: root/14/56f949772cca938d635af88eca4ba931b87e2b

Delivery-date: Fri, 02 May 2025 04:06:27 -0700
Received: from mail-yb1-f187.google.com ([209.85.219.187])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBD6NLIEP7MCRBJ6O2LAAMGQEMTBCXCY@googlegroups.com>)
	id 1uAoDp-0001O9-97
	for bitcoindev@gnusha.org; Fri, 02 May 2025 04:06:27 -0700
Received: by mail-yb1-f187.google.com with SMTP id 3f1490d57ef6-e72a02f0e5esf2237325276.3
        for <bitcoindev@gnusha.org>; Fri, 02 May 2025 04:06:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1746183979; x=1746788779; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=AhHzCvb9OvNYElJ6FldxX3xo26OSjCL2PmGxDpwysZE=;
        b=xUcdi3axk6ZFVnGpY8fBJENlbSD7cANmKmcKEl5j2VNmbVcRa8hNg/iMOuvBXeJ43F
         5VlEmzyn1E2OSkT2nL4YnwPAA643QH++SXgfRGjxIKqFqKw2virag2fMiQKVxqRphhcn
         sk4NWS6ioCCBUevfP8fG2eybk7eOxmKs2INTgwubgow7RPn5wEsuCL0/KmnOzAGyzYBV
         SUkdud+zgBaspDb5RYW2p71aje1AI5Pge9dkfNKHLAQIB3wuXJYGBwChg6WrOXUIVCYj
         xCeT/hlM+GdW/KCUbkOoeB8mUzsoGnF6P1p0LlYlUhiLEDeSy+aXVOJ3xbtgTTdbVAEI
         sDgw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746183979; x=1746788779; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=AhHzCvb9OvNYElJ6FldxX3xo26OSjCL2PmGxDpwysZE=;
        b=FGpW7Wi/tHGHvkSj619U/RQ8zUrN0XkDZEHDhQW+i9qVU7ugyNatQ5qrjPzkqln977
         oyCDpm24QeJHUSTANqfjLkvUHz6rFjoJJmYXiTgmKUqybuvVbZj12i5L0i8BQSzXzVrC
         AStKlXBCACxFkFuDL5WwjgoWZ4IOnFCtbWr/FEmsL26rnKzJ9R8Vg1ppy9fz5g8sx8jo
         0sGBSjV+1Bf05bcD5uPCTHG9MNn98OvNx4tY23ffo+Ep5t+BOQa3RBErg+eGE9jUWHpK
         uNwYbDB19zdRDW2/E96YNCuIYhgWxGKtxfNZlgc1ykDc+xtUwvCSCpFjNsR+2D65bx8+
         WMTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746183979; x=1746788779;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=AhHzCvb9OvNYElJ6FldxX3xo26OSjCL2PmGxDpwysZE=;
        b=TFbYeolDv/hO/9ReL7GgdkeTE9MWtQlYSf6Q+O56OAkpOr3QF4WJ7RZ2H3V5tmweSB
         KIgnR3toebrG0f+bK0UClxgEAyAOjqfiXLq+zB1OghOs8E330XK5HGhdbB/Uotl/3cAj
         7M69FLolJWQL7DSs5b9BYbprbja5z/Mq5HYIMARD7PV4ZReWju6SjnK9Yi7RXfJSVarf
         KaFLK1dUekT7R1ETelnXNw95vUovxyaOw1l7nT9keT4kr/iOsObpS1pGfsYEEsREQ5ZB
         ljhKHKO80MrHgY4OJbElgR2p0zHmi2VZ8G+tQGK5GAfIEVIdG9hlAyX7HbmoHcZ8gadl
         XeKQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXfKmAGrh2hA93Ii6aie0ie1tksSmvkKgO86pp6ZgKpcLHckVH4HU+V10D2lkqu/yRr0E7N/3/uyx3e@gnusha.org
X-Gm-Message-State: AOJu0Yxgfbz9Y/zmCPjd8n9HFGohdXo1LoKNftHrv1T/ReZySvdZWo6z
	rmqwx9Y8PfPAJ4B0UU2l3UWKN0sdNsQXJe47vAzrwV+cbIQ961aI
X-Google-Smtp-Source: AGHT+IF35cvHhzEnmAQnalYqv2QkMOYw7mRKJv7bjOa5ZWehLbhp/rtzpkvbdhRgFBBw5Vz4gHv0Ng==
X-Received: by 2002:a05:6902:1b8a:b0:e72:9703:a4d0 with SMTP id 3f1490d57ef6-e7565659c38mr2901005276.44.1746183978843;
        Fri, 02 May 2025 04:06:18 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBHSk5ox/qBPHQm99OVQopSPSWA1WMOnNFnwnPhXiuldAw==
Received: by 2002:a25:aae8:0:b0:e74:4c3b:7a5a with SMTP id 3f1490d57ef6-e74d9988cc9ls283031276.0.-pod-prod-08-us;
 Fri, 02 May 2025 04:06:15 -0700 (PDT)
X-Received: by 2002:a05:690c:64c4:b0:708:4f42:c2f6 with SMTP id 00721157ae682-708ced50a6cmr40506127b3.16.1746183974924;
        Fri, 02 May 2025 04:06:14 -0700 (PDT)
Received: by 2002:a81:f801:0:b0:6ef:590d:3213 with SMTP id 00721157ae682-708cfb0b4cems7b3;
        Thu, 1 May 2025 17:14:45 -0700 (PDT)
X-Received: by 2002:a05:690c:6985:b0:708:bc6e:f48c with SMTP id 00721157ae682-708cebcef1cmr18912737b3.0.1746144884093;
        Thu, 01 May 2025 17:14:44 -0700 (PDT)
Date: Thu, 1 May 2025 17:14:43 -0700 (PDT)
From: PandaCute <pandacute12345678@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <68cdce0e-9030-4a6b-92a4-d48d05be3e80n@googlegroups.com>
In-Reply-To: <IpyzvdqFhM_40OKYdilNrHU9u_cIx7BKlYKBUgTGPW6idPAItRiza5tq8B1jEs141ypieLGkR2UMRIxg0qdxBMl6DQ3UKaQsID0gBjWLXtY=@protonmail.com>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <IpyzvdqFhM_40OKYdilNrHU9u_cIx7BKlYKBUgTGPW6idPAItRiza5tq8B1jEs141ypieLGkR2UMRIxg0qdxBMl6DQ3UKaQsID0gBjWLXtY=@protonmail.com>
Subject: [bitcoindev] Re: Relax OP_RETURN standardness restrictions
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_55536_968519904.1746144883759"
X-Original-Sender: pandacute12345678@gmail.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 (/)

------=_Part_55536_968519904.1746144883759
Content-Type: multipart/alternative; 
	boundary="----=_Part_55537_1523779707.1746144883759"

------=_Part_55537_1523779707.1746144883759
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think this debate is missing one important part: a communication link=20
between the developers and the users. The developers are speaking with the=
=20
developers, the users are speaking with the users, and no one is really=20
trying to understand where the other side is coming from. It's been a lot=
=20
of aggressive, unproductive back-and-forth, with both sides accusing each=
=20
other of bad intentions and completely dismissing each other's points.

This is a technical mailing list aimed at devs, so I'll try to summarize=20
what I've seen in normal_users_land, and the general feeling out there=20
right now. Obviously, I'm not trying to suggest that users *feelings*=20
should be dictate the technical direction of Bitcoin. However, it is=20
important that there is mutual respect and trust between users and devs.

Right now, trust is pretty broken. It can be regained, but not without=20
understanding what went wrong in the first place.=20

I saw on IRC some devs suggesting they spend time on podcasts and social=20
media to explain the motivations behind this proposal *before* merging it,=
=20
instead of merging now and hoping people just accept it. I think that=E2=80=
=99s a=20
fantastic idea, and the way to go. I particularly liked jonatack's message=
=20
- =E2=80=9Cif Core shows humility and patience, it would surprise people an=
d=20
improve things.=E2=80=9D

Now, about the proposal itself and what it *feels* like: It=E2=80=99s a big=
 change=20
that came out of nowhere, especially at a time when spam doesn=E2=80=99t se=
em like=20
a big issue. It=E2=80=99s a bit=E2=80=A6 shocking? Normally Bitcoin changes=
 are discussed=20
for ages, PRs take so long to get merged, because of all the care that devs=
=20
put into considering the pros and the cons, but here? We get a mailing list=
=20
post (that no user is reading, let=E2=80=99s be honest) and a PR with a lot=
 of=20
contributors saying =E2=80=9Cyeah, let=E2=80=99s do this!=E2=80=9D. There s=
hould be a bit more=20
research. (Maybe there was, but behind closed doors?). We want to know=20
about all the protocols that are bloating the UTXO set and that could be=20
using OP_RETURN instead. We want to know how many transactions like these=
=20
are in each block, and how many there will be once the new protocols start=
=20
getting deployed. We want to see that you did your homework for weeks=20
before trying to change the policies.=20

It feels weird=E2=80=94like some sort of attack or a bribe. One protocol is=
=20
mentioned that would benefit from this change, and then an investor ACKs=20
the PR. Someone points out a potential conflict of interest, and their=20
comment gets hidden. That=E2=80=99s shady, no denying it.

And then, it feels that users have no say. It's a ""technocracy"", where=20
devs have all the power in their hands and can decide where the protocol=20
goes, while completely dismissing users' concerns.

Users do have concerns=E2=80=94lots of them. And I encourage devs to step o=
ut and=20
talk to "regular" Bitcoin users. It=E2=80=99s not just a =E2=80=9Cloud mino=
rity=E2=80=9D=E2=80=94there are=20
many people genuinely worried: =E2=80=9CCan we trust Core devs anymore? Is =
there=20
even another option?=E2=80=9D. But their concerns are dismissed, their comm=
ents=20
deleted or hidden, they're treated like "bullies" that devs should ignore,=
=20
devs should "merge Todd's PR and call it a day".

Without understanding all the technical details, I'd say there's a pretty=
=20
good chance that the very smart people that work on Core are right once=20
again. Statistically, it's very likely. Communicate to users, explain your=
=20
motivations, and show that you want to listen to our concerns.

Lastly, as irritating as that might be, users freaking out and holding core=
=20
developers accountable and flooding Github is a feature, not a bug. Devs=20
aren't the Bitcoin gods, they are humans, and humans can be bribed,  can be=
=20
coerced, can have conflict of interest, can fck up.

Users care and want to protect Bitcoin. Be grateful.=20

Respectfully,
A Bitcoin Dev

On Friday, May 2, 2025 at 12:46:20=E2=80=AFAM UTC+2 Antoine Poinsot wrote:

> As i have repeatedly asked people to take conceptual discussions to the=
=20
> mailing list, i am circling back to this thread to answer objections. I=
=20
> have also written my point of view and reasons for proposing this change =
in=20
> a blog post which goes into more details:=20
> https://antoinep.com/posts/relay_policy_drama.=20
>
> Going through the emails in order.
>
> Am I the only one left on this list who actually cares about Bitcoin's=20
> survival?
>
>
> Thanks Luke for your measured take. It's refreshing to see we have adults=
=20
> on both sides of this "debate".
>
> With that history in mind, removing limits on OP_RETURN standardness size=
=20
> is pointless.
>
>
> Yes, it is pointless for people who want to store massive amount of data.=
=20
> It is not for people who want to store a small amount of data in a=20
> time-sensitive transaction's output. Because they need their transaction =
to=20
> be relayed on the p2p network, and are therefore pushed to use unspendabl=
e=20
> outputs instead.
>
> Relaxing OP_RETURN size limits without dealing with the inscriptions
>
>
> This is orthogonal. The harmful behaviour described in OP is possible=20
> today regardless of inscriptions.
>
> There's little to no incentive to use OP_RETURN for data storage when=20
> using the 'inscriptions' exploit costs 4x less in transactions. What's th=
e=20
> point of having a "standard" way to store arbitrary data if the exploit=
=20
> method is 4x cheaper? And the nonstandard version of the exploit allows 4=
x=20
> the data?
>
>
> You have obviously not properly read or understood OP. There is no need=
=20
> to speculate about what would happen or not. People are using outputs to=
=20
> store data *today*=E2=80=8B. The only question now is harm reduction: giv=
en that=20
> people are storing this data in outputs today, do we want to offer a way =
to=20
> do it that does not force every single full node on the network to store=
=20
> their data forever?=20
>
> That said i agree that this is not going to change anything for people wh=
o=20
> try to store large amount of data onchain, they already have a 4x cheaper=
=20
> way of doing so.
>
> For example, let's say I want to distribute malware. Well, might as well=
=20
> just store it in an OP_RETURN.
>
>
> The point about storing data on everyone's disk was addressed by others:=
=20
> it's already possible and that's why Core XOR's the content of=20
> third-party-controlled data it writes to disk. But an interesting fact on=
=20
> this specific point about malware and OP_RETURN outputs is how they have=
=20
> already been used in the past to resiliently update the domain of a=20
> malware's C2 servers:=20
> https://news.sophos.com/wp-content/uploads/2020/06/glupteba_final-1.pdf .
>
> This is a fundamental change to the nature of what the Bitcoin network=20
> itself is in its entirety. [...] Bitcoin as we know it changes forever in=
=20
> the most fundamental way imaginable
>
>
> Wild emotional claims with no ground whatsoever don't convince anybody an=
d=20
> only hurt your credibility.
>
> and we might as well give up on Bitcoin ever being a thing if this is the=
=20
> path chosen
>
>
> Well if you believe the whole system is as brittle as relying on people=
=20
> playing nice for security, you might as well give up now.
>
> Have the courage to reject this type of thing for the sake of the overall=
=20
> project.
>
>
> Right. We do that, and you go outside and touch some grass for the benefi=
t=20
> of all subscribers to this mailing list.
>
> If you don't have confidence in the Bitcoin Core developers, instead of=
=20
> insulting them, you could also just (help) maintain a fork of the project=
.=20
> I obviously think you're misguided here, but at least it's better to=20
> channel this distrust into something constructive. Given the number of=20
> people who share your sentiment, *such a project should be perfectly=20
> viable*.=20
>
>
> Doubt.
>
> It was suggested in two different PRs ([0] and [1]) that the conceptual=
=20
> discussion take place in this thread, so I am submitting my comments here=
.
>
>
> Thank you for taking conceptual discussion to the mailing list. AJ alread=
y=20
> addressed your claims, so i won't repeat it here.
>
> This is just a temporary cease-fire while the spammers reload their=20
> ammunition. There is obviously about to be another wave
>
>
> Between this one and your previous email, you certainly do know a lot=20
> about the future! How's your trading going?
>
> otherwise what is the point of eliminating OP_RETURN restrictions?
>
>
> To not force people to bloat the UTxO set to store a trivial amount of=20
> data in the output of a time-sensitive transactions. On the specifics,=20
> Citrea stores a zk-proof verifying Bitcoin's longest chain composed of a=
=20
> 128-byte Groth16 proof and 16-byte total accumulated work (sauce:=20
> https://x.com/ekrembal_/status/1918008476552356202). I don't know and=20
> don't care why they do it in this way in particular, i just wish they did=
=20
> so in pruneable OP_RETURN outputs instead of unspendable Taproot outputs =
as=20
> they do today. Or worse, start thinking about bare multisig.
>
> Yes, and then the money printer makes sure that there is always enough=20
> easy money sloshing around in the economy so that more pop up where the o=
ld=20
> ones dropped out. This can and will continue indefinitely if we do nothin=
g.
>
>
> Money printer financing working people forever certainly isn't something =
i=20
> expected to read on the Bitcoin dev mailing list!
>
> My proposal is not to counter literally every type of spam. Just the ones=
=20
> that have protocols relying on consistent transaction formats. Creating=
=20
> specific filters against just these worst offenders should
>
>
> This is veering off-topic for this thread. If you want to argue that Core=
=20
> should filter inscriptions could you take it to the appropriate thread?=
=20
> This thread is just about damage control for people storing data in=20
> transaction outputs.
>
> I believe you greatly overestimate the skill and competence of the people=
=20
> who would do this type of thing. You could accomplish what you've laid ou=
t.=20
> I could accomplish it.
>
>
> Your hubris gives me second-hand embarrassment. I hope the C2 domain=20
> update i shared above gives you a clue that there does in fact exist othe=
r=20
> smart people in the world. Threat actors would laugh pretty hard at your=
=20
> arrogant emails and emotional breakdowns, but they probably don't care=20
> about your filters in the slightest anyways.
>
> After reading the whole thread i have yet to read a single sound objectio=
n=20
> to lifting the OP_RETURN restrictions.
> On Thursday, April 17th, 2025 at 2:52 PM, Antoine Poinsot <
> daro...@protonmail.com> wrote:
>
> Hi,
>
> Standardness rules exist for 3 mains reasons: mitigate DoS vectors,=20
> provide upgrade hooks, or as a nudge to deter some usages.
>
> Bitcoin Core will by default only relay and mine transactions with at mos=
t=20
> a single OP_RETURN output, with a scriptPubKey no larger than 83 bytes. T=
his=20
> standardness rule falls into the third category: it aims to mildly deter=
=20
> data storage while still allowing a less harmful alternative than using=
=20
> non-provably-unspendable outputs.
>
> Developers are now designing constructions that work around these=20
> limitations. An example is Clementine, the recently-announced Citrea=20
> bridge, which uses unspendable Taproot outputs to store data in its=20
> "WatchtowerChallenge" transaction due to the standardness restrictions on=
=20
> the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years=
=20
> that the nudge is ineffective to deter storing data onchain.
>
> Since the restrictions on the usage of OP_RETURN outputs encourage harmfu=
l=20
> practices while being ineffective in deterring unwanted usage, i propose =
to=20
> drop them. I suggest to start by lifting the restriction on the size of t=
he=20
> scriptPubKey for OP_RETURN outputs, as a first minimal step to stop=20
> encouraging harmful behaviour, and to then proceed to lift the restrictio=
n=20
> on the number of OP_RETURN outputs per transactions.
>
> Antoine Poinsot
>
> [^0]: See section 6.1 of their whitepaper here=20
> 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/=
68cdce0e-9030-4a6b-92a4-d48d05be3e80n%40googlegroups.com.

------=_Part_55537_1523779707.1746144883759
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think this debate is missing one important part: a communication link bet=
ween the developers and the users. The developers are speaking with the dev=
elopers, the users are speaking with the users, and no one is really trying=
 to understand where the other side is coming from. It's been a lot of aggr=
essive, unproductive back-and-forth, with both sides accusing each other of=
 bad intentions and completely dismissing each other's points.<br /><br />T=
his is a technical mailing list aimed at devs, so I'll try to summarize wha=
t I've seen in normal_users_land, and the general feeling out there right n=
ow. Obviously, I'm not trying to suggest that users *feelings* should be di=
ctate the technical direction of Bitcoin. However, it is important that the=
re is mutual respect and trust between users and devs.<br /><br />Right now=
, trust is pretty broken. It can be regained, but not without understanding=
 what went wrong in the first place. <br /><br />I saw on IRC some devs sug=
gesting they spend time on podcasts and social media to explain the motivat=
ions behind this proposal *before* merging it, instead of merging now and h=
oping people just accept it. I think that=E2=80=99s a fantastic idea, and t=
he way to go. I particularly liked jonatack's message - =E2=80=9Cif Core sh=
ows humility and patience, it would surprise people and improve things.=E2=
=80=9D<br /><br />Now, about the proposal itself and what it *feels* like: =
It=E2=80=99s a big change that came out of nowhere, especially at a time wh=
en spam doesn=E2=80=99t seem like a big issue. It=E2=80=99s a bit=E2=80=A6 =
shocking? Normally Bitcoin changes are discussed for ages, PRs take so long=
 to get merged, because of all the care that devs put into considering the =
pros and the cons, but here? We get a mailing list post (that no user is re=
ading, let=E2=80=99s be honest) and a PR with a lot of contributors saying =
=E2=80=9Cyeah, let=E2=80=99s do this!=E2=80=9D. There should be a bit more =
research. (Maybe there was, but behind closed doors?). We want to know abou=
t all the protocols that are bloating the UTXO set and that could be using =
OP_RETURN instead. We want to know how many transactions like these are in =
each block, and how many there will be once the new protocols start getting=
 deployed. We want to see that you did your homework for weeks before tryin=
g to change the policies. <br /><br />It feels weird=E2=80=94like some sort=
 of attack or a bribe. One protocol is mentioned that would benefit from th=
is change, and then an investor ACKs the PR. Someone points out a potential=
 conflict of interest, and their comment gets hidden. That=E2=80=99s shady,=
 no denying it.<br /><br />And then, it feels that users have no say. It's =
a ""technocracy"", where devs have all the power in their hands and can dec=
ide where the protocol goes, while completely dismissing users' concerns.<b=
r /><br />Users do have concerns=E2=80=94lots of them. And I encourage devs=
 to step out and talk to "regular" Bitcoin users. It=E2=80=99s not just a =
=E2=80=9Cloud minority=E2=80=9D=E2=80=94there are many people genuinely wor=
ried: =E2=80=9CCan we trust Core devs anymore? Is there even another option=
?=E2=80=9D. But their concerns are dismissed, their comments deleted or hid=
den, they're treated like "bullies" that devs should ignore, devs should "m=
erge Todd's PR and call it a day".<br /><br />Without understanding all the=
 technical details, I'd say there's a pretty good chance that the very smar=
t people that work on Core are right once again. Statistically, it's very l=
ikely. Communicate to users, explain your motivations, and show that you wa=
nt to listen to our concerns.<br /><br />Lastly, as irritating as that migh=
t be, users freaking out and holding core developers accountable and floodi=
ng Github is a feature, not a bug. Devs aren't the Bitcoin gods, they are h=
umans, and humans can be bribed, =C2=A0can be coerced, can have conflict of=
 interest, can fck up.<br /><br />Users care and want to protect Bitcoin. B=
e grateful. <br /><br />Respectfully,<br />A Bitcoin Dev<br /><br /><div cl=
ass=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Friday, May 2=
, 2025 at 12:46:20=E2=80=AFAM UTC+2 Antoine Poinsot wrote:<br/></div><block=
quote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: 1px =
solid rgb(204, 204, 204); padding-left: 1ex;"><div>As i have repeatedly ask=
ed 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 m=
ore details:=C2=A0<span><a rel=3D"noreferrer nofollow noopener" href=3D"htt=
ps://antoinep.com/posts/relay_policy_drama" target=3D"_blank" data-saferedi=
recturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://antoinep.com/=
posts/relay_policy_drama&amp;source=3Dgmail&amp;ust=3D1746231111393000&amp;=
usg=3DAOvVaw3yh8GKJBlcJou50zDIYd4R">https://antoinep.com/posts/relay_policy=
_drama</a></span>. <br></div><div><br></div><div>Going through the emails i=
n order.</div><div><br></div><blockquote style=3D"border-left:3px solid rgb=
(200,200,200);border-color:rgb(200,200,200);padding-left:10px;color:rgb(102=
,102,102)"><div style=3D"font-family:Arial,sans-serif;font-size:14px">Am I =
the
      only one left on this list who actually cares about Bitcoin&#39;s
      survival?</div></blockquote><div><br></div><div><span style=3D"font-f=
amily:Arial,sans-serif;font-size:14px;font-weight:400;color:rgb(0,0,0);back=
ground-color:rgb(255,255,255)">Thanks Luke for your measured take. It&#39;s=
 refreshing to see we have adults on both sides of this &quot;debate&quot;.=
</span><br></div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
    <div>

            </div>

            <div>

            </div>
</div>
<div style=3D"font-family:Arial,sans-serif;font-size:14px"><br></div><block=
quote style=3D"border-left:3px solid rgb(200,200,200);border-color:rgb(200,=
200,200);padding-left:10px;color:rgb(102,102,102)"><div style=3D"font-famil=
y:Arial,sans-serif;font-size:14px">With that history in mind, removing limi=
ts on OP_RETURN standardness size is pointless.</div></blockquote><div><br>=
</div><div>Yes, it is pointless for people who want to store massive amount=
 of data. It is not for people who want to store a small amount of data in =
a time-sensitive transaction&#39;s output. Because they need their transact=
ion to be relayed on the p2p network, and are therefore pushed to use unspe=
ndable outputs instead.</div><div><br></div><blockquote style=3D"border-lef=
t:3px solid rgb(200,200,200);border-color:rgb(200,200,200);padding-left:10p=
x;color:rgb(102,102,102)"><div>Relaxing OP_RETURN size limits without deali=
ng with the inscriptions</div></blockquote><div><br></div><div>This is orth=
ogonal. The harmful behaviour described in OP is possible today regardless =
of inscriptions.</div><div><br></div><blockquote style=3D"border-left:3px s=
olid rgb(200,200,200);border-color:rgb(200,200,200);padding-left:10px;color=
:rgb(102,102,102)"><div>There&#39;s little to no incentive to use OP_RETURN=
 for data storage when using the &#39;inscriptions&#39; exploit costs 4x le=
ss in transactions. What&#39;s the point of having a &quot;standard&quot; w=
ay to store arbitrary data if the exploit method is 4x cheaper? And the non=
standard version of the exploit allows 4x the data?</div></blockquote><div>=
<br></div><div><span style=3D"font-family:Arial,sans-serif;font-size:14px;f=
ont-weight:400;color:rgb(0,0,0);background-color:rgb(255,255,255)">You have=
 obviously not properly read or understood OP.=C2=A0<span style=3D"backgrou=
nd-color:rgb(255,255,255)">There is no need to speculate about what would h=
appen or not.</span> People are using outputs to store data <b>today</b>=E2=
=80=8B. The only question now is harm reduction: given that people are stor=
ing this data in outputs today, do we want to offer a way to do it that doe=
s not force every single full node on the network to store their data forev=
er? <br></span></div><div><span><br></span></div><div><span style=3D"font-f=
amily:Arial,sans-serif;font-size:14px;font-weight:400;color:rgb(0,0,0);back=
ground-color:rgb(255,255,255)">That said i agree that this is not going to =
change anything for people who try to store large amount of data onchain, t=
hey already have a 4x cheaper way of doing so.<br></span></div><div><span s=
tyle=3D"font-family:Arial,sans-serif;font-size:14px;font-weight:400;color:r=
gb(0,0,0);background-color:rgb(255,255,255)"><br></span></div><div><blockqu=
ote style=3D"border-left:3px solid rgb(200,200,200);border-color:rgb(200,20=
0,200);padding-left:10px;color:rgb(102,102,102)">For example, let&#39;s say=
 I want to distribute malware. Well, might as well just store it in an OP_R=
ETURN.</blockquote><span><br></span></div><div><span style=3D"font-family:A=
rial,sans-serif;font-size:14px;font-weight:400;color:rgb(0,0,0);background-=
color:rgb(255,255,255)">The point about storing data on everyone&#39;s disk=
 was addressed by others: it&#39;s already possible and that&#39;s why Core=
 XOR&#39;s the content of third-party-controlled data it writes to disk. Bu=
t an interesting fact on this specific point about malware and OP_RETURN ou=
tputs is how they have already been used in the past to resiliently update =
the domain of a malware&#39;s C2 servers: <span><a rel=3D"noreferrer nofoll=
ow noopener" href=3D"https://news.sophos.com/wp-content/uploads/2020/06/glu=
pteba_final-1.pdf" target=3D"_blank" data-saferedirecturl=3D"https://www.go=
ogle.com/url?hl=3Den&amp;q=3Dhttps://news.sophos.com/wp-content/uploads/202=
0/06/glupteba_final-1.pdf&amp;source=3Dgmail&amp;ust=3D1746231111394000&amp=
;usg=3DAOvVaw3u1cRRTsE_C-nmZM2H0oSl">https://news.sophos.com/wp-content/upl=
oads/2020/06/glupteba_final-1.pdf</a></span> .<br></span></div><div><span s=
tyle=3D"font-family:Arial,sans-serif;font-size:14px;font-weight:400;color:r=
gb(0,0,0);background-color:rgb(255,255,255)"><br></span></div><div><span><b=
lockquote style=3D"border-left:3px solid rgb(200,200,200);border-color:rgb(=
200,200,200);padding-left:10px;color:rgb(102,102,102)">This is a fundamenta=
l change to the nature of what the Bitcoin network itself is in its entiret=
y. [...] Bitcoin as we know it changes forever in the most fundamental way =
imaginable<br></blockquote><br></span></div><div><span>Wild emotional claim=
s with no ground whatsoever don&#39;t convince anybody and only hurt your c=
redibility.</span></div><div><span><br></span></div><blockquote style=3D"bo=
rder-left:3px solid rgb(200,200,200);border-color:rgb(200,200,200);padding-=
left:10px;color:rgb(102,102,102)"><div><span>and we might as well give up o=
n Bitcoin ever being a thing if this is the path chosen<br></span></div></b=
lockquote><div><span style=3D"font-family:Arial,sans-serif;font-size:14px;f=
ont-weight:400;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></sp=
an></div><div><span style=3D"font-family:Arial,sans-serif;font-size:14px;fo=
nt-weight:400;color:rgb(0,0,0);background-color:rgb(255,255,255)">Well if y=
ou believe the whole system is as brittle as relying on people playing nice=
 for security, you might as well give up now.</span></div><div><span style=
=3D"font-family:Arial,sans-serif;font-size:14px;font-weight:400;color:rgb(0=
,0,0);background-color:rgb(255,255,255)"><br></span></div><blockquote style=
=3D"border-left:3px solid rgb(200,200,200);border-color:rgb(200,200,200);pa=
dding-left:10px;color:rgb(102,102,102)"><div>Have the courage to reject thi=
s type of thing for the sake of the overall project.<span><br></span></div>=
</blockquote><div><br></div><div><span><span style=3D"font-family:Arial,san=
s-serif;font-size:14px;font-weight:400;color:rgb(0,0,0);background-color:rg=
b(255,255,255)">Right. We do that, and you go outside and touch some grass =
for the benefit of all subscribers to this mailing list.<br></span></span><=
/div><div><span><span style=3D"font-family:Arial,sans-serif;font-size:14px;=
font-weight:400;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></s=
pan></span></div><div><span><span style=3D"font-family:Arial,sans-serif;fon=
t-size:14px;font-weight:400;color:rgb(0,0,0);background-color:rgb(255,255,2=
55)"><blockquote style=3D"border-left:3px solid rgb(200,200,200);border-col=
or:rgb(200,200,200);padding-left:10px;color:rgb(102,102,102)">If you don&#3=
9;t have confidence in the Bitcoin Core developers, instead of insulting th=
em, you could also just (help) maintain a fork of the project. I obviously =
think you&#39;re misguided here, but at least it&#39;s better to channel th=
is distrust into something constructive. Given the number of people who sha=
re your sentiment, <b>such a project should be perfectly viable</b>.
<span><span><br></span></span></blockquote><br></span></span></div><div><sp=
an style=3D"font-family:Arial,sans-serif;font-size:14px;font-weight:400;col=
or:rgb(0,0,0);background-color:rgb(255,255,255)">Doubt.</span></div><div><s=
pan style=3D"font-family:Arial,sans-serif;font-size:14px;font-weight:400;co=
lor:rgb(0,0,0);background-color:rgb(255,255,255)"><br></span></div><div><sp=
an><span style=3D"font-family:Arial,sans-serif;background-color:rgb(255,255=
,255)"><blockquote style=3D"border-left:3px solid rgb(200,200,200);border-c=
olor:rgb(200,200,200);padding-left:10px;color:rgb(102,102,102)">It was sugg=
ested in two different PRs ([0] and [1]) that the conceptual discussion tak=
e place in this thread, so I am submitting my comments here.<span><span><br=
></span></span></blockquote></span></span><span><br></span></div><div><span=
 style=3D"font-family:Arial,sans-serif;font-size:14px;font-weight:400;color=
:rgb(0,0,0);background-color:rgb(255,255,255)">Thank you for taking concept=
ual discussion to the mailing list. AJ already addressed your claims, so i =
won&#39;t repeat it here.</span></div><div><span style=3D"font-family:Arial=
,sans-serif;font-size:14px;font-weight:400;color:rgb(0,0,0);background-colo=
r:rgb(255,255,255)"><br></span></div><div><span><span style=3D"font-family:=
Arial,sans-serif;background-color:rgb(255,255,255)"><blockquote style=3D"bo=
rder-left:3px solid rgb(200,200,200);border-color:rgb(200,200,200);padding-=
left:10px;color:rgb(102,102,102)">This is just a temporary cease-fire while=
 the spammers reload their ammunition. There is obviously about to be anoth=
er wave<span><span><br></span></span></blockquote></span></span><span><br><=
/span></div><div><span>Between this one and your previous email, you certai=
nly do know a lot about the future! How&#39;s your trading going?</span></d=
iv><div><span><br></span></div><div><span><span><span style=3D"font-family:=
Arial,sans-serif;background-color:rgb(255,255,255)"><blockquote style=3D"bo=
rder-left:3px solid rgb(200,200,200);border-color:rgb(200,200,200);padding-=
left:10px;color:rgb(102,102,102)">otherwise what is the point of eliminatin=
g OP_RETURN restrictions?<span><span><br></span></span></blockquote></span>=
</span><br></span></div><div><span style=3D"font-family:Arial,sans-serif;fo=
nt-size:14px;font-weight:400;color:rgb(0,0,0);background-color:rgb(255,255,=
255)">To not force people to bloat the UTxO set to store a trivial amount o=
f data in the output of a time-sensitive transactions. On the specifics, Ci=
trea stores <span>a zk-proof verifying Bitcoin&#39;s longest chain composed=
 of a
128-byte Groth16 proof and
16-byte total accumulated work (sauce: <span><a rel=3D"noreferrer nofollow =
noopener" href=3D"https://x.com/ekrembal_/status/1918008476552356202" targe=
t=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp=
;q=3Dhttps://x.com/ekrembal_/status/1918008476552356202&amp;source=3Dgmail&=
amp;ust=3D1746231111394000&amp;usg=3DAOvVaw3pmdPufum6Irhfd5xlZSY4">https://=
x.com/ekrembal_/status/1918008476552356202</a></span></span><span></span>).=
 I don&#39;t know and don&#39;t care why they do it in this way in particul=
ar, i just wish they did so in pruneable OP_RETURN outputs instead of unspe=
ndable Taproot outputs as they do today. Or worse, start thinking about bar=
e multisig.<br></span></div><div><span style=3D"font-family:Arial,sans-seri=
f;font-size:14px;font-weight:400;color:rgb(0,0,0);background-color:rgb(255,=
255,255)"><br></span></div><div><span><span><span style=3D"font-family:Aria=
l,sans-serif;background-color:rgb(255,255,255)"><blockquote style=3D"border=
-left:3px solid rgb(200,200,200);border-color:rgb(200,200,200);padding-left=
:10px;color:rgb(102,102,102)">Yes, and then the money printer makes sure th=
at there is always enough easy money sloshing around in the economy so that=
 more pop up where the old ones dropped out. This can and will continue ind=
efinitely if we do nothing.<span><span><br></span></span></blockquote></spa=
n></span></span><span><br></span></div><div><span style=3D"font-family:Aria=
l,sans-serif;font-size:14px;font-weight:400;color:rgb(0,0,0);background-col=
or:rgb(255,255,255)">Money printer financing working people forever certain=
ly isn&#39;t something i expected to read on the Bitcoin dev mailing list!<=
/span></div><div><span style=3D"font-family:Arial,sans-serif;font-size:14px=
;font-weight:400;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></=
span></div><blockquote style=3D"border-left:3px solid rgb(200,200,200);bord=
er-color:rgb(200,200,200);padding-left:10px;color:rgb(102,102,102)"><div><s=
pan style=3D"font-family:Arial,sans-serif;font-size:14px;font-weight:400;co=
lor:rgb(0,0,0);background-color:rgb(255,255,255)"></span></div><span></span=
><span>My proposal is not to counter literally every type of spam. Just the=
 ones that have protocols relying on consistent transaction formats. Creati=
ng specific filters against just these worst offenders should</span></block=
quote><div><span style=3D"font-family:Arial,sans-serif;font-size:14px;font-=
weight:400;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></span><=
/div><div><span style=3D"font-family:Arial,sans-serif;font-size:14px;font-w=
eight:400;color:rgb(0,0,0);background-color:rgb(255,255,255)">This is veeri=
ng off-topic for this thread. If you want to argue that Core should filter =
inscriptions could you take it to the appropriate thread? This thread is ju=
st about damage control for people storing data in transaction outputs.</sp=
an></div><div><span style=3D"font-family:Arial,sans-serif;font-size:14px;fo=
nt-weight:400;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></spa=
n></div><blockquote style=3D"border-left:3px solid rgb(200,200,200);border-=
color:rgb(200,200,200);padding-left:10px;color:rgb(102,102,102)"><div>I bel=
ieve you greatly overestimate the skill and competence of the people who wo=
uld do this type of thing. You could accomplish what you&#39;ve laid out. I=
 could accomplish it.<span><br></span></div></blockquote><div style=3D"font=
-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:r=
gb(255,255,255)"><br></div><div style=3D"font-family:Arial,sans-serif;font-=
size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)">Your hubris g=
ives me second-hand embarrassment. I hope the C2 domain update i shared abo=
ve gives you a clue that there does in fact exist other smart people in the=
 world. Threat actors would laugh pretty hard at your arrogant emails and e=
motional breakdowns, but they probably don&#39;t care about your  filters i=
n the slightest anyways.</div><div style=3D"font-family:Arial,sans-serif;fo=
nt-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div>=
<div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);=
background-color:rgb(255,255,255)">After reading the whole thread i have ye=
t to read a single sound objection to lifting the OP_RETURN restrictions.<b=
r></div><div>
        On Thursday, April 17th, 2025 at 2:52 PM, Antoine Poinsot &lt;<a hr=
ef data-email-masked rel=3D"nofollow">daro...@protonmail.com</a>&gt; wrote:=
<br>
        <blockquote type=3D"cite">
            <div style=3D"font-family:Arial,sans-serif;font-size:14px">
<div style=3D"font-family:Arial,sans-serif;font-size:14px">
    <div>

            </div>

            <div>

            </div>
</div>
Hi,<br>
<br>
Standardness rules exist for 3 mains reasons: mitigate DoS vectors, provide=
 upgrade hooks, or as a nudge to deter some usages.</div><div style=3D"font=
-family:Arial,sans-serif;font-size:14px"><br></div><div style=3D"font-famil=
y:Arial,sans-serif;font-size:14px">Bitcoin Core will by default only relay =
and mine transactions with at most a single OP_RETURN output, with a script=
PubKey no larger than 83 bytes. <span>This standardness rule falls into the=
 third category: it aims to mildly deter data storage while still allowing =
a less harmful alternative than using non-provably-unspendable outputs.</sp=
an></div><div style=3D"font-family:Arial,sans-serif;font-size:14px"><span><=
br></span></div><div style=3D"font-family:Arial,sans-serif;font-size:14px">=
Developers are now designing constructions that work around these limitatio=
ns. An example is Clementine, the recently-announced Citrea bridge, which u=
ses unspendable Taproot outputs to store data in its &quot;WatchtowerChalle=
nge&quot; transaction due to the standardness restrictions on the size of O=
P_RETURNs[^0]. Meanwhile, we have witnessed in recent years that the nudge =
is ineffective to deter storing data onchain.</div><div style=3D"font-famil=
y:Arial,sans-serif;font-size:14px"><br></div><div style=3D"font-family:Aria=
l,sans-serif;font-size:14px">Since the restrictions on the usage of OP_RETU=
RN 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 the size of the scriptPubKey for OP_RETURN outputs, as a fir=
st minimal step to stop encouraging harmful behaviour, and to then proceed =
to lift the restriction on the number of OP_RETURN outputs per transactions=
.<br></div><div style=3D"font-family:Arial,sans-serif;font-size:14px"><br><=
/div><div style=3D"font-family:Arial,sans-serif;font-size:14px">Antoine Poi=
nsot<br></div><div style=3D"font-family:Arial,sans-serif;font-size:14px"><b=
r></div><div style=3D"font-family:Arial,sans-serif;font-size:14px">[^0]: Se=
e section 6.1 of their whitepaper here <span><a rel=3D"noreferrer nofollow =
noopener" href=3D"https://citrea.xyz/clementine_whitepaper.pdf" target=3D"_=
blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dh=
ttps://citrea.xyz/clementine_whitepaper.pdf&amp;source=3Dgmail&amp;ust=3D17=
46231111394000&amp;usg=3DAOvVaw2QcXAUpEF87BpIlUoNBWtB">https://citrea.xyz/c=
lementine_whitepaper.pdf</a></span><br></div>
        </blockquote><br>
    </div></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/68cdce0e-9030-4a6b-92a4-d48d05be3e80n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/68cdce0e-9030-4a6b-92a4-d48d05be3e80n%40googlegroups.com</a>.<br />

------=_Part_55537_1523779707.1746144883759--

------=_Part_55536_968519904.1746144883759--