summaryrefslogtreecommitdiff
path: root/e4/b979f464bcbf6ca5d07892cfdc2e4733d332ea
blob: 91459fc9e436211adceb594bcc6f8017206187a3 (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
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
Delivery-date: Sat, 26 Apr 2025 03:57:46 -0700
Received: from mail-oo1-f60.google.com ([209.85.161.60])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBAABBIHYWLAAMGQECHZGJWQ@googlegroups.com>)
	id 1u8dE9-0007S0-Qx
	for bitcoindev@gnusha.org; Sat, 26 Apr 2025 03:57:46 -0700
Received: by mail-oo1-f60.google.com with SMTP id 006d021491bc7-60634afce18sf2551640eaf.0
        for <bitcoindev@gnusha.org>; Sat, 26 Apr 2025 03:57:45 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1745665060; cv=pass;
        d=google.com; s=arc-20240605;
        b=eq4Rr8RXtnD/p1/yY+gOUdXgitVc8xwf+jwULFAKiLXc2iOJeAeA7sO9DmLRWsgXtk
         i4Dy0rEXCfTFdVz2IxVoljgZdQ1jD2dfycddcsuF/lQn4DDVjYJbo8m6Dojv5UuBqAHj
         fxwY3zIMalnlkbxodUbLXEVaI4yRH9cBdxJH8615eSVZpYPlOLJRjNdfX3eTojSPqJp4
         MmCB+hpZpDWIVkiJLbVKJlAzhgwfsMA+CSgR3UoHl2auJMEqKmCkW7cuRbA60Z3wspCe
         9gA+DeekkhpzfjmBgDuPJU9kKqhkbVN+OBXjwkFjrYwz2SAJAHk/sqxDqLJbNqpx1DBD
         7S1A==
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:references:to:cc:in-reply-to:date
         :subject:mime-version:message-id:from:feedback-id:sender
         :dkim-signature;
        bh=MKTCdhSKzaxD6j1Ozo4EURMtBWmlBcC+IqsL75Dzgjo=;
        fh=037MQzzdZ5/wvOfCm7ChEEVh7qlSiG6Xv86bobhkEJU=;
        b=ALRQUr94KW467RCvHw/1NPteW0saX/sAYU2N2VPZ5ZuoqSbYkKHydYllziXIwiNIuC
         QqDsgxwERmVVjoNOPy+Q+6hakhejqhOVQEuDHEMow6YRuQqLSK3/euiY5Y+WwZXAlr8F
         ORy2+b69jTS19r2fA8sEU5uIOjMF4Hhvfkx6gwxXM+wDlqaSE1I2OsrgOYPbbCbdPLfT
         3NHnzXiDhZ6IRBjIpsVlO+CO2WxCogInmqW3KrIt2a6tMHzXL9RHlvhfYIxLyF0QQAGx
         QCzyEzWTIwyEgq7N7RH2NcepvJnX/y+xVaRxzifOiW3OW+HB5U6VDSHiD8MMEJOMX/sx
         i5Iw==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@sprovoost.nl header.s=fm1 header.b=VYIgVXVa;
       dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=eb3MaZAa;
       spf=pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.152 as permitted sender) smtp.mailfrom=sjors@sprovoost.nl;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sprovoost.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1745665060; x=1746269860; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:references:to:cc:in-reply-to:date:subject
         :mime-version:message-id:from:feedback-id:sender:from:to:cc:subject
         :date:message-id:reply-to;
        bh=MKTCdhSKzaxD6j1Ozo4EURMtBWmlBcC+IqsL75Dzgjo=;
        b=LfkV70dWrz5KYjMTcNRFqCQ8Q/3vT9NPsSJjzE+wYjx0MewutiaApFhQlth0W7pYiV
         /I4KvDfSZINGtIV1kS7yvpXDNwLBJN9rzfcptkRv8Y8RdUrOx5EvDUTlRLhA0P5V4abR
         NWLBPZTp+cNgFth59L9e52iWqLKAvEHKCHhLBiMapepnvgBLHRKcBv/RxCtGzytfh0DW
         R3O7jhw0rCdA8uAN2o5gwm8lWJS+8Hlxsm4zyphcRP2If8asYLEHv98xxiQBxvxBJnGu
         oZUXkAuSp8mZmqigMi2Z/BFlTIhDbhcWj4XE9CzfVCm1+Fzf+eJk9jf1C3xSqWheW+LC
         mZkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1745665060; x=1746269860;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:references:to:cc:in-reply-to:date:subject
         :mime-version:message-id:from:feedback-id:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=MKTCdhSKzaxD6j1Ozo4EURMtBWmlBcC+IqsL75Dzgjo=;
        b=VTkpE5fe5pkGbNeagTMhmrkMPyDFCXZuhaIVI++EdSRhGSdKIQ3dvtUqPCGnv9hhXd
         rSDLs+ulAHz5BfWqt17KUHfbmgPHoMGusANOGpc9dK0U7F0cUg9FsZE2B7b9CI5b3gDR
         rP06hNgS3G+QN2Z40q8PVI2OQpteYQkfwGRyx1hY/IPNymxE946TBN37x6G+U1t0lo2C
         5wI0OB6eKYAaeGRjwiMsTnqXYI7COiW3NE4qxJ7Pyyn+ySBAGvAE/PUU45I7g6UzLHob
         QUiubjmtyNISNjKFa+dboAL2YWQQ0TELwxmIoOPPPcuvpX+kz/ePXig80/gCKxgVLugL
         GPlg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCV/AAyddx+w6aOXQqvyNzrn/tk6FMeNWDOVc0dEDtV0lsw5SixmRZBtEQ8sak4Tg7mleTwmhqov2pQ9@gnusha.org
