path: root/e4/eff6b748f210556f3a1e2cd5cdab63f3e4c1f3

Delivery-date: Fri, 26 Sep 2025 15:07:16 -0700
Received: from mail-oo1-f56.google.com ([209.85.161.56])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDSKF7WH24FRBCE53TDAMGQE7AG2ECQ@googlegroups.com>)
	id 1v2Gaw-0003lB-I2
	for bitcoindev@gnusha.org; Fri, 26 Sep 2025 15:07:16 -0700
Received: by mail-oo1-f56.google.com with SMTP id 006d021491bc7-63e2ba38e78sf1815126eaf.2
        for <bitcoindev@gnusha.org>; Fri, 26 Sep 2025 15:07:14 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1758924428; cv=pass;
        d=google.com; s=arc-20240605;
        b=WgkFrPI6S+y2VBs/pudYO3iz71OeBZ2HNZi758MoyBApRIJ5xrV80E0WLjMEMzFQxa
         DIMy7UjhyujkDhQyUzKzBfuwS3VN3UHnDFdK2/Je1wrH/VTyatEXU0VrTG6C8IHRAFLf
         jqCs1dkM4V6k7LNxKCj6ac/mqtGKpe0CRRORmqamESoQIApxNq41udFlbVvRa6S+bERC
         8nrRzvAMO8YccF3F8Wl9QMiK/0nV/cPHJjFEn0YHjvDwx0z6E72gRqE4xqh8oh0Aod5W
         dW8gOxig88Z7Y91L8KwW/Hn2YIkmL9TjO9zhgLoosAOZ18GMf5mmM1inkvjvX0B/ffK+
         oNtQ==
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:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=6qSPL29jfpXBY8Lyd/p/gU/Bsf9ADNPgmn7FvLczAIM=;
        fh=3W0620jEPqa8pBq2LRBIEO0932N/w7os/+4kHDHZISo=;
        b=I5Upxkc4g1V6HIKyeoD2ORqRUhfvr54u5+y7j76zjbuzT69l4RDH93nhg33ty0ty+c
         tBj2HaHdbp7u1sLUX/4+qRbva+RRg9QXDwxqK0FfGQR30IwHhIsfrHw/R6g1313g6tHH
         pbeqNVfW6kzn+eSFAgA5q9qwwhJfmZlehc0/sEFMHrnjAvZKOKJ2GHV34DyTC9JDBl3d
         WVlrDHBPfOusnwyqenilT9nmEQspHVlWm4l4zy8wHvWe0Ql7+QGNFlIiPn6ji90Sh74p
         M0DFG16R1JlTHFKeORZYu6R04FUyoqkNIoPAiPQQ291y2At6MqOB707QQjOJeRuxXX6V
         VBow==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=ZKmge5Bv;
       spf=pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::733 as permitted sender) smtp.mailfrom=chrisguida@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1758924428; x=1759529228; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=6qSPL29jfpXBY8Lyd/p/gU/Bsf9ADNPgmn7FvLczAIM=;
        b=RUAmBZqTSRCMGWVVyx6hr6BrMqlbjJpI9+XjIHrRKOY5QckiEZ/lraDZ/g+mJcDD3f
         +WW7rFhI9nnUratGHswte9o2Mv77bt1pdf4eQ1aCkk3zS5CRnxyNqQtAzX/RBo3/RtMK
         ItPgWC6umDK9McXOZg+h5WQchbsRDyMo0jNB+EMvscpRwRvGKYRhPODA3DgqZLd7N6Bb
         pkjBqJXmbq/1h0meKLa6LPO2rphGxrXMwo2oE5WZdNKfzKSUpYDe2ZvbNZN+w2SiPuZm
         V/YEEUOTfM8W6mD2UnOA9GKo0hvExBb5ZXgfQdey17YtCKucvVcezsXoJZwXmcwCgSaE
         ASPg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1758924428; x=1759529228; 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:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=6qSPL29jfpXBY8Lyd/p/gU/Bsf9ADNPgmn7FvLczAIM=;
        b=gnRFY4g5zpWqKJ7INprHu55mLkckfXQb0cCiXQTXKA5a++QKN9j1PXOOPPIgZoQfBs
         GqafnbDx2n1yVCKOWJi/A3/osVBye7kr4Vg7oKq010QTIRtBB4gIYyyQk75U4E4R1ic6
         ziUSy4IgQgfxYms9vzhhc22PNnlBDsOxwP/MuCIoX5RFV0cy86nfUcMxQG4UiSFj31Q9
         iuarfLGnSCHbLkX9/wS9b+Eui+80jqJVjR5CBCrtOE3RFD20KBgLqwOLsqOvVXdBA+ll
         gvfACjRifvozkbTRSWfgBRUFjU97VgE3hnPb7rMjE9iYgUJAuTrM1SUZnufuHUTd4Yk7
         7P6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1758924428; x=1759529228;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=6qSPL29jfpXBY8Lyd/p/gU/Bsf9ADNPgmn7FvLczAIM=;
        b=dA1bRp/9m8+BLhAq73w5aPlpJ4qzce79mjhU2ZdVeknYIjxTVU2HTpUL/GWU9TO5zG
         h/46RPwggRn3HVtHZ7Kza3HEWU70Xmureihs6ozSJkM1i0Viu0XpKRBnFTZuTL0tDWnR
         8sghNAexQ+Psr/xZ45z7oH1F4dDVgaaS4V5DuV+TxrjgnjnGK2wagTZ5y8HF/REl2TsX
         4rNY84cF8iJIQfr3VHzBeOCip60QQWn86cdG6hzY445ytnNUsVIOsLdKXIzjk+9RGEqV
         WinY1SIJ81zSOUr4fUmynBxFFljAv30KiCXj30173aFHEhpCzWGr1bVmCyEM0XzLRNwi
         YaGQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCW7PUuM8iU+M6K9etVJMBlXMGbnWJpXx4j4ALEGTuf2uR1QD+bBC1XquFlr363pkUrswO9WQoInAgHI@gnusha.org
