summaryrefslogtreecommitdiff
path: root/48/dc00931480a16400ec94709250e66e4bdbd6e4
blob: 16f8c80e2b52950909a3f471eeba9c36f3c7fbf7 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
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 <bitcoindev+bncBCJNLJPWXAIBB6FQ2TAAMGQEV2DR47Y@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <gmaxwell@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <f19214a4-6a89-4a2f-a729-560d244573bfn@googlegroups.com>
In-Reply-To: <s0wjN-XWg2inZbTjDilS4QsIddAa6sP7Zo7xp2XxcheO1d21g-7Jy_-okj96LPEBSAV1BtoEnrIKzgZLi06c1aka0kvFiR3l0YqxYxuTHRQ=@pm.me>
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <IpyzvdqFhM_40OKYdilNrHU9u_cIx7BKlYKBUgTGPW6idPAItRiza5tq8B1jEs141ypieLGkR2UMRIxg0qdxBMl6DQ3UKaQsID0gBjWLXtY=@protonmail.com>
 <68cdce0e-9030-4a6b-92a4-d48d05be3e80n@googlegroups.com>
 <1B78AC90-E698-421F-AECD-32DBCDD8669A@sprovoost.nl>
 <s0wjN-XWg2inZbTjDilS4QsIddAa6sP7Zo7xp2XxcheO1d21g-7Jy_-okj96LPEBSAV1BtoEnrIKzgZLi06c1aka0kvFiR3l0YqxYxuTHRQ=@pm.me>
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: <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_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

<div><div dir=3D"auto">On Friday, May 2, 2025 at 3:28:36=E2=80=AFPM UTC nsv=
rn wrote:<br /></div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border=
-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">"Spam is annoying =
but it always runs it course if you ignore it"
<br />and=20
<br />"When relay policy shouldn't be more restrictive than what is actuall=
y being mined"
<br />
<br />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"=
.
<br /></blockquote><div><br /></div><div>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.</div=
><div><br /></div><div>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.</div><div><br /></div><div>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.</div><div><br /></div><div>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><=
div><br /></div><div>&gt; People are pre-emptively making accomodation for =
a startup with a whitepaper</div><div><br /></div><div>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=
.</div><div><br /></div></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/f19214a4-6a89-4a2f-a729-560d244573bfn%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/f19214a4-6a89-4a2f-a729-560d244573bfn%40googlegroups.com</a>.<br />

------=_Part_87679_538317059.1746204185781--

------=_Part_87678_303325306.1746204185781--