X-Gm-Message-State: AOJu0YwuEu59xxN+MTVCCjx5TmpzlBeXUavXXZEFC3S5gHLCTOJyXznH
	fezlFxdOJtTN+sXhY1naPkpKvN+awND7ggZch9A5ITGaJPBolXe7
X-Google-Smtp-Source: AGHT+IEKzuzarxSHIdRpgh+JTOEjptSCTeJ3tXypfYamWL3pUc7M7oQM7CVZY5M8Jgh24fXoMwl2qw==
X-Received: by 2002:a05:6820:c86:b0:606:26bd:409f with SMTP id 006d021491bc7-60658f3b064mr1641073eaf.6.1745665059581;
        Sat, 26 Apr 2025 03:57:39 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=ARLLPAKH3ZvdezBhOFjbhno+QQez9iz1g6gx9OnIgGnVmmqkDQ==
Received: by 2002:a4a:a683:0:b0:603:f12f:5cf with SMTP id 006d021491bc7-606434b435dls816215eaf.1.-pod-prod-05-us;
 Sat, 26 Apr 2025 03:57:36 -0700 (PDT)
X-Received: by 2002:a05:6808:3386:b0:401:e694:3e82 with SMTP id 5614622812f47-401fd70d9f1mr1123413b6e.6.1745665056217;
        Sat, 26 Apr 2025 03:57:36 -0700 (PDT)
Received: by 2002:a05:6808:1d0:b0:3f6:a384:eb6f with SMTP id 5614622812f47-401f2e72ab9msb6e;
        Sat, 26 Apr 2025 03:53:33 -0700 (PDT)