X-Gm-Message-State: AOJu0Yz9vlnidKO8f111H2cyFTR7DPkieGGCb4O54W1v1sTLHm4rKB6j
	A7VRlLoW+DRmmjVB5NLJYmlPfWNsJ0GjB1C+xFq8B9n6NcewQYzgz1rU
X-Google-Smtp-Source: AGHT+IH39db5dWctiFEjbNSluQT0GjBmBzYq8EiqKAiDjgbrJPBs29oWedNo1Gd/Jt60s0BZpgn6kQ==
X-Received: by 2002:a05:6871:3501:b0:365:1c38:3141 with SMTP id 586e51a60fabf-3651c383a63mr3852814fac.13.1758924428245;
        Fri, 26 Sep 2025 15:07:08 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd5tDCRs2BdURgW8Y/+uijXTLn52qK6DwTNrX22i5CVq2A=="
Received: by 2002:a05:6870:5593:b0:35a:ce0a:d0a3 with SMTP id
 586e51a60fabf-35ebc17c4a5ls2730878fac.0.-pod-prod-08-us; Fri, 26 Sep 2025
 15:07:04 -0700 (PDT)
X-Received: by 2002:a05:6808:19a0:b0:438:257d:6664 with SMTP id 5614622812f47-43f4cca1b7cmr2633320b6e.20.1758924424395;
        Fri, 26 Sep 2025 15:07:04 -0700 (PDT)
Received: by 2002:a05:620a:4628:b0:80d:5a8b:a44e with SMTP id af79cd13be357-8601b027b5fms85a;
        Fri, 26 Sep 2025 14:50:23 -0700 (PDT)
X-Received: by 2002:a05:620a:f0c:b0:853:64e7:8f2f with SMTP id af79cd13be357-85ae96afdc1mr1075928985a.77.1758923422981;
        Fri, 26 Sep 2025 14:50:22 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1758923422; cv=none;
        d=google.com; s=arc-20240605;
        b=eXeIm/F+Yc5I56jqt8Qm7yvTO2SQxX9q5RxN8BpXZJzSf5HyCtA+rhZDU067nKL2wq
         Yr/2p9ssa9QNVtATqkr8Acc9FW11MmzPYHwFi+mvpWcxjILE0Ij0dFkF4q9+/fHbV9gl
         QzTRptEJOrNt5E//xiHEIkDLtXXhGYYUkeZXHKbngEiSC48l3KzW0+DPhj9cKtE1uIrb
         JNjp7VDqF6DXlA/mbnQ4HMYYlCoPwcDRKY3nZomFWdq5IskMrVtCNjTCiQAcJ3RxP+jZ
         6t4t+jjXrxoRTP4Zj+M7G8hdqFaRN+c0Sx3NuwUu4Zvk3UGI+TpSHYJ1yIfjQfJ4iZC2
         V8NQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=mshpoQlAIDoEc8UkrWnG3PNBTiZndfqVO4J85U2fQYI=;
        fh=Pr8BdNueWheXDew+ifn/bKM5rzXGO0Gi8K1DjK18d0E=;
        b=FCZZw58CP6ogl3pUFlToCEsKxu/kG+yibijQOecYI6pdOfXLl1NmcSsvl2AkzZ+WEy
         chpxcNRBf5OcqWS9cPiy3hmpTCtoRD7J6NSgi4Zfrr1YHpHF7paWCtjbUNQqHNjlAtIV
         5TvK+ZvdYtn7Mt3VMg/p/hKC9lD3n+bxQ8ozD+svKhRoXuaZER0eF3nLozT7B306QHsI
         LNFZK9IY2Uv48Q4AoAmObWs8Wx8ePoWDQ8bvEL2E7ldMhrBwLuIn9aWShALFQFDkjxLX
         ZRiFEXLCIbHXUMg/aduhIV8GCmceeptarf/tFi/bvuSWEYWgQ3o7YiYaaeD/P6lLCXzB
         Pg+Q==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=ZKmge5Bv;
       spf=pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::733 as permitted sender) smtp.mailfrom=chrisguida@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com. [2607:f8b0:4864:20::733])
        by gmr-mx.google.com with ESMTPS id af79cd13be357-85c2c904122si22245585a.4.2025.09.26.14.50.22
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Fri, 26 Sep 2025 14:50:22 -0700 (PDT)
Received-SPF: pass (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::733 as permitted sender) client-ip=2607:f8b0:4864:20::733;
Received: by mail-qk1-x733.google.com with SMTP id af79cd13be357-856222505eeso287585285a.1
        for <bitcoindev@googlegroups.com>; Fri, 26 Sep 2025 14:50:22 -0700 (PDT)
