From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 01 May 2025 15:46:27 -0700 Received: from mail-oi1-f188.google.com ([209.85.167.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uAcfi-0003fa-0c for bitcoindev@gnusha.org; Thu, 01 May 2025 15:46:27 -0700 Received: by mail-oi1-f188.google.com with SMTP id 5614622812f47-400b3a7e259sf449007b6e.3 for ; Thu, 01 May 2025 15:46:26 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1746139580; cv=pass; d=google.com; s=arc-20240605; b=evEGaLnpBwQaL+qS2g2oztAQ1pj8ry/qFtNeTHcmemuqNZqVrnkaLSSafoM6dmMNT+ Xg/6Y82C4pC3887SJAh+fo26esAjSen4ikCv7FcrYnL9IAavNCYljNQJmmm/v9GPwBRa FUVcZ33O1d09pa4TuGDEQBTpV1SUzA9cZZvHY8arJHVi7LCDmAJDqM2yzfBcfLjncdOK JfsOdfTCw5keEvRsGgTQyN5N/yxHEKR6ZWIr7vTmU3+m+9yc1LP4hSstlNzuUUQ/Ei/6 I10QOyPvRtcktPcAu2dj2Ap+K57e3qPYjmQ5xxATJskPu+7Kou/6DeWyO5mupIJBt02D eXqA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id :references:in-reply-to:message-id:subject:from:to:date :dkim-signature; bh=fjGU+0yx1kEa/NhQ0MMTrir/LtczRYYzfqMJVx2YLHc=; fh=QNfll5Ur+59iVUzIY81vj2KBAEPELH/KBXQA7GNSEh4=; b=OsvqnpyB2/BSiMvnJCV6xmhSYdnNv1SDZCOdAyyObNqnM+F+2kVwvkruLI8AAvRord kSJE1/ve6nkTDYJ0u0CS07maOL0AEdSMb7Vbn3NA3n3uQtsJJQjWpljEtW6ziLIV2hFB ELe5Fraw86J3B/O08uOh7lfDPUVIMW+X10JwCKbZIzIwprVrsM8t1aME34aLIvylQKM6 TUVtzMRkwU/Mys0l6yYJXh+GcbYTC8vyMA+ZQv984VoTYkdQ+/81emWz/JP9OoGwWqHx c96rZsdr6Uejv8kCiW57su1p/yzcLA1BKEmy5aZxohaE6dIMoGb4d9/eIeI5HokFeHcr BcgQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="Oy/ycGEU"; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1746139580; x=1746744380; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:from:to:date :from:to:cc:subject:date:message-id:reply-to; bh=fjGU+0yx1kEa/NhQ0MMTrir/LtczRYYzfqMJVx2YLHc=; b=LgFnJtiV379hM1uWZA8/EMQVmk4rRgEpus890Kpd2dPgq8AfjKPNrIrGX7ok27aiYc 4M5/EuME4swMOMMEYYDade1J9mNzP6puzBSduYUDEO+1iI+TR88T5O5GHskvtF2/NEBa bLADDCqPzpy3wYssgwIPXaRUdOW6cTt3pUPxISVLET0GqrvklHIzu+qa85o6FvqkpaSi 2DBtI7UyWwSEWhzSbd/KfeB6Jbvt0XOo0+RRFngqAKRs/sBUzNfxnMr6P01n6Ku+8dND GuBYPnUZqpVzUYCXuq4+LvRdZkvsOad9oc20xAEW2XEFnotRTEU9Kt68evRfP6A9EpuB wqOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746139580; x=1746744380; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to :x-original-authentication-results:x-original-sender:mime-version :feedback-id:references:in-reply-to:message-id:subject:from:to:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fjGU+0yx1kEa/NhQ0MMTrir/LtczRYYzfqMJVx2YLHc=; b=B0GiXRkJpLkd64bVR/BnQZaIKq+0WoZkOVFlmiesFH80/UzGh0LMLSXbQVgJccrhuO R8xh9EXgYlLDaUTZiCiiNrqa+yG30ObQ/npzmhAEOArXX44d9RIpdIY8lrQl3HbU7dDg yst02EG7lWApIzJlPzeFhLEL16sHu0O0q9HSrksYZEzD3hfWuygieWwhLE0HpNJHJn9D K3iZhY0g36YjVKrQhNIOH6C49gcrKkw6nQ5gEFsZuZh6sWS1TYQs/jI3THX1nOXfaJXh LEGCu9w1AzzmxNxgsw3tRb1gsV7EDZhUvvoOdLFWomh/I0eX/37El8U0sGMU7jbsGbfB 19Zg== X-Forwarded-Encrypted: i=2; AJvYcCUTrfEz3fxJzXQNnf8CSu3snvT/yfG0NtZbqZ/FoGWgW4h0dF3uHqm2SOFHHvXk/ZBPMKoWmrPhV3Kv@gnusha.org X-Gm-Message-State: AOJu0YzbivOuNmczhhIU1SixQl28H2oezOVgh3K74WC90h0kEao3KrN4 rQoY4eTelDrgJ+tEsxS6eWO8v8ZOJoRdXNjgttmTSQqvaqy2+igV X-Google-Smtp-Source: AGHT+IEbr3cSAFi7YA6LzrA2mTX58S5Tc6mmDpo7wG9Cc89B0HJNDCckpWnMHHnr9b23ChxcuVMlfw== X-Received: by 2002:a05:6870:b010:b0:2d5:cb5:2193 with SMTP id 586e51a60fabf-2dab340a881mr375684fac.35.1746139579998; Thu, 01 May 2025 15:46:19 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBGHAuwPcDgrs0HJqgOiBTfzJEn08nlfPOr7B0ZCf3UGiA== Received: by 2002:a05:6871:2b19:b0:2d5:b2c1:db0b with SMTP id 586e51a60fabf-2da8a5b747els558652fac.2.-pod-prod-06-us; Thu, 01 May 2025 15:46:15 -0700 (PDT) X-Received: by 2002:a05:6808:850e:b0:403:37dd:e26f with SMTP id 5614622812f47-403414acf13mr538308b6e.33.1746139575671; Thu, 01 May 2025 15:46:15 -0700 (PDT) Received: by 2002:ab3:11b:0:b0:293:3256:5107 with SMTP id a1c4a302cd1d6-2acb761afabmsc7a; Thu, 1 May 2025 15:40:27 -0700 (PDT) X-Received: by 2002:a2e:bc8f:0:b0:30b:f2d7:1e7c with SMTP id 38308e7fff4ca-320ab29ac51mr2353101fa.5.1746139223932; Thu, 01 May 2025 15:40:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1746139223; cv=none; d=google.com; s=arc-20240605; b=FoTY7TsxXQCakQaB3JdCqO5Hr+txAutzns5K57gjojzA25X67hVO6yXbXmnGNDzv8e jtoBE8JHURawSadtSLyQC1h44MYzp0cu81MXyag7AIIvhuRow60fco0S5RTlJ++l3WWQ 8OaqpaERfpgZRzLUEKvl4IkbrMvqBj7U24cUnjEziHwwP4veEzCtqqs/47bI3TA6AUlL oEAwFV7QWJk2SCWRWyeMhvNuPsErhXIQYBeViMMgCC5uK7Cz+PXPHJQ+6VwEFmRoUsuz JHS1LtBvnE08SMOxKuR15LtIvmYzOiR7rq/qAEeqpZPPf2UcSpcUqvCJsemXy78aH+iQ k4OQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=mime-version:feedback-id:references:in-reply-to:message-id:subject :from:to:date:dkim-signature; bh=ZLuHoP3ib42SpaAlKu0Q0YksfUNNAGNXyq4gqOZpO3A=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=iJIBl1iYHXYrEhObxUfBBTAL3+OuEePgdjokQI2uS8PkQigLwzdUO90oyZT29MhdlF wN/NbMgbcHzNA2GEQ4/VmbxEuJ8T3tb7SWuDSBYqf05Lfp6M30b9edl8O69QY2sCGv7O z+udy7oLZ7Zggfw4DAhAv9Pa+TBmkMESnZ2EftZ/+8NKZuORlFzrftFJT+P8S+ObxnAu tIhkANXDTFzaCrGRFiEnoFxvX/zKH+9s7EYJYjRd4jw/qib1j4rzcds+EfvPl5peF2nZ /fsUluVvTaMR+EAHQCFpDzVXECBLUu3dn5E2qIhJ/WX3H33c/IzcuxlWP8TrjwNh/r5Q jjYQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="Oy/ycGEU"; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch. [185.70.43.22]) by gmr-mx.google.com with ESMTPS id 38308e7fff4ca-3202a5b2067si576021fa.5.2025.05.01.15.40.23 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 01 May 2025 15:40:23 -0700 (PDT) Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) client-ip=185.70.43.22; Date: Thu, 01 May 2025 22:40:19 +0000 To: Bitcoin Development Mailing List From: "'Antoine Poinsot' via Bitcoin Development Mailing List" Subject: [bitcoindev] Re: Relax OP_RETURN standardness restrictions Message-ID: In-Reply-To: References: Feedback-ID: 7060259:user:proton X-Pm-Message-ID: 32c5b2510e329ca7b426e4203c28b8f8d122b3d4 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1=_kl5kv3pcGNN66T3alolLVpk3cQZSu8RAwsK9HTsNE" X-Original-Sender: darosior@protonmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b="Oy/ycGEU"; spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.22 as permitted sender) smtp.mailfrom=darosior@protonmail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com X-Original-From: Antoine Poinsot Reply-To: Antoine Poinsot 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: -1.0 (-) --b1=_kl5kv3pcGNN66T3alolLVpk3cQZSu8RAwsK9HTsNE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As i have repeatedly asked people to take conceptual discussions to the mai= ling list, i am circling back to this thread to answer objections. I have a= lso written my point of view and reasons for proposing this change in a blo= g post which goes into more details: https://antoinep.com/posts/relay_polic= y_drama. Going through the emails in order. > Am I the only one left on this list who actually cares about Bitcoin's su= rvival? Thanks Luke for your measured take. It's refreshing to see we have adults o= n both sides of this "debate". > With that history in mind, removing limits on OP_RETURN standardness size= is pointless. Yes, it is pointless for people who want to store massive amount of data. I= t is not for people who want to store a small amount of data in a time-sens= itive transaction's output. Because they need their transaction to be relay= ed on the p2p network, and are therefore pushed to use unspendable outputs = instead. > Relaxing OP_RETURN size limits without dealing with the inscriptions This is orthogonal. 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 usi= ng the 'inscriptions' exploit costs 4x less in transactions. What's the poi= nt of having a "standard" way to store arbitrary data if the exploit method= is 4x cheaper? And the nonstandard version of the exploit allows 4x the da= ta? You have obviously not properly read or understood OP. There is no need to = speculate about what would happen or not. People are using outputs to store= data today=E2=80=8B. The only question now is harm reduction: given that p= eople are storing this data in outputs today, do we want to offer a way to = do it that does not force every single full node on the network to store th= eir data forever? That said i agree that this is not going to change anything for people who = try to store large amount of data onchain, they already have a 4x cheaper w= ay of doing so. > For example, let's say I want to distribute malware. Well, might as well = just store it in an OP_RETURN. 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-co= ntrolled data it writes to disk. But an interesting fact on this specific p= oint about malware and OP_RETURN outputs is how they have already been used= in the past to resiliently update the domain of a malware's C2 servers: ht= tps://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 it= self is in its entirety. [...] Bitcoin as we know it changes forever in the= most fundamental way imaginable Wild emotional claims with no ground whatsoever don't convince anybody and = only hurt your credibility. > and we might as well give up on Bitcoin ever being a thing if this is the= path chosen Well if you believe the whole system is as brittle as relying on people pla= ying 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= project. Right. We do that, and you go outside and touch some grass for the benefit = of all subscribers to this mailing list. > If you don't have confidence in the Bitcoin Core developers, instead of i= nsulting them, 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= this distrust into something constructive. Given the number of people who = share your sentiment, such a project should be perfectly viable. Doubt. > It was suggested in two different PRs ([0] and [1]) that the conceptual d= iscussion take place in this thread, so I am submitting my comments here. Thank you for taking conceptual 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 ammun= ition. There is obviously about to be another wave Between this one and your previous email, you certainly do know a lot 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 data= in the output of a time-sensitive transactions. On the specifics, Citrea s= tores a zk-proof verifying Bitcoin's longest chain composed of a 128-byte G= roth16 proof and 16-byte total accumulated work (sauce: https://x.com/ekrem= bal_/status/1918008476552356202). I don't know and don't care why they do i= t in this way in particular, i just wish they did so in pruneable OP_RETURN= outputs instead of unspendable Taproot outputs as they do today. Or worse,= start thinking about bare multisig. > Yes, and then the money printer makes sure that there is always enough ea= sy money sloshing around in the economy so that more pop up where the old o= nes dropped out. This can and will continue indefinitely if we do nothing. Money printer financing working people forever certainly isn't something i = expected to read on the Bitcoin dev mailing list! > My proposal is not to counter literally every type of spam. Just the ones= that have protocols relying on consistent transaction formats. Creating sp= ecific filters against just these worst offenders should This is veering off-topic for this thread. If you want to argue that Core s= hould filter inscriptions could you take it to the appropriate thread? This= thread is just about damage control for people storing data in transaction= outputs. > I believe you greatly overestimate the skill and competence of the people= who would do this type of thing. You could accomplish what you've laid out= . I could accomplish it. Your hubris gives me second-hand embarrassment. I hope the C2 domain update= i shared above 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 emotional breakdowns, but they probably don't care about your f= ilters in the slightest anyways. After reading the whole thread i have yet to read a single sound objection = to lifting the OP_RETURN restrictions. On Thursday, April 17th, 2025 at 2:52 PM, Antoine Poinsot wrote: > Hi, > > Standardness rules exist for 3 mains reasons: mitigate DoS vectors, provi= de upgrade hooks, or as a nudge to deter some usages. > > Bitcoin Core will by default only relay and mine transactions with at mos= t a single OP_RETURN output, with a scriptPubKey no larger than 83 bytes. T= his standardness rule falls into the third category: it aims to mildly dete= r data storage while still allowing a less harmful alternative than using n= on-provably-unspendable outputs. > > Developers are now designing constructions that work around these limitat= ions. An example is Clementine, the recently-announced Citrea bridge, which= uses unspendable Taproot outputs to store data in its "WatchtowerChallenge= " transaction due to the standardness restrictions on the size of OP_RETURN= s[^0]. Meanwhile, we have witnessed in recent years that the nudge is ineff= ective to deter storing data onchain. > > Since the restrictions on the usage of OP_RETURN outputs encourage harmfu= l 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 first minimal step to stop enc= ouraging harmful behaviour, and to then proceed to lift the restriction on = the number of OP_RETURN outputs per transactions. > > Antoine Poinsot > > [^0]: See section 6.1 of their whitepaper here https://citrea.xyz/clement= ine_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/= IpyzvdqFhM_40OKYdilNrHU9u_cIx7BKlYKBUgTGPW6idPAItRiza5tq8B1jEs141ypieLGkR2U= MRIxg0qdxBMl6DQ3UKaQsID0gBjWLXtY%3D%40protonmail.com. --b1=_kl5kv3pcGNN66T3alolLVpk3cQZSu8RAwsK9HTsNE Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As i have repeatedly asked people to take conceptual discus= sions to the mailing list, i am circling back to this thread to answer obje= ctions. 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<= /a>.