X-Received: by 2002:a17:90b:1c07:b0:2ee:b6c5:1def with SMTP id 98e67ed59e1d1-30a01317a49mr3577568a91.8.1745664812875;
        Sat, 26 Apr 2025 03:53:32 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1745664812; cv=none;
        d=google.com; s=arc-20240605;
        b=le0pqpLW5f/+YUXh2g4nNVv6ujvcWO8DRqBU4GJ2J/vSHBv/kJpbZslOft4edOL/tD
         lMFZCdhI6pPF9Kv2sEOT0SMBBMGHLeK+dBAv8kN0dZPpYR14yvomjp3jULTi5QmL9T3C
         X00YwYnyV6r9gOIrLe+rAssrQX4yT5sc50Gnjsn+g3bnilrh2JyFgAnrCNj6sDVuqUrP
         mSMplaZC2EBRvBrv13h7vc5nKP1Mt5dSIO+r1GQKUd3CctZAHMNMScs5097UWUfd3X0r
         uQ3NBr1Dj+moVt372ptKMaJ9eU1woBWmjnXfRreH/d/E9A5IYoEsfQHkrmcx70urmfAJ
         Wzzw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=references:to:cc:in-reply-to:date:subject:mime-version:message-id
         :from:feedback-id:dkim-signature:dkim-signature;
        bh=OJWaKFJJHAs4jPFuy4kcjcY085l/u1ia9k0YPCw31XQ=;
        fh=ZXVVqYDe2aQ3zBYF9HPbjtuUn/Og0i4ghjhZ3fYEqfM=;
        b=e+1VVHR98K1sDhM6mOaS4RaUQzO5Vzck+eQ+S8Phf5ISmMKIXa0G6YMP5uUGEKyVgt
         sV/n3oUpgRUsuqB/yTtCi8oCLBa7zqoUHMY6+id5vr2O+xLT3h68C+YPoMG46cGsxduo
         TjNAsjhI3k1I/wlSotq1wyy9eVW0Tu/oShBhyuERr2ixCn1/t/R4NzLzijTn+t5/3d6t
         fFysjfXLH77OgnQSgSNS6bBylfRQpR2DMTglZ9rwAIQdjho0YKT1542Ld+N4MZDM6P4t
         pyLsRrae/TJSYK6AHv3H+gMYyTg+ZeeYpDO1oiK6S4XKE8xMt3KLPw/N+nbXGZipJgt6
         XJ6g==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@sprovoost.nl header.s=fm1 header.b=VYIgVXVa;
       dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=eb3MaZAa;
       spf=pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.152 as permitted sender) smtp.mailfrom=sjors@sprovoost.nl;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sprovoost.nl
Received: from fhigh-a1-smtp.messagingengine.com (fhigh-a1-smtp.messagingengine.com. [103.168.172.152])
        by gmr-mx.google.com with ESMTPS id 98e67ed59e1d1-309ef037e60si46900a91.1.2025.04.26.03.53.32
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sat, 26 Apr 2025 03:53:32 -0700 (PDT)
Received-SPF: pass (google.com: domain of sjors@sprovoost.nl designates 103.168.172.152 as permitted sender) client-ip=103.168.172.152;
Received: from phl-compute-01.internal (phl-compute-01.phl.internal [10.202.2.41])
	by mailfhigh.phl.internal (Postfix) with ESMTP id 82783114021F;
	Sat, 26 Apr 2025 06:53:31 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
  by phl-compute-01.internal (MEProxy); Sat, 26 Apr 2025 06:53:31 -0400
X-ME-Sender: <xms:K7sMaHNGIA8rtS_VzJLdlh9E8Pjxiq9tbO9qxAaLYGm_UYTLHoC5bQ>
    <xme:K7sMaB9tA2TV1_mm1Tu2YzOaeSOUsKUvYoFsoaBA3a81VXD2vjv-w6VM-EijUBEPr
    -fRFIn1qYFo7zBFdQ>
X-ME-Received: <xmr:K7sMaGSocxt4kHpUZ-y05ehqO8HQA7lkK5bNngxASmvPWOr2-RW5psuHnKEuycCRZsJj>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvheehtdduucetufdoteggodetrf
    dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggv
    pdfurfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpih
    gvnhhtshculddquddttddmnecujfgurhephffktgggufffjgevvfhfofesrgdtmherhhdt
    vdenucfhrhhomhepufhjohhrshcurfhrohhvohhoshhtuceoshhjohhrshesshhprhhovh
    hoohhsthdrnhhlqeenucggtffrrghtthgvrhhnpefgtdeuffekvdfgfeeiveffvdehgedv
    ffeuffektdeltddtheehffelhfehtdffhfenucffohhmrghinhepghhithhhuhgsrdgtoh
    hmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhj
    ohhrshesshhprhhovhhoohhsthdrnhhlpdhnsggprhgtphhtthhopedvpdhmohguvgepsh
    hmthhpohhuthdprhgtphhtthhopegsihhttghoihhnuggvvhesghhoohhglhgvghhrohhu
    phhsrdgtohhmpdhrtghpthhtoheplhhukhgvsegurghshhhjrhdrohhrgh
