From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Fri, 02 May 2025 12:09:54 -0700 Received: from mail-yw1-f191.google.com ([209.85.128.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uAvlh-0001IZ-PW for bitcoindev@gnusha.org; Fri, 02 May 2025 12:09:54 -0700 Received: by mail-yw1-f191.google.com with SMTP id 00721157ae682-703d7a66d77sf34019237b3.0 for ; Fri, 02 May 2025 12:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1746212988; x=1746817788; 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=BG+nFUecIxFWCZ+mlIQoJ0ZW0zE3HghxMTykxSaeZQo=; b=iYGCheqVx5usCFQn4241OnH07nL9sq6IyUX8VAx4EGAWx6Lg/JWB7LBDFg0WGalpvm 13o+UqkYuYpEaU9Pnw8vpADcPtb9fRsZfwd9BS9cs4hw/NbZ7DGDPoGxTT5KW7b5Ocl6 Ao7g39LUXO8WgBnt509vlGz3diMG7byQ0/V/Fb8YxI+KwK7MZuHnZ5ZLq+90ubNQ5Ds0 eKryRr3rYQKEN2pyiJo44WAZjMazV8N7r1ypZV7HiH2qu7OMn2t4q/9dVHVAF9ZqJhi9 GJYJmXSiYe33FsnX6eZXF7nrUd8P/25Z9Mh+6ILeQt5Z5CvSl/ktlS+zt6ED8entsx2k xP8Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1746212988; x=1746817788; 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=BG+nFUecIxFWCZ+mlIQoJ0ZW0zE3HghxMTykxSaeZQo=; b=Ts5T+Z1j50BBfDDuVb2nliMHBRs9Wwd3OaoqqzBKPPV8XDpAQD2cTyVeomKjrweT3r N89F+gkraKNAIbx6dviTR6VlPAYLKd8ScSwLiQFfuTjnV1vj4uY5XvKOIJHNQIUUDJGK jxr4Ep1qojxaXF3CzjyaQUVYOrL2leL8mGvHOJsclpy9nUSWr53TvYXstqaYVfxBeCAv u4+WDCpp4nclrh+rNzgmsWFCsun+MDNAncTQPauouF223eY1c72Ar6xLzS6ljADs0W1i c1FpA3018fVTv0r9GDNSRVZ0Dad1jqtvLgZS4P3LFPOVu3+JBogqM5EYM4wLTEel0PpM HTEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746212988; x=1746817788; 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=BG+nFUecIxFWCZ+mlIQoJ0ZW0zE3HghxMTykxSaeZQo=; b=VK6nf3D4JLPx48SaMWYYyBStS+uTCHWYCuTAsJXq4UanXxsCbqbU6eTnrLmt7CrKjI 1t/j/fgyLADbuWqmh7SEkRvNAjoM4Xq/tRUUEZenFlUYdhodFWEf8qN/XCZkSzJsTHOs iEYwUUtS6zxKndkmzC2PuWc9tZg4qW9xYFlfhj7ntDDqtjHAWB9C/AB8CTECk2uqE/3p Ao0Aw2pyONkGvDUPpOAUgs83X60AbKO1Rj6RUhRk3AZ7pxPeo+Jke7rDEtMApiLvu5EL UMwNNpxJogTDFocv+lm+jd29H9Blo1TE37tYZoJa9c4Eix9ndWFSfNmo3BLYUxtgv0o6 nz8A== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXg8bx+jGsxx43QWoOJyoezULwn2i88NPJb51bTTqxJh/W4Te1tk/WuoxvPKvMD1GP7H01RXNEi5ux/@gnusha.org X-Gm-Message-State: AOJu0Yxv6Selm0wB9NpLCUDeO/WqDGFDdFs8HJ+a2qjKzOGcXSnrvKjG +78CQnaIPFy/5OgpYjrucqtk6O93bFaPGjefl3XelP4873NebBOy X-Google-Smtp-Source: AGHT+IFQbTqlDBKyI83HEo4bJL7/R6FB61UYiCRw2iDPBYd28OMijasmymMwOsFM8Ou061oqpgRwcw== X-Received: by 2002:a05:690c:6104:b0:6fe:c2b4:f099 with SMTP id 00721157ae682-708bce5e233mr107180117b3.7.1746212987663; Fri, 02 May 2025 12:09:47 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBF+A2lJzN9fNWt1aORLA1mVksX3z9BZ8ssJFDdUbWg0FQ== Received: by 2002:a25:b225:0:b0:e72:6a60:9f92 with SMTP id 3f1490d57ef6-e74d9694c86ls614691276.0.-pod-prod-01-us; Fri, 02 May 2025 12:09:44 -0700 (PDT) X-Received: by 2002:a05:690c:7010:b0:6fb:ae6b:a340 with SMTP id 00721157ae682-708cf2208a0mr62279737b3.30.1746212984439; Fri, 02 May 2025 12:09:44 -0700 (PDT) Received: by 2002:a05:690c:a10:b0:708:1ea1:3cd5 with SMTP id 00721157ae682-708cfde0f15ms7b3; Fri, 2 May 2025 09:43:07 -0700 (PDT) X-Received: by 2002:a05:690c:338b:b0:6fe:bfb7:68bd with SMTP id 00721157ae682-708cf00eccamr59836347b3.1.1746204186122; Fri, 02 May 2025 09:43:06 -0700 (PDT) Date: Fri, 2 May 2025 09:43:05 -0700 (PDT) From: Greg Maxwell To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <68cdce0e-9030-4a6b-92a4-d48d05be3e80n@googlegroups.com> <1B78AC90-E698-421F-AECD-32DBCDD8669A@sprovoost.nl> Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_87678_303325306.1746204185781" X-Original-Sender: gmaxwell@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_87678_303325306.1746204185781 Content-Type: multipart/alternative; boundary="----=_Part_87679_538317059.1746204185781" ------=_Part_87679_538317059.1746204185781 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Friday, May 2, 2025 at 3:28:36=E2=80=AFPM UTC nsvrn wrote: "Spam is annoying but it always runs it course if you ignore it"=20 and=20 "When relay policy shouldn't be more restrictive than what is actually=20 being mined"=20 are contradictory statements by gmaxwell. Btw, 99.9% of transactions rn are= =20 standard, nothing has changed. People are pre-emptively making accomodation= =20 for a startup with a whitepaper. No one is making relay policy more=20 restrictive, they're talking about making it more flexible "pre-emptively".= =20 I've looked high and low and I can't find any case where I've made the=20 first quotation. Can you help me out? It sounds like a riff on views I=20 expressed but I can't find it. I think your comparison though demonstrates a downside of reasoning in=20 broad categories. High volume nuisance traffic tends to burn itself out= =20 because the user that is flooding out everyone else has to burn whatever=20 everyone else was willing to pay in each block everyone else is displaced= =20 from-- they run out of money. But my statement on relay policy doesn't=20 have much to do with volume. A small consistent _small_ stream of=20 transactions that aren't getting relayed but get mined anyways brings the= =20 downsides of having a mining inconsistent relay policy, there doesn't need= =20 to be a flood. And no flood, no self limiting behavior in any case. I also think your argument misses the mark in that there isn't a credible= =20 argument that there is/will-be any traffic floods that the=20 proposed-for-removal criteria will *prevent*. Anyone who wants to stuff=20 data into outputs can already stuff an unlimited amount, there are parties= =20 right now who are currently doing so. Moreover, there is no credible way= =20 to stop them from doing so (because you can't distinguish arbitrary data=20 from addresses, essentially). However, if they use OP_RETURN instead it= =20 will prevent the data from going into the UTXO set. Maybe they will maybe= =20 they won't. But counting this proposal with concerns about 'spam' doesn't= =20 get us anywhere because removing the restriction doesn't change the current= =20 situation with respect to 'spam' however you define it. It doesn't really matter how dire spam is when discussing a proposal that= =20 doesn't meaningfully *change* the situation around it, except perhaps in=20 giving a lever to convert some more harmful traffic into less harmful=20 traffic. If it did then sure the harms of the spam would be a relevant=20 consideration. > People are pre-emptively making accomodation for a startup with a=20 whitepaper I can't speak for others but I didn't follow any links related to citrea or= =20 any other startup in the thread, I don't think it's relevant. I have been= =20 complaining about standardizes rules screwing up block reconstruction and= =20 direct to miner relationships to bypass relay rules for several years. My= =20 impression is that random startup whatever carries precisely zero weight in= =20 minds of the vast majority of the commenters in favor of eliminating the=20 restriction. --=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/= f19214a4-6a89-4a2f-a729-560d244573bfn%40googlegroups.com. ------=_Part_87679_538317059.1746204185781 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Friday, May 2, 2025 at 3:28:36=E2=80=AFPM UTC nsv= rn wrote:
"Spam is annoying = but it always runs it course if you ignore it"
and=20
"When relay policy shouldn't be more restrictive than what is actuall= y being mined"

are contradictory statements by gmaxwell. Btw, 99.9% of transactions = rn are standard, nothing has changed. People are pre-emptively making accom= odation for a startup with a whitepaper. No one is making relay policy more= restrictive, they're talking about making it more flexible "pre-emptively"= .

I've looked high and low and I can= 't find any case where I've made the first quotation. Can you help me out?= =C2=A0 It sounds like a riff on views I expressed but I can't find it.

I think your comparison though demonstrates a downsi= de of reasoning in broad categories.=C2=A0=C2=A0 High volume nuisance traff= ic tends to burn itself out because the user that is flooding out everyone = else has to burn whatever everyone else was willing to pay in each block ev= eryone else is displaced from-- they run out of money.=C2=A0 But my stateme= nt on relay policy doesn't have much to do with volume.=C2=A0 A small consi= stent _small_ stream of transactions that aren't getting relayed but get mi= ned anyways brings the downsides of having a mining inconsistent relay poli= cy, there doesn't need to be a flood. And no flood, no self limiting behavi= or in any case.

I also think your argument misse= s the mark in that there isn't a credible argument that there is/will-be an= y traffic floods that the proposed-for-removal criteria will *prevent*.=C2= =A0 Anyone who wants to stuff data into outputs can already stuff an unlimi= ted amount, there are parties right now who are currently doing so.=C2=A0 M= oreover, there is no credible way to stop them from doing so (because you c= an't distinguish arbitrary data from addresses, essentially).=C2=A0=C2=A0 H= owever, if they use OP_RETURN instead it will prevent the data from going i= nto the UTXO set.=C2=A0 Maybe they will maybe they won't.=C2=A0 But countin= g this proposal with concerns about 'spam' doesn't get us anywhere because = removing the restriction doesn't change the current situation with respect = to 'spam' however you define it.

It doesn't real= ly matter how dire spam is when discussing a proposal that doesn't meaningf= ully *change* the situation around it, except perhaps in giving a lever to = convert some more harmful traffic into less harmful traffic.=C2=A0 If it di= d then sure the harms of the spam would be a relevant consideration.
<= div>
> People are pre-emptively making accomodation for = a startup with a whitepaper

I can't speak for ot= hers but I didn't follow any links related to citrea or any other startup i= n the thread, I don't think it's relevant.=C2=A0 I have been complaining ab= out standardizes rules screwing up block reconstruction and direct to miner= relationships to bypass relay rules for several years.=C2=A0 My impression= is that random startup whatever carries precisely zero weight in minds of = the vast majority of the commenters in favor of eliminating the restriction= .

--
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/f19214a4-6a89-4a2f-a729-560d244573bfn%40googlegroups.com.
------=_Part_87679_538317059.1746204185781-- ------=_Part_87678_303325306.1746204185781--