<= 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);">
With that histor= y in mind, removing limits on OP_RETURN standardness size is pointless.

Yes, it is pointle= ss for people who want to store massive amount of data. It is not for peopl= e who want to store a small amount of data in a time-sensitive transaction'= s output. Because they need their transaction to be relayed on the p2p netw= ork, and are therefore pushed to use unspendable outputs instead.

Relaxing OP_RETURN size limits without de= aling with the inscriptions

This is orthogonal. The harmful behaviour described in OP is p= ossible today regardless of inscriptions.

There's little to no incentive to use OP_RETURN for data storage = when using the 'inscriptions' exploit costs 4x less in transactions. What's= the point of having a "standard" way to store arbitrary data if the exploi= t method is 4x cheaper? And the nonstandard version of the exploit allows 4= x the data?

You have ob= viously not properly read or understood OP. There is no need to speculate about what would = happen or not. People are using outputs to store data today= =E2=80=8B. The only question now is harm reduction: given that people are s= toring this data in outputs today, do we want to offer a way to do it that = does not force every single full node on the network to store their data fo= rever?

<= div style=3D"">That said i agree that this is not going to change anything for peop= le who try to store large amount of data onchain, they already have a 4x ch= eaper way of doing so.






Thank you for taking conceptual discussion to the mailing= list. AJ already addressed your claims, so i won't repeat it here.<= /div>

