From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: <68cdce0e-9030-4a6b-92a4-d48d05be3e80n@googlegroups.com> In-Reply-To: References: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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.

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.

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

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

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.

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.

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

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.

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.

Users care and want to protect Bitcoin. B= e grateful.

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 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=A0https://antoinep.com/posts/relay_policy= _drama.

Going through the emails i= n order.

Am I = the only one left on this list who actually cares about Bitcoin's survival?

Thanks Luke for your measured take. It's= refreshing to see we have adults on both sides of this "debate".=

With that history in mind, removing limi= ts on OP_RETURN standardness size is pointless.

=
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'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.

Relaxing OP_RETURN size limits without deali= ng with the inscriptions

This is orth= ogonal. The harmful behaviour described in OP is possible today regardless = of inscriptions.

There's little to no incentive to use OP_RETURN= for data storage when using the 'inscriptions' exploit costs 4x le= ss in transactions. What's the point of having a "standard" 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?
=
You have= obviously not properly read or understood OP.=C2=A0There is no need to speculate about what would h= appen or not. People are using outputs to store data today=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?

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.

For example, let's say= I want to distribute malware. Well, might as well just store it in an OP_R= ETURN.
The point about storing data on everyone's disk= was addressed by others: it's already possible and that's why Core= XOR'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's C2 servers: https://news.sophos.com/wp-content/upl= oads/2020/06/glupteba_final-1.pdf .

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

Wild emotional claim= s with no ground whatsoever don't convince anybody and only hurt your c= redibility.

and we might as well give up o= n Bitcoin ever being a thing if this is the path chosen

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.

Have the courage to reject thi= s type of thing for the sake of the overall project.
=

Right. We do that, and you go outside and touch some grass = for the benefit of all subscribers to this mailing list.
<= /div>

If you don= 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're misguided here, but at least it's better to channel th= is distrust into something constructive. Given the number of people who sha= re your sentiment, such a project should be perfectly viable.

Doubt.

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.

Thank you for taking concept= ual discussion to the mailing list. AJ already addressed your claims, so i = won't repeat it here.

This is just a temporary cease-fire while= the spammers reload their ammunition. There is obviously about to be anoth= er wave

<= /span>
Between this one and your previous email, you certai= nly do know a lot about the future! How's your trading going?

otherwise what is the point of eliminatin= g OP_RETURN restrictions?
=
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 a zk-proof verifying Bitcoin's longest chain composed= of a 128-byte Groth16 proof and 16-byte total accumulated work (sauce: https://= x.com/ekrembal_/status/1918008476552356202).= I don't know and don'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.

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.

Money printer financing working people forever certain= ly isn't something i expected to read on the Bitcoin dev mailing list!<= /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

<= /div>
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.

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've laid out. I= could accomplish it.

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't care about your filters i= n the slightest anyways.

=
After reading the whole thread i have ye= t to read a single sound objection 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, provide= upgrade hooks, or as a nudge to deter some usages.

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. 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.
<= br>
= 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 "WatchtowerChalle= nge" 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.

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

<= /div>
Antoine Poi= nsot
[^0]: Se= e section 6.1 of their whitepaper here https://citrea.xyz/c= lementine_whitepaper.pdf

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/68cdce0e-9030-4a6b-92a4-d48d05be3e80n%40googlegroups.com.
------=_Part_55537_1523779707.1746144883759-- ------=_Part_55536_968519904.1746144883759--