X-ME-Proxy: <xmx:K7sMaLv2m9K5SNMM_kKi_0mXRtSBO2Cds-4AgZzOu83VysS00O629w>
    <xmx:K7sMaPfTu6ZAOEW4GuMZ3niJeTYdpdjYLL24zHARiJ3yHNRDjJMVoA>
    <xmx:K7sMaH3GA9lhxhIk8P2Uqw7jhksWA8OmHzm9L-JnQLkJlhy141mC3g>
    <xmx:K7sMaL9iyZ7YlA8-ccMOyPSDfnYjZBxoqpbDVlYCm-Ey7f8v1Ff6TQ>
    <xmx:K7sMaBiMKEHHHpma2ocHHKiCBja82YPlyT5wo1EVRO0xrysax3Ptx86e>
Feedback-ID: ie5e042df:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat,
 26 Apr 2025 06:53:30 -0400 (EDT)
From: Sjors Provoost <sjors@sprovoost.nl>
Message-Id: <CEB83B34-6C5B-469E-9914-20940F27EEC0@sprovoost.nl>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_A34EE45B-3AB4-4E6B-9646-D1B6C420B3AE"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
Subject: Re: [bitcoindev] Relax OP_RETURN standardness restrictions
Date: Sat, 26 Apr 2025 12:53:18 +0200
In-Reply-To: <03be4934-f0ff-4b58-880d-861d63a4f970@dashjr.org>
Cc: Luke Dashjr <luke@dashjr.org>
To: bitcoindev@googlegroups.com
References: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
 <03be4934-f0ff-4b58-880d-861d63a4f970@dashjr.org>
X-Mailer: Apple Mail (2.3826.500.181.1.5)
X-Original-Sender: sjors@sprovoost.nl
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@sprovoost.nl header.s=fm1 header.b=VYIgVXVa;       dkim=pass
 header.i=@messagingengine.com header.s=fm3 header.b=eb3MaZAa;       spf=pass
 (google.com: domain of sjors@sprovoost.nl designates 103.168.172.152 as
 permitted sender) smtp.mailfrom=sjors@sprovoost.nl;       dmarc=pass (p=NONE
 sp=NONE dis=NONE) header.from=sprovoost.nl
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.7 (/)


--Apple-Mail=_A34EE45B-3AB4-4E6B-9646-D1B6C420B3AE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"


Op 26 apr 2025, om 11:50 heeft Luke Dashjr <luke@dashjr.org> het volgende g=
eschreven:
> It should be needless to say, but this idea is utter insanity. Disappoint=
ing to see positive responses, and not one sensible reply calling it out ye=
t. The bugs should be fixed, not the abuse embraced. If attackers continue =
to bypass filters, we can go back to a full whitelist approach.=20
>=20
Are you proposing a whitelist of authorised public keys? Or a transaction s=
ize increase?

Your earlier proposal [0] to whitelist certain script forms is not relevant=
 here, because the Citrea white paper uses unspendable public keys to encod=
e the data that doesn't fit in OP_RETURN.

To stop that, you'd have to introduce a rule that only allows spendable pub=
lic keys to be put on chain. Afaik, the only way to do that is to require a=
 signature. That would dramatically increase the size of all output scripts=
.

And that won't fix "spam" either, because you can still grind the first N b=
its of every public key and/signature, maybe encode things in the nonce, et=
c.

The cost of that would be trivial for a bridge system. And "art" systems mi=
ghtly actually like the extra scarcity.

As for your earlier proposals (Ordisrespector, etc), they were not useful i=
n general, because they rely too heavily on having standardness rules go ag=
ainst financial incentives. Only consensus changes can work, but so far you=
 haven't proposed those. Since "spam" is a cat-and-mouse game, and consensu=
s changes take ages to design, implement and roll out, it's also not a viab=
le solution.

Increasing the OP_RETURN limit reduces harm compared to the two alternative=
s:
1. UTXO set bloating with fake public keys
2. Large scale bypassing of the (default) mempool, which leads to
   a) compact block relay failures (mempool fragmentation)
   b) centralisation