This is just a t= emporary cease-fire while the spammers reload their ammunition. There is ob= viously about to be another wave
=
Between this one and your previous email, you certainly do know a lot= 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 dat= a in the output of a time-sensitive transactions. On the specifics, Citrea = 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<= /span>). I don't know and don't care why they do it in this wa= y in particular, i just wish they did so in pruneable OP_RETURN outputs ins= tead of unspendable Taproot outputs as they do today. Or worse, start think= ing about bare multisig.

Yes, and then the money printer makes sure that t= here is always enough easy money sloshing around in the economy so that mor= e pop up where the old ones dropped out. This can and will continue indefin= itely if we do nothing.

Money printer finan= cing working people forever certainly isn't something i expected to read on= the Bitcoin dev mailing list!

My proposal is not to counter literally every= type of spam. Just the ones that have protocols relying on consistent tran= saction formats. Creating specific filters against just these worst offende= rs should

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 believe you greatly overest= imate the skill and competence of the people who would do this type of thin= g. You could accomplish what you've laid out. I could accomplish it.

Your= hubris gives me second-hand embarrassment. I hope the C2 domain update i s= hared above gives you a clue that there does in fact exist other smart peop= le in the world. Threat actors would laugh pretty hard at your arrogant ema= ils and emotional breakdowns, but they probably don't care about your filt= ers in the slightest anyways.