X-Gm-Gg: ASbGncuCc7u85AVIP/6vk7nVDQCkIwoVZt8eqNPG5o3GiJG4c35ZFLeGlEO/cjCe5Yv
	ZOLR1YEHF+yf7f+/wS2vJYQJrJGAzf4GKyHddm7beOg4SjI1OlYLdvvf2qCynUt4U3TN4P5wuF5
	PYnuk4K7V42lOljCPNQRFxBZZ9BlbTz+LQ4ik+e4tOGB0Ofau9RIxdoFFiQ0232RdVGbx425/4E
	bWgJQ==
X-Received: by 2002:a05:6214:20ec:b0:786:8f81:42f with SMTP id
 6a1803df08f44-7fc37e564ffmr127175476d6.39.1758923422330; Fri, 26 Sep 2025
 14:50:22 -0700 (PDT)
MIME-Version: 1.0
References: <aNaUjR7QTqWvtZLa@mail.wpsoftware.net>
In-Reply-To: <aNaUjR7QTqWvtZLa@mail.wpsoftware.net>
From: Chris Guida <chrisguida@gmail.com>
Date: Fri, 26 Sep 2025 15:50:09 -0600
X-Gm-Features: AS18NWA7znmcOmxKrZcHqEDIP2BpAH_RtQZ27Hwky9gMCZIDHcNznZhKIbrGucE
Message-ID: <CAAANnUz3V-ciTB1+9tUz8yByhd66UpyPJTZEQFrPRMjLXZfdwQ@mail.gmail.com>
Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies
 via User-Defined Scripts]