Custom-but-public relay networks like Libre Relay don't cause (2b), but (li=
kely) do cause (2a). So it's not good if Bitcoin Core default policy heavil=
y incentives such an alternative network. That's one reason why -mempoolful=
lrbf is now a default.

You're also not specifying what problem you're trying to solve. Nor what "d=
amage" is done. If blocks are too big in your opinion, then why not simply =
propose a block size decrease (again)? I would not expect meaningful suppor=
t for that either, but at least it's simple.

- Sjors=20

[0] https://github.com/bitcoin/bitcoin/issues/29187
=20

--=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/=
CEB83B34-6C5B-469E-9914-20940F27EEC0%40sprovoost.nl.

--Apple-Mail=_A34EE45B-3AB4-4E6B-9646-D1B6C420B3AE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="UTF-8"

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dus-ascii"></head><body style=3D"overflow-wrap: break-word; -webkit-nbsp-=
mode: space; line-break: after-white-space;"><div><br></div><div><div>Op 26=
 apr 2025, om 11:50 heeft Luke Dashjr &lt;luke@dashjr.org&gt; het volgende =
geschreven:</div><div><p></p></div></div><blockquote type=3D"cite"><div><di=
v><p>It should be needless to say, but this idea is utter insanity. Disappo=
inting to see positive responses, and not one sensible reply calling it out=
 yet. The bugs should be fixed, not the abuse embraced. If attackers contin=
ue to bypass filters, we can go back to a full whitelist approach.&nbsp;</p=
></div></div></blockquote><div>Are you proposing a whitelist of authorised =
public keys? Or a transaction size increase?</div><div><br></div><div><div>=
Your earlier proposal [0] to whitelist certain script forms is not relevant=
 here, because the Citrea white paper uses unspendable public keys to encod=
e the data that doesn't fit in OP_RETURN.</div></div><div><br></div><div>To=
 stop that, you'd have to introduce a rule that only allows spendable publi=
c keys to be put on chain. Afaik, the only way to do that is to require a s=
ignature. That would dramatically increase the size of all output scripts.<=
/div><div><br></div><div>And that won't fix "spam" either, because you can =
still grind the first N bits of every public key and/signature, maybe encod=
e things in the nonce, etc.</div><div><br></div><div>The cost of that would=
 be trivial for a bridge system. And "art" systems mightly actually like th=
e extra scarcity.</div><div><br></div><div>As for your earlier proposals (O=
rdisrespector, etc), they were not useful in general, because they rely too=
 heavily on having standardness rules go against financial incentives. Only=
 consensus changes can work, but so far you haven't proposed those. Since "=
spam" is a cat-and-mouse game, and consensus changes take ages to design, i=
mplement and roll out, it's also not a viable solution.</div><div><br></div=
><div>Increasing the OP_RETURN limit reduces harm compared to the two alter=
natives:</div><div>1. UTXO set bloating with fake public keys</div><div>2. =
Large scale bypassing of the (default) mempool, which leads to</div><div>&n=
bsp; &nbsp;a) compact block relay failures (mempool fragmentation)</div><di=
v>&nbsp; &nbsp;b) centralisation</div><div><br></div><div>Custom-but-public=
 relay networks like Libre Relay don't cause (2b), but (likely) do cause (2=
a). So it's not good if Bitcoin Core default policy heavily incentives such=
 an alternative network. That's one reason why -mempoolfullrbf is now a def=
ault.</div><div><br></div><div>You're also not specifying what problem you'=
re trying to solve. Nor what "damage" is done. If blocks are too big in you=
r opinion, then why not simply propose a block size decrease (again)? I wou=
ld not expect meaningful support for that either, but at least it's simple.=
</div><div><br></div><div>- Sjors&nbsp;</div><div><br></div><div>[0]&nbsp;h=
ttps://github.com/bitcoin/bitcoin/issues/29187</div><div>&nbsp;<div><br></d=
iv></div></body></html>

<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/CEB83B34-6C5B-469E-9914-20940F27EEC0%40sprovoost.nl?utm_medium=
=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoindev/=
CEB83B34-6C5B-469E-9914-20940F27EEC0%40sprovoost.nl</a>.<br />

--Apple-Mail=_A34EE45B-3AB4-4E6B-9646-D1B6C420B3AE--