After rea= ding the whole thread i have yet to read a single sound objection to liftin= g the OP_RETURN restrictions.
On Thursday, April 17th, 2025 at 2:52 PM, Antoine Poinsot <daros= ior@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 o= nly relay and mine transactions with at most a single OP_RETURN output, wit= h a scriptPubKey no larger than 83 bytes. This standardness rule fall= s into the third category: it aims to mildly deter data storage while still= allowing a less harmful alternative than using non-provably-unspendable ou= tputs.

Developers are now designing constructions that work ar= ound these limitations. An example is Clementine, the recently-announced Ci= trea bridge, which uses unspendable Taproot outputs to store data in its "W= atchtowerChallenge" transaction due to the standardness restrictions on the= size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years that = the nudge is ineffective to deter storing data onchain.

Since the restrictions on = the usage of OP_RETURN outputs encourage harmful practices while being inef= fective in deterring unwanted usage, i propose to drop them. I suggest to s= tart by lifting the restriction on the size of the scriptPubKey for OP_RETU= RN outputs, as a first minimal step to stop encouraging harmful behaviour, = and to then proceed to lift the restriction on the number of OP_RETURN outp= uts per transactions.

Antoine Poinsot

[^0]: See section 6.1 of their whitepaper h= ere https://citrea.xyz/clementin= e_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/bitcoindev/= IpyzvdqFhM_40OKYdilNrHU9u_cIx7BKlYKBUgTGPW6idPAItRiza5tq8B1jEs141ypieLGkR2U= MRIxg0qdxBMl6DQ3UKaQsID0gBjWLXtY%3D%40protonmail.com.
--b1=_kl5kv3pcGNN66T3alolLVpk3cQZSu8RAwsK9HTsNE--