To: Andrew Poelstra <apoelstra@wpsoftware.net>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="000000000000c673ae063fbb45ae"
X-Original-Sender: ChrisGuida@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=ZKmge5Bv;       spf=pass
 (google.com: domain of chrisguida@gmail.com designates 2607:f8b0:4864:20::733
 as permitted sender) smtp.mailfrom=chrisguida@gmail.com;       dmarc=pass
 (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;       dara=pass header.i=@googlegroups.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 (/)

--000000000000c673ae063fbb45ae
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Andrew -

>(You sent this message to me personally but it looks like it was
intended for the list. I am replying to the list, which I hope is
okay.)

Haha yes, indeed! Thank you sir =F0=9F=99=8F

I don't suppose it's worth it to try to "reply all" on my previous email to
re-attach this to the previous thread...

>Yes, it is a "new purpose" introduced almost a decade ago to allow Bitcoin
to scale without unnecessarily causing load on nodes

Yes, and my point here is that you seem to be implying that the *only*
purpose of the mempool is to make blocks propagate faster, and if that were
true, then I would agree with you that spam filters are harmful. But since
the mempool predates CBR by several years, your claim cannot be true.

>which are essential for the decentralization of the system but
uncompensated by the network.

Yes, and this is exactly the problem with data spam, and also the problem
with bitcoin core's recent shift.

The tripling of the utxoset within a couple of years has raised the minimum
cost of joining the network from ~$150 to ~$250, which is permanent damage
that may never be fixed, and worse, core devs have done nothing to prevent
it from happening again (raising the opreturn limit does nothing to prevent
brc20 or similar schemes).

Data spam pays an upfront fee, then enjoys bulletproof integrity and
availability guarantees for the rest of eternity. A finite quantity (the
upfront fee) divided by an infinite quantity (the amount of time the data
is hosted) is zero. This is why payment txs can never fairly compete with
data txs.

In addition, the fee does not actually go to the noderunners hosting the
data; it only goes to the miner who mines the tx. So data txs are an
unwanted and unnecessary burden on noderunners, which means they worsen the
cost/benefit analysis of running a node, leading to a smaller node network.

Your point about node decentralization being paramount is also why core
devs should listen to their users when they report UX difficulties. If the
experience of running a node is bad, very few will do it. (I can assure you
that the experience of running a useful merchant node is bad).

You appear to be making the claim that a merchant will have a better time
running a node if he doesn't filter transactions than if he does. The last
two years have proven this wrong. The primary culprit for making life
difficult for merchant noderunners is data spam. A merchant's node will
still work just fine even if block reconstruction times are quite long. A
Lightning implementation such as CLN will not even notice the difference
between a 1-second block propagation and a 10-second one. It just doesn't
matter.

Conversely, the spam attacks from 2023-4 have directly led to increases in
IBD times that are so extreme that the most popular merchant node hardware
(the RPi 4B 4GB) can no longer sync the chain in under a month, and the
next cheapest hardware that can do so is much more expensive. Reducing data
spam (or utxoset workarounds like libbitcoin) are what we should be
focusing on to increase participation in the node network. Pro-spam
measures like ripping out the opreturn limit only make the problem worse,
by fueling demand for shitcoining on-chain.

>If the dust filter, transaction size filters, standardness limits, etc.,
were being ignored by miners then they should be removed, yes.

Really? This should be trivial to achieve simply by launching a shitcoin
metaprotocol on top of one of these filtered tx formats. At that point node
DoS attacks would become more commonplace, no?

>Some of these exist for historical reasons and others for performance
reasons, and in the latter case there might be a movement to enforce the
old rules in consensus.

Interesting, so you're saying if someone launches a shitcoin metaprotocol
on top of txs that are DoS vectors, then that might generate support for
the Great Consensus Cleanup? Hmm...

>But if it came to "mempool policy vs miner policy" then it is in the
interest of both node operators and the network's health to change the
mempool policy.

Again, this seems like a slippery slope toward stuffing blocks full of data
garbage rather than payments. You're basically saying miners should be in
charge of bitcoin, and that non-mining nodes should have no mechanism by
which to push back on miners. Am I misunderstanding?

>People can do whatever they want. This does not mean that Bitcoin Core
should actively support "whatever people want".

Sure, but see the prior discussion, where you acknowledged that if bitcoin
core does not make running bitcoin core a good UX for its users, then very
few people will run bitcoin core nodes. So core devs need to strike a
balance between disallowing popular user behaviors and discouraging
noderunners from participating at all.

>Unfortunately, this logic is akin to "We must do something. This is
something. Therefore, we must do this."

No, that's not what I'm saying. I'm saying we can't sustainably fight spam
in consensus, and the only other enforcement mechanism besides consensus is
what we relay. It's a much weaker enforcement mechanism, but it's much
better suited to countering rapidly evolving threats than consensus, and it
has historically been very effective at countering data spam. I can think
of no other mechanisms besides consensus and standardness to bias the
bitcoin network away from data and toward payments, can you?

>You are correct that, in a world where people are willing to pay more for
data publication than for transactions, Bitcoin will be overwhelmed by data
carriers unless it were possible to block data carriers. But your proposed
solution will not achieve this. To the contrary, it will increase the cost
of running a node for anybody who does it, and increase the time it takes
for blocks to propagate across the network, both of which will have
centralizing effects.

This claim is incredibly dubious. Again, there is incontrovertible
historical data showing that data spam has been directly responsible for
significantly increasing costs on noderunners. Slower block propagation via
filters has not produced anywhere near the same effect. I'm actually not
even sure what the mechanism for such increased costs would be; can you
elaborate on how this works? Anyway no one I know has noticed an increased
cost from slow block propagation, but practically everyone with a
low-resource node noticed extreme increases in IBD times due to spam.
Filtering inscriptions as soon as they started being exploited would have
easily prevented this.

>Nodes filtering dust will, at best, prevent people from accidentally
broadcasting dust transactions. If somebody wants to do it, then they will
be able to, and any nodes that filter will be uselessly swimming against
the current.

That is not what the data show. First, the opreturn filter results in a 99%
reduction in confirmed nonstandard opreturns. Second, the dust filter
itself was implemented as a result of spam attacks, and it has been
perfectly effective since the moment it was implemented. Again, the purpose
of spam filtration is not to eliminate 100% of spam. The purpose is to
raise costs on spammers. Your email spam filter likely leaks a few spam
emails once in a while, but I guarantee your reaction is not "it doesn't
work; let's get rid of it".

>If a meaningful number of blocks are produced that are full of dust
transactions, that filter should be removed (and perhaps some movement to
consensus-ban dust transactions will appear, which is a technically much
easier thing to accomplish).

Right, but this is unlikely because of the dust filter. Likewise for
opreturn.

>Nobody is "attempting to coerce people to relay transactions", any more
than you are "attempting to coerce" Core developers by posting polite
messages on the mailing list.

Sure, that's why I said "or designing systems on the assumption that
everyone's mempools are always identical".

Best,

--Chris

On Fri, Sep 26, 2025 at 8:16=E2=80=AFAM Andrew Poelstra <apoelstra@wpsoftwa=
re.net>
wrote:

> (You sent this message to me personally but it looks like it was
> intended for the list. I am replying to the list, which I hope is
> okay.)
>
> On Thu, Sep 25, 2025 at 07:37:04PM -0600, Chris Guida wrote:
> >
> > >The purpose of the mempool is to approximate the contents of blocks,
> both
> > to help individual node operators (who would otherwise get large
> quantities
> > of "surprise transactions" with every block)
> >
> > This is a new "purpose" for the mempool which did not exist prior to 20=
16
> > when compact block relay was introduced. The original purpose for the
> > mempool is, of course, to relay unconfirmed transactions to all mining
> > nodes to increase the likelihood that transactions will be confirmed.
> >
>
> Yes, it is a "new purpose" introduced almost a decade ago to allow Bitcoi=
n
> to scale without unnecessarily causing load on nodes, which are essential
> for the decentralization of the system but uncompensated by the network.
>
> > >Any sort of filtering beyond that done by miners is contrary to this
> > purpose of the mempool. This is a technical fact.
> >
> > Again, you appear to be ignoring the existence of things like the dust
> > filter, transaction size filters, standardness limits on legacy inputs,
> > etc. And also again, you appear to be implying that the mempool is *not=
*
> > useful for relaying transactions to miners so they can be confirmed in
> > blocks (and not just so that said blocks can propagate quickly).
> >
>
> If the dust filter, transaction size filters, standardness limits, etc.,
> were being ignored by miners then they should be removed, yes. Some of
> these exist for historical reasons and others for performance reasons,
> and in the latter case there might be a movement to enforce the old
> rules in consensus. But if it came to "mempool policy vs miner policy"
> then it is in the interest of both node operators and the network's
> health to change the mempool policy.
>
> > >It has nothing to do with "bitcoin's ethos", except its ethos as a
> > consensus system, which directly contradicts your point.
> >
> > The mempool is not a consensus system, and noderunners are free to rela=
y,
> > or not relay, any transactions or blocks they like.
> >
>
> Yes, of course, but the goal of Bitcoin Core is not to let people do
> "whatever they want" on the network. Core does not support "spy node"
> operation, address indexing, or any number of things people have
> requested but are unnecessary (or harmful) to the health of the network.
>
> People can do whatever they want. This does not mean that Bitcoin Core
> should actively support "whatever people want".
>
> > Yes, in general things work more smoothly if all nodes have roughly the
> > same view of the network, but allowing miners absolute control over the
> > content of blocks in order to maximize their short-term fee revenue is =
a
> > slippery slope toward a situation in which *only* data transactions are
> > mined, rather than payments, and this would be fatal to a network that =
is
> > supposed to be a payment system.
> >
> > Since there is no permanent way to disallow all data transactions in
> > consensus, our only sustainable counterweight to this inevitable slide
> > toward more and more short-term concerns by miners (at the expense of t=
he
> > network's long-term wellbeing) is mempool policy.
> >
>
> Unfortunately, this logic is akin to "We must do something. This is
> something. Therefore, we must do this."
>
> You are correct that, in a world where people are willing to pay more
> for data publication than for transactions, Bitcoin will be overwhelmed
> by data carriers unless it were possible to block data carriers. But
> your proposed solution will not achieve this. To the contrary, it will
> increase the cost of running a node for anybody who does it, and
> increase the time it takes for blocks to propagate across the network,
> both of which will have centralizing effects.
>
> > When I say that disallowing filtering is not in keeping with bitcoin's
> > ethos, I mean that bitcoin is a voluntary network where no one can coer=
ce
> > anyone else, and everyone is assumed to be following his or her own
> > rational self-interest. Filtering dust is in the rational self-interest
> of
> > a supermajority of nodes, because the alternative is massive utxoset
> bloat
> > (and potentially node DoS attacks). Filtering data spam is no different=
;
> it
> > has a very successful track record of helping to preserve bitcoin's
> > usefulness as permissionless money, so it is beneficial to everyone.
> >
>
> Nodes filtering dust will, at best, prevent people from accidentally
> broadcasting dust transactions. If somebody wants to do it, then they
> will be able to, and any nodes that filter will be uselessly swimming
> against the current.
>
> If a meaningful number of blocks are produced that are full of dust
> transactions, that filter should be removed (and perhaps some movement
> to consensus-ban dust transactions will appear, which is a technically
> much easier thing to accomplish).
>
> > People are going to filter, because doing so is in their rational
> > self-interest, so attempting to coerce people into relaying unconfirmed
> > transactions that contain data (or designing systems on the assumption
> that
> > everyone's mempools are always identical) is doomed to fail.
> >
>
> Nobody is "attempting to coerce people to relay transactions", any more
> than
> you are "attempting to coerce" Core developers by posting polite messages
> on
> the mailing list.
>
> --
> Andrew Poelstra
> Director, Blockstream Research
> Email: apoelstra at wpsoftware.net
> Web:   https://www.wpsoftware.net/andrew
>
> The sun is always shining in space
>     -Justin Lewis-Webster
>
> --
> 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
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/aNaUjR7QTqWvtZLa%40mail.wpso=
ftware.net
> .
>

--=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/=
CAAANnUz3V-ciTB1%2B9tUz8yByhd66UpyPJTZEQFrPRMjLXZfdwQ%40mail.gmail.com.

--000000000000c673ae063fbb45ae
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi Andrew -<br></div><div><br></div><div>&gt;(You sen=
t this message to me personally but it looks like it was<br>
intended for the list. I am replying to the list, which I hope is<br>
okay.)</div><div><br></div><div>Haha yes, indeed! Thank you sir =F0=9F=99=
=8F</div><div><br></div><div>I don&#39;t suppose it&#39;s worth it to try t=
o &quot;reply all&quot; on my previous email to re-attach this to the previ=
ous thread...</div><div><br></div><div>&gt;Yes, it is a &quot;new purpose&q=
uot; introduced almost a decade ago to allow Bitcoin<br>
to scale without unnecessarily causing load on nodes</div><div><br></div><d=
iv>Yes, and my point here is that you seem to be implying that the *only* p=
urpose of the mempool is to make blocks propagate faster, and if that were =
true, then I would agree with you that spam filters are harmful. But since =
the mempool predates CBR by several years, your claim cannot be true.</div>=
<div><br></div><div>&gt;which are essential for the decentralization of the=
 system but uncompensated by the network.<div><br></div><div>Yes, and this =
is exactly the problem with data spam, and also the problem with bitcoin co=
re&#39;s recent shift.=C2=A0</div><div><br></div><div>The tripling of the u=
txoset within a couple of years has raised the minimum cost of joining the =
network from ~$150 to ~$250, which is permanent damage that may never be fi=
xed, and worse, core devs have done nothing to prevent it from happening ag=
ain (raising the opreturn limit does nothing to prevent brc20 or similar sc=
hemes).<br></div><div><br></div><div>Data spam pays an upfront fee, then en=
joys bulletproof integrity and availability guarantees for the rest of eter=
nity. A finite quantity (the upfront fee) divided by an infinite quantity (=
the amount of time the data is hosted) is zero. This is why payment txs can=
 never fairly compete with data txs.</div><div><br></div><div>In addition, =
the fee does not actually go to the noderunners hosting the data; it only g=
oes to the miner who mines the tx. So data txs are an unwanted and unnecess=
ary burden on noderunners, which means they worsen the cost/benefit analysi=
s of running a node, leading to a smaller node network.</div><div><br></div=
><div>Your point about node decentralization being paramount is also why co=
re devs should listen to their users when they report UX difficulties. If t=
he experience of running a node is bad, very few will do it. (I can assure =
you that the experience of running a useful merchant node is bad).<br></div=
><div><br></div><div>You appear to be making the claim that a merchant will=
 have a better time running a node if he doesn&#39;t filter transactions th=
an if he does. The last two years have proven this wrong. The primary culpr=
it for making life difficult for merchant noderunners is data spam. A merch=
ant&#39;s node will still work just fine even if block reconstruction times=
 are quite long. A Lightning implementation such as CLN will not even notic=
e the difference between a 1-second block propagation and a 10-second one. =
It just doesn&#39;t matter.</div><div><br></div><div>Conversely, the spam a=
ttacks from 2023-4 have directly led to increases in IBD times that are so =
extreme that the most popular merchant node hardware (the RPi 4B 4GB) can n=
o longer sync the chain in under a month, and the next cheapest hardware th=
at can do so is much more expensive. Reducing data spam (or utxoset workaro=
unds like libbitcoin) are what we should be focusing on to increase partici=
pation in the node network. Pro-spam measures like ripping out the opreturn=
 limit only make the problem worse, by fueling demand for shitcoining on-ch=
ain.</div><div><br></div><div>&gt;If the dust filter, transaction size filt=
ers, standardness limits, etc., were being ignored by miners then they shou=
ld be removed, yes.</div><div><br></div><div>Really? This should be trivial=
 to achieve simply by launching a shitcoin metaprotocol on top of one of th=
ese filtered tx formats. At that point node DoS attacks would become more c=
ommonplace, no?<br></div><div><br></div><div>&gt;Some of these exist for hi=
storical reasons and others for performance reasons, and in the latter case=
 there might be a movement to enforce the old rules in consensus.</div><div=
><br></div><div>Interesting, so you&#39;re saying if someone launches a shi=
tcoin metaprotocol on top of txs that are DoS vectors, then that might gene=
rate support for the Great Consensus Cleanup? Hmm...<br></div><div><br></di=
v><div>&gt;But if it came to &quot;mempool policy vs miner policy&quot; the=
n it is in the interest of both node operators and the network&#39;s health=
 to change the mempool policy.</div><div><br></div><div>Again, this seems l=
ike a slippery slope toward stuffing blocks full of data garbage rather tha=
n payments. You&#39;re basically saying miners should be in charge of bitco=
in, and that non-mining nodes should have no mechanism by which to push bac=
k on miners. Am I misunderstanding?<br></div><div><br></div><div>&gt;People=
 can do whatever they want. This does not mean that Bitcoin Core should act=
ively support &quot;whatever people want&quot;.</div><div><br></div><div>Su=
re, but see the prior discussion, where you acknowledged that if bitcoin co=
re does not make running bitcoin core a good UX for its users, then very fe=
w people will run bitcoin core nodes. So core devs need to strike a balance=
 between disallowing popular user behaviors and discouraging noderunners fr=
om participating at all.</div><div><br></div><div>&gt;Unfortunately, this l=
ogic is akin to &quot;We must do something. This is something. Therefore, w=
e must do this.&quot;</div><div><br></div><div>No, that&#39;s not what I&#3=
9;m saying. I&#39;m saying we can&#39;t sustainably fight spam in consensus=
, and the only other enforcement mechanism besides consensus is what we rel=
ay. It&#39;s a much weaker enforcement mechanism, but it&#39;s  much better=
 suited to countering rapidly evolving threats than consensus, and it has h=
istorically been very effective at countering data spam. I can think of no =
other mechanisms besides consensus and standardness to bias the bitcoin net=
work away from data and toward payments, can you?</div><div><br></div><div>=
&gt;You are correct that, in a world where people are willing to pay more f=
or data publication than for transactions, Bitcoin will be overwhelmed by d=
ata carriers unless it were possible to block data carriers. But your propo=
sed solution will not achieve this. To the contrary, it will increase the c=
ost of running a node for anybody who does it, and increase the time it tak=
es for blocks to propagate across the network, both of which will have cent=
ralizing effects.</div><div><br></div><div>This claim is incredibly dubious=
. Again, there is incontrovertible historical data showing that data spam h=
as been directly responsible for significantly increasing costs on noderunn=
ers. Slower block propagation via filters has not produced anywhere near th=
e same effect. I&#39;m actually not even sure what the mechanism for such i=
ncreased costs would be; can you elaborate on how this works? Anyway no one=
 I know has noticed an increased cost from slow block propagation, but prac=
tically everyone with a low-resource node noticed extreme increases in IBD =
times due to spam. Filtering inscriptions as soon as they started being exp=
loited would have easily prevented this.<br></div><div><br></div><div>&gt;N=
odes filtering dust will, at best, prevent people from accidentally broadca=
sting dust transactions. If somebody wants to do it, then they will be able=
 to, and any nodes that filter will be uselessly swimming against the curre=
nt.</div><div><br></div><div>That is not what the data show. First, the opr=
eturn filter results in a 99% reduction in confirmed nonstandard opreturns.=
 Second, the dust filter itself was implemented as a result of spam attacks=
, and it has been perfectly effective since the moment it was implemented. =
Again, the purpose of spam filtration is not to eliminate 100% of spam. The=
 purpose is to raise costs on spammers. Your email spam filter likely leaks=
 a few spam emails once in a while, but I guarantee your reaction is not &q=
uot;it doesn&#39;t work; let&#39;s get rid of it&quot;.<br></div><div><br><=
/div><div>&gt;If a meaningful number of blocks are produced that are full o=
f dust transactions, that filter should be removed (and perhaps some moveme=
nt to consensus-ban dust transactions will appear, which is a technically m=
uch easier thing to accomplish).</div></div><div><br></div><div>Right, but =
this is unlikely because of the dust filter. Likewise for opreturn.</div><d=
iv><br></div><div>&gt;Nobody is &quot;attempting to coerce people to relay =
transactions&quot;, any more than you are &quot;attempting to coerce&quot; =
Core developers by posting polite messages on the mailing list.<font color=
=3D"#888888"><br></font></div><div><br></div><div>Sure, that&#39;s why I sa=
id &quot;or designing systems on the assumption that everyone&#39;s mempool=
s are always identical&quot;.</div><div><br></div><div>Best,</div><div><br>=
</div><div>--Chris<br></div></div><br><div class=3D"gmail_quote gmail_quote=
_container"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Sep 26, 2025 at 8=
:16=E2=80=AFAM Andrew Poelstra &lt;<a href=3D"mailto:apoelstra@wpsoftware.n=
et">apoelstra@wpsoftware.net</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">(You sent this message to me personally but it =
looks like it was<br>
intended for the list. I am replying to the list, which I hope is<br>
okay.)<br>
<br>
On Thu, Sep 25, 2025 at 07:37:04PM -0600, Chris Guida wrote:<br>
&gt; <br>
&gt; &gt;The purpose of the mempool is to approximate the contents of block=
s, both<br>
&gt; to help individual node operators (who would otherwise get large quant=
ities<br>
&gt; of &quot;surprise transactions&quot; with every block)<br>
&gt; <br>
&gt; This is a new &quot;purpose&quot; for the mempool which did not exist =
prior to 2016<br>
&gt; when compact block relay was introduced. The original purpose for the<=
br>
&gt; mempool is, of course, to relay unconfirmed transactions to all mining=
<br>
&gt; nodes to increase the likelihood that transactions will be confirmed.<=
br>
&gt;<br>
<br>
Yes, it is a &quot;new purpose&quot; introduced almost a decade ago to allo=
w Bitcoin<br>
to scale without unnecessarily causing load on nodes, which are essential<b=
r>
for the decentralization of the system but uncompensated by the network.<br=
>
<br>
&gt; &gt;Any sort of filtering beyond that done by miners is contrary to th=
is<br>
&gt; purpose of the mempool. This is a technical fact.<br>
&gt; <br>
&gt; Again, you appear to be ignoring the existence of things like the dust=
<br>
&gt; filter, transaction size filters, standardness limits on legacy inputs=
,<br>
&gt; etc. And also again, you appear to be implying that the mempool is *no=
t*<br>
&gt; useful for relaying transactions to miners so they can be confirmed in=
<br>
&gt; blocks (and not just so that said blocks can propagate quickly).<br>
&gt;<br>
<br>
If the dust filter, transaction size filters, standardness limits, etc.,<br=
>
were being ignored by miners then they should be removed, yes. Some of<br>
these exist for historical reasons and others for performance reasons,<br>
and in the latter case there might be a movement to enforce the old<br>
rules in consensus. But if it came to &quot;mempool policy vs miner policy&=
quot;<br>
then it is in the interest of both node operators and the network&#39;s<br>
health to change the mempool policy.<br>
<br>
&gt; &gt;It has nothing to do with &quot;bitcoin&#39;s ethos&quot;, except =
its ethos as a<br>
&gt; consensus system, which directly contradicts your point.<br>
&gt; <br>
&gt; The mempool is not a consensus system, and noderunners are free to rel=
ay,<br>
&gt; or not relay, any transactions or blocks they like.<br>
&gt;<br>
<br>
Yes, of course, but the goal of Bitcoin Core is not to let people do<br>
&quot;whatever they want&quot; on the network. Core does not support &quot;=
spy node&quot;<br>
operation, address indexing, or any number of things people have<br>
requested but are unnecessary (or harmful) to the health of the network.<br=
>
<br>
People can do whatever they want. This does not mean that Bitcoin Core<br>
should actively support &quot;whatever people want&quot;.<br>
<br>
&gt; Yes, in general things work more smoothly if all nodes have roughly th=
e<br>
&gt; same view of the network, but allowing miners absolute control over th=
e<br>
&gt; content of blocks in order to maximize their short-term fee revenue is=
 a<br>
&gt; slippery slope toward a situation in which *only* data transactions ar=
e<br>
&gt; mined, rather than payments, and this would be fatal to a network that=
 is<br>
&gt; supposed to be a payment system.<br>
&gt;<br>
&gt; Since there is no permanent way to disallow all data transactions in<b=
r>
&gt; consensus, our only sustainable counterweight to this inevitable slide=
<br>
&gt; toward more and more short-term concerns by miners (at the expense of =
the<br>
&gt; network&#39;s long-term wellbeing) is mempool policy.<br>
&gt;<br>
<br>
Unfortunately, this logic is akin to &quot;We must do something. This is<br=
>
something. Therefore, we must do this.&quot;<br>
<br>
You are correct that, in a world where people are willing to pay more<br>
for data publication than for transactions, Bitcoin will be overwhelmed<br>
by data carriers unless it were possible to block data carriers. But<br>
your proposed solution will not achieve this. To the contrary, it will<br>
increase the cost of running a node for anybody who does it, and<br>
increase the time it takes for blocks to propagate across the network,<br>
both of which will have centralizing effects.<br>
<br>
&gt; When I say that disallowing filtering is not in keeping with bitcoin&#=
39;s<br>
&gt; ethos, I mean that bitcoin is a voluntary network where no one can coe=
rce<br>
&gt; anyone else, and everyone is assumed to be following his or her own<br=
>
&gt; rational self-interest. Filtering dust is in the rational self-interes=
t of<br>
&gt; a supermajority of nodes, because the alternative is massive utxoset b=
loat<br>
&gt; (and potentially node DoS attacks). Filtering data spam is no differen=
t; it<br>
&gt; has a very successful track record of helping to preserve bitcoin&#39;=
s<br>
&gt; usefulness as permissionless money, so it is beneficial to everyone.<b=
r>
&gt;<br>
<br>
Nodes filtering dust will, at best, prevent people from accidentally<br>
broadcasting dust transactions. If somebody wants to do it, then they<br>
will be able to, and any nodes that filter will be uselessly swimming<br>
against the current.<br>
<br>
If a meaningful number of blocks are produced that are full of dust<br>
transactions, that filter should be removed (and perhaps some movement<br>
to consensus-ban dust transactions will appear, which is a technically<br>
much easier thing to accomplish).<br>
<br>
&gt; People are going to filter, because doing so is in their rational<br>
&gt; self-interest, so attempting to coerce people into relaying unconfirme=
d<br>
&gt; transactions that contain data (or designing systems on the assumption=
 that<br>
&gt; everyone&#39;s mempools are always identical) is doomed to fail.<br>
&gt;<br>
<br>
Nobody is &quot;attempting to coerce people to relay transactions&quot;, an=
y more than<br>
you are &quot;attempting to coerce&quot; Core developers by posting polite =
messages on<br>
the mailing list.<br>
<br>
-- <br>
Andrew Poelstra<br>
Director, Blockstream Research<br>
Email: apoelstra at <a href=3D"http://wpsoftware.net" rel=3D"noreferrer" ta=
rget=3D"_blank">wpsoftware.net</a><br>
Web:=C2=A0 =C2=A0<a href=3D"https://www.wpsoftware.net/andrew" rel=3D"noref=
errer" target=3D"_blank">https://www.wpsoftware.net/andrew</a><br>
<br>
The sun is always shining in space<br>
=C2=A0 =C2=A0 -Justin Lewis-Webster<br>
<br>
-- <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%2Bunsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/aNaUjR7QTqWvtZLa%40mail.wpsoftware.net" rel=3D"noreferrer" targe=
t=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/aNaUjR7QTqWvtZLa%=
40mail.wpsoftware.net</a>.<br>
</blockquote></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/CAAANnUz3V-ciTB1%2B9tUz8yByhd66UpyPJTZEQFrPRMjLXZfdwQ%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CAAANnUz3V-ciTB1%2B9tUz8yByhd66UpyPJTZEQFrPRMjLXZfdwQ%40ma=
il.gmail.com</a>.<br />

--000000000000c673ae063fbb45ae--