path: root/42/40085623d466f4f82957b65e005e491f52d106

Delivery-date: Mon, 29 Sep 2025 08:30:31 -0700
Received: from mail-oo1-f61.google.com ([209.85.161.61])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCU2P6FJ3EBBBC6M5LDAMGQEPKEB3CY@googlegroups.com>)
	id 1v3Fpe-0005XA-7e
	for bitcoindev@gnusha.org; Mon, 29 Sep 2025 08:30:31 -0700
Received: by mail-oo1-f61.google.com with SMTP id 006d021491bc7-638e82a8166sf1858231eaf.0
        for <bitcoindev@gnusha.org>; Mon, 29 Sep 2025 08:30:30 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1759159824; cv=pass;
        d=google.com; s=arc-20240605;
        b=B9aIDtAIQvhGSotZXvnh9KHU1DnSTjJ5u94bXntXJRt4Wf76j2mwAZvzfYRwI1r3/b
         vkJNeShMxsNxKesAt9ATaMPXbyiSPPfDUJC9LgScFaKHKN0gCUnXhUvBpx3zWHbGVu/g
         AC8shwURmmrCjNTq9bdfSsrMlKYAYihit6cmrB6ytl21HthH7B0wDH6Wj7jD2kF7UEPX
         PUNvf6DyqKWtCP82gFhcJmZFxeIMJNjU7674QI1eyLP5C++lXKQvoOzi2JVhBEzdr0EF
         bft5lsqZEtfkMCnJyG9yN0FmsXLo7r5PkzHC99nuOJnLbm0LzbrJqisL8oRMkMnO9ZV6
         POcg==
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=IslVMPkop5Ux96q8AOaJxHAzxnQ/D0Olb8UWqTZAKUo=;
        fh=YIBx0yjVSvO+POjctiqBewdDDy2x3EEKcrim8saEFho=;
        b=XE1spxykw3+9smnieebb7PCbscuYZWid9OwYdt/IBex3Iutfdtbdo5TLD1anrrCcy5
         7/V0fDalcZB9BPkIUxfFQ26iRFWto/jHaqA/wzT/3S4E1G9OnF2PdbmDGzxIn67uO/t2
         V9kJqCEEalSgagU2BWpLvcvgkTihOw9BcGZ+Gz0M3gwLsScFjWsXxRfXjt0dt71gur3C
         EbAzZ5gMQ9wVEm5K8wt2LfdUBSrp8qHFbURhKldUdnsRyJKxt1TYi7TmSOGVDGmApWLb
         2xbhK3n5i56Ddf5kLvi0CR7XHVDeMBqEYWrHW85W0N3jWTAGXRy6wLKnXinQalMC7hvz
         vuzg==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=BWgcDv7m;
       spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::32d as permitted sender) smtp.mailfrom=alicexbtong@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=1759159824; x=1759764624; 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=IslVMPkop5Ux96q8AOaJxHAzxnQ/D0Olb8UWqTZAKUo=;
        b=BVpEAYhFGH0V9hf/Ty1aleCjmI0DltI547dalGN0jqI56BXF4ngQ8Pp3pSX8zwUISU
         3GmXrCjyy2d440QUpQ/IZrxXtB6KQfMTia2tBt5v9M63EVn305fgNaOM8ufZwsf+uZHD
         di0YJvInKb932/crgzCe9X7YWsNhJ9fUABG9kfwrk4SDoJDsmDy54YV0OpRlQbkmia8j
         rFT0Aue7SG7ZtObBgTdnAWW5BLKEMB38l/lkDEr3kVSUlQA4iceKCWZjh1lkfCnhZvtc
         XAalXLft5Ugz6EDDvKYaQ3hMHUQrm4sxx2ieaJydYPlnZ3gPRlQ7WHKMEqWotLEA314D
         BHZw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1759159824; x=1759764624; 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=IslVMPkop5Ux96q8AOaJxHAzxnQ/D0Olb8UWqTZAKUo=;
        b=SDXV8y5FNFffwRhL/gndGVJB1OUN05pPoUy65vlDz1NuhJv7SV/tzKP2e9hBwcYITv
         TXN4boMG73T0A8NzExkmI5Sy3mKYSWpHZInMy9nz5gfskE4ecLpgHqEXxMEsko1xmQzC
         BmOyroV3o1/Zpe7r4A+RHFu6A0/IEYvP6MDadaU9lAlnKpG/RGjgMFp1h6nHtOMU+sQ6
         wEP1u3DZ0dFTWLilNVF9Pl0p7aizZwQ8ZF7fArxnXHNd1/OzFkqQ4uxOm/62mHoo1w6U
         /jrrOzj5QYP1P60DVkskbsx8R/DE09IP8XlIs4m54zamom7rZefaWg/zm5mPTY1hf7cT
         2npw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1759159824; x=1759764624;
        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=IslVMPkop5Ux96q8AOaJxHAzxnQ/D0Olb8UWqTZAKUo=;
        b=wrjZsCQnGUtHzODoguz+9Y9beI/TsP8fRFXUH9gvTy3srrr8eUNnb+qCrSMgATw13c
         V9OG6tF/dmMEoO5LoDxu5O2nEogCXAj27FlSWRYu/U248VXdfvgkrAZ7rhrK/j9aqM6Z
         ikNhUisgR5isMXTUmMzK3J73kiNtzBRjGf8zRob8QY/2Qzl5Gzo3kPxxAr2rRP0rEy/x
         x96v+T1GIi+0Rp7reXpX17zhYha1NaF0QvuW+1hXRba0axy+tBu+dd6QeTQSMa0ooz7s
         51GaLeNynq/cJ4b2udpxxJNbBuuj2GQ+K4Ez8MmuHi6aWNGbdzTZhbh4zx7RF/JxlWru
         pfZw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCXRXuowOKDz3Xi3NtbYEjiXfRHLNwHjVhuwvPFl0swfnLgIBbtnyHoohe5d6uE+mXUiij4JqWzQze4A@gnusha.org
X-Gm-Message-State: AOJu0YyxEusQ7/vMOZr2Shveog0c0JMtfudp33BjNBa+rhhshfwXWkbe
	v+p60veJG+m3MkoC74+HqPmsHrBFpzG54ZHp9TX/V2Aa4im5vRbVWHPU
X-Google-Smtp-Source: AGHT+IG401aD+VY7wN13P/ENRcl+4X0twji9ldhG74rBzKMWzQBuBWw4EV8/derOKoVACmNrPVoL8g==
X-Received: by 2002:a05:6820:54e:b0:621:aadc:8d2b with SMTP id 006d021491bc7-63a31693cd1mr7987682eaf.2.1759159823219;
        Mon, 29 Sep 2025 08:30:23 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h="ARHlJd5gL19FZcj8DpQl+0g43Icls1ZBtCpr/0e1FBRMBTrTtA=="
Received: by 2002:a05:6820:986:b0:621:767d:3566 with SMTP id
 006d021491bc7-63a7619f092ls1688994eaf.2.-pod-prod-07-us; Mon, 29 Sep 2025
 08:30:19 -0700 (PDT)
X-Received: by 2002:a05:6808:a541:20b0:43f:51f9:f1d3 with SMTP id 5614622812f47-43f51f9f5ffmr6706428b6e.12.1759159819479;
        Mon, 29 Sep 2025 08:30:19 -0700 (PDT)
Received: by 2002:a05:620a:8c0d:b0:851:28d8:13e with SMTP id af79cd13be357-85b8b290704ms85a;
        Mon, 29 Sep 2025 06:41:46 -0700 (PDT)
X-Received: by 2002:a05:6214:d8e:b0:81c:96cc:f7ec with SMTP id 6a1803df08f44-81c96cd0a1amr163280856d6.12.1759153305259;
        Mon, 29 Sep 2025 06:41:45 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1759153305; cv=none;
        d=google.com; s=arc-20240605;
        b=N2rv9TYO3xmtc0IHmQA4poaTXXiEssBnhQ/AVOvjakyqSqtwMIk29kmNQNacNOg1gh
         BURPr7U/F9RdHuDTUN50GD5l2LF9AWZ+iPbS1PDnKhEgXWsQ8nKGBMnC/mIgbhk1OLGp
         MxgfopgmhW6AEfTp8b5jFC8ZMsDZ+8tF6cxaqbU7gqCCbJH+AP0abdJfYLQYoQEBoI4c
         J+PUYRMje3IkLfDIRV+IUT41eiChsE1OKZf+J2Ep1930oBf5t7RRlhQE4/IpioSPg6lh
         Lx41QooPz/Wd1GWz9y6B5y993Bd6fgU/W1N+A0fIEbgNBtXKzuoWVGbhZaYthLeiGymj
         6R7Q==
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=ltYm+SCdTpH3wlF2juQBNfIO6GsoktnvHIt9b2pV83c=;
        fh=Pr8BdNueWheXDew+ifn/bKM5rzXGO0Gi8K1DjK18d0E=;
        b=URHUdMNrLbLYg+D2yj937gsjkCbiGgTY1C+1462rkdyQZlWZt/WCIUtSe/3xcoMqkX
         2j7eZmBbWNUgFl0iaZ0vTjjXjXbwuVDVk48yBfba03M8cBA+lsTnSwfwba3ji2kOhjEj
         F/mmOEWqwi/mJ4XEfM4flb2EGqE8d7MDsboEXFKRKmCk261yu9e2gyWuFFLBi8uN1eRp
         Z2CNzLW8BPy+MXsNhHz8niiVuEdwHlSZcZ0f7wDSOm7ubn9gsYm3fzT6xI7AHm1017XW
         MCymZzBtwF3oOPzQ1u6b9mbREN8Bc2qKjuLzEao6DH2X3Wo+xvPeqgQii1B5IqzBkKb7
         A2ag==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=BWgcDv7m;
       spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::32d as permitted sender) smtp.mailfrom=alicexbtong@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com;
       dara=pass header.i=@googlegroups.com
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com. [2607:f8b0:4864:20::32d])
        by gmr-mx.google.com with ESMTPS id 6a1803df08f44-801378f04fdsi4264296d6.1.2025.09.29.06.41.45
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Mon, 29 Sep 2025 06:41:45 -0700 (PDT)
Received-SPF: pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::32d as permitted sender) client-ip=2607:f8b0:4864:20::32d;
Received: by mail-ot1-x32d.google.com with SMTP id 46e09a7af769-7a7b084ef77so2548949a34.2
        for <bitcoindev@googlegroups.com>; Mon, 29 Sep 2025 06:41:45 -0700 (PDT)
X-Gm-Gg: ASbGnculTDxtbbjZ4lRA0OM3QHKYQnHOgH9zfxIheVDGT/1XDgdAQaT971xn6CFObiq
	XUsLgV3DObblt5OtAPbmfLJUZ9ESqtWu1MMNxVtaAg384K/5MUEFE+Det4FPTpWO5MGy8DmbvdX
	eFfWc6CrsQdhdKT1ymfBIVWYgDykINX7xkgehWW8j0MeFOCx0LlSU3BAIO19dYNkKPoqfznVCbr
	wQA1Zk5qdEUbmn3zLGcCUhtOmfeUNmXp4d2GdiiJ6ngnw==
X-Received: by 2002:a05:6808:a541:20b0:43f:51f9:f1d3 with SMTP id
 5614622812f47-43f51f9f5ffmr6520759b6e.12.1759153304532; Mon, 29 Sep 2025
 06:41:44 -0700 (PDT)
MIME-Version: 1.0
References: <aNaUjR7QTqWvtZLa@mail.wpsoftware.net> <CAAANnUz3V-ciTB1+9tUz8yByhd66UpyPJTZEQFrPRMjLXZfdwQ@mail.gmail.com>
 <aNnIvR5Naea8pXCe@mail.wpsoftware.net>
In-Reply-To: <aNnIvR5Naea8pXCe@mail.wpsoftware.net>
From: "/dev /fd0" <alicexbtong@gmail.com>
Date: Mon, 29 Sep 2025 19:11:34 +0530
X-Gm-Features: AS18NWAbT15dXO-pAt8xuC5IK1pGfKwubFEG3UggNWKamczp_00w306q6tbUr5k
Message-ID: <CALiT-ZqxbLmRDuWMqubYDeSvawSg0xgQ8khet+w6YTJKy7aqeQ@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="000000000000d284d1063ff0cba6"
X-Original-Sender: alicexbtong@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=BWgcDv7m;       spf=pass
 (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::32d
 as permitted sender) smtp.mailfrom=alicexbtong@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 (/)

--000000000000d284d1063ff0cba6
Content-Type: text/plain; charset="UTF-8"

Hi Andrew,

> User experience is bad when every 10 minutes a block comes in and your
> laptop fan spins up and your software freezes because your computer is
> suddenly processing a whole block of transactions at once. It's bad when
> Netflix needs to pause and re-cache every 10 minutes because your
> network connection is saturated by a whole block.

> Both of these things happened to me constantly before compact blocks.

Have you tested compact blocks relay with default
`blockreconstructionextratxn` in knots v29.1?

/dev/fd0
floppy disk guy

On Mon, Sep 29, 2025, 5:37 AM Andrew Poelstra <apoelstra@wpsoftware.net>
wrote:

> On Fri, Sep 26, 2025 at 03:50:09PM -0600, Chris Guida wrote:
> >
> > >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.
> >
>
> I certainly didn't mean to imply that the only purpose of the mempool
> was to improve block propagation -- it is also useful for nodes to
> validate transactions and cache signature validity and UTXO set updates,
> something which filters are also harmful for.
>
> <snip>
>
> >
> > 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).
> >
>
> User experience is bad when every 10 minutes a block comes in and your
> laptop fan spins up and your software freezes because your computer is
> suddenly processing a whole block of transactions at once. It's bad when
> Netflix needs to pause and re-cache every 10 minutes because your
> network connection is saturated by a whole block.
>
> Both of these things happened to me constantly before compact blocks.
>
> <snip>
>
> > >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...
> >
>
> Yes, you could try something like this, though this plan has a movie-plot
> level of complexity and you are likely to fail at the first step where
> you try to meme something into existence based on some obscure technical
> thing :).
>
> > >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?
> >
>
> Non-mining nodes push back on miners by validating transactions (and
> their ability to do so is constrained by resource usage, which filtering
> increases). This prevents miners from processing tranasctions that
> violate the rules of the network.
>
> But nodes have no ability to constrain miners' behavior if that behavior
> is within the rules of the network -- except by coordinating to execute
> a fork to change the consensus rules.
>
> <snip>
>
> > 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".
> >
>
> Your "99%" number is silly. I could produce a hundred billion
> transactions that violate some policy rule, send them to my local node
> which will reject them, and then claim that the policy rule was
> 99.9999999% effective at filtering out such transactions. My point is
> that there's no meaningful way to count "transactions that exist but are
> neither propagated nor in blocks".
>
> Mempool policy makes it inconvenient for people to use transactions that
> violate the mempool policy. It may discourage them from building
> protocols that require such transactions. But this discouragement has no
> monetary value, which means that as soon as there is any economic
> interest in producing such transactions, they will be produced and they
> will wind up in blocks. This is what we see -- and it's why we are
> talking about eliminating the data carrier filters and not about
> eliminating, say, the MINIMALIF rule on pre-segwit transactions.
>
> <snip>
>
> --
> 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/aNnIvR5Naea8pXCe%40mail.wpsoftware.net
> .
>
>

-- 
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/CALiT-ZqxbLmRDuWMqubYDeSvawSg0xgQ8khet%2Bw6YTJKy7aqeQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div dir=3D"auto">Hi Andrew,<div dir=3D"auto"><br></div><d=
iv dir=3D"auto">&gt; User experience is bad when every 10 minutes a block c=
omes in and your</div><div dir=3D"auto">&gt; laptop fan spins up and your s=
oftware freezes because your computer is</div><div dir=3D"auto">&gt; sudden=
ly processing a whole block of transactions at once. It&#39;s bad when</div=
><div dir=3D"auto">&gt; Netflix needs to pause and re-cache every 10 minute=
s because your</div><div dir=3D"auto">&gt; network connection is saturated =
by a whole block.</div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; B=
oth of these things happened to me constantly before compact blocks.</div><=
div dir=3D"auto"><br></div><div>Have you tested compact blocks relay with d=
efault `blockreconstructionextratxn` in knots v29.1?=C2=A0</div><div dir=3D=
"auto"><br></div>/dev/fd0</div><div dir=3D"auto">floppy disk guy<br><br><di=
v class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Sep 2=
9, 2025, 5:37 AM Andrew Poelstra &lt;<a href=3D"mailto:apoelstra@wpsoftware=
.net" target=3D"_blank">apoelstra@wpsoftware.net</a>&gt; wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Sep 26, 2025 at 03:=
50:09PM -0600, Chris Guida wrote:<br>
&gt; <br>
&gt; &gt;Yes, it is a &quot;new purpose&quot; introduced almost a decade ag=
o to allow Bitcoin<br>
&gt; to scale without unnecessarily causing load on nodes<br>
&gt; <br>
&gt; Yes, and my point here is that you seem to be implying that the *only*=
<br>
&gt; purpose of the mempool is to make blocks propagate faster, and if that=
 were<br>
&gt; true, then I would agree with you that spam filters are harmful. But s=
ince<br>
&gt; the mempool predates CBR by several years, your claim cannot be true.<=
br>
&gt;<br>
<br>
I certainly didn&#39;t mean to imply that the only purpose of the mempool<b=
r>
was to improve block propagation -- it is also useful for nodes to<br>
validate transactions and cache signature validity and UTXO set updates,<br=
>
something which filters are also harmful for.<br>
<br>
&lt;snip&gt;<br>
<br>
&gt;<br>
&gt; Your point about node decentralization being paramount is also why cor=
e<br>
&gt; devs should listen to their users when they report UX difficulties. If=
 the<br>
&gt; experience of running a node is bad, very few will do it. (I can assur=
e you<br>
&gt; that the experience of running a useful merchant node is bad).<br>
&gt;<br>
<br>
User experience is bad when every 10 minutes a block comes in and your<br>
laptop fan spins up and your software freezes because your computer is<br>
suddenly processing a whole block of transactions at once. It&#39;s bad whe=
n<br>
Netflix needs to pause and re-cache every 10 minutes because your<br>
network connection is saturated by a whole block.<br>
<br>
Both of these things happened to me constantly before compact blocks.<br>
<br>
&lt;snip&gt;<br>
<br>
&gt; &gt;If the dust filter, transaction size filters, standardness limits,=
 etc.,<br>
&gt; were being ignored by miners then they should be removed, yes.<br>
&gt; <br>
&gt; Really? This should be trivial to achieve simply by launching a shitco=
in<br>
&gt; metaprotocol on top of one of these filtered tx formats. At that point=
 node<br>
&gt; DoS attacks would become more commonplace, no?<br>
&gt; <br>
&gt; &gt;Some of these exist for historical reasons and others for performa=
nce<br>
&gt; reasons, and in the latter case there might be a movement to enforce t=
he<br>
&gt; old rules in consensus.<br>
&gt; <br>
&gt; Interesting, so you&#39;re saying if someone launches a shitcoin metap=
rotocol<br>
&gt; on top of txs that are DoS vectors, then that might generate support f=
or<br>
&gt; the Great Consensus Cleanup? Hmm...<br>
&gt;<br>
<br>
Yes, you could try something like this, though this plan has a movie-plot<b=
r>
level of complexity and you are likely to fail at the first step where<br>
you try to meme something into existence based on some obscure technical<br=
>
thing :).<br>
<br>
&gt; &gt;But if it came to &quot;mempool policy vs miner policy&quot; then =
it is in the<br>
&gt; interest of both node operators and the network&#39;s health to change=
 the<br>
&gt; mempool policy.<br>
&gt; <br>
&gt; Again, this seems like a slippery slope toward stuffing blocks full of=
 data<br>
&gt; garbage rather than payments. You&#39;re basically saying miners shoul=
d be in<br>
&gt; charge of bitcoin, and that non-mining nodes should have no mechanism =
by<br>
&gt; which to push back on miners. Am I misunderstanding?<br>
&gt;<br>
<br>
Non-mining nodes push back on miners by validating transactions (and<br>
their ability to do so is constrained by resource usage, which filtering<br=
>
increases). This prevents miners from processing tranasctions that<br>
violate the rules of the network.<br>
<br>
But nodes have no ability to constrain miners&#39; behavior if that behavio=
r<br>
is within the rules of the network -- except by coordinating to execute<br>
a fork to change the consensus rules.<br>
<br>
&lt;snip&gt; <br>
<br>
&gt; That is not what the data show. First, the opreturn filter results in =
a 99%<br>
&gt; reduction in confirmed nonstandard opreturns. Second, the dust filter<=
br>
&gt; itself was implemented as a result of spam attacks, and it has been<br=
>
&gt; perfectly effective since the moment it was implemented. Again, the pu=
rpose<br>
&gt; of spam filtration is not to eliminate 100% of spam. The purpose is to=
<br>
&gt; raise costs on spammers. Your email spam filter likely leaks a few spa=
m<br>
&gt; emails once in a while, but I guarantee your reaction is not &quot;it =
doesn&#39;t<br>
&gt; work; let&#39;s get rid of it&quot;.<br>
&gt;<br>
<br>
Your &quot;99%&quot; number is silly. I could produce a hundred billion<br>
transactions that violate some policy rule, send them to my local node<br>
which will reject them, and then claim that the policy rule was<br>
99.9999999% effective at filtering out such transactions. My point is<br>
that there&#39;s no meaningful way to count &quot;transactions that exist b=
ut are<br>
neither propagated nor in blocks&quot;.<br>
<br>
Mempool policy makes it inconvenient for people to use transactions that<br=
>
violate the mempool policy. It may discourage them from building<br>
protocols that require such transactions. But this discouragement has no<br=
>
monetary value, which means that as soon as there is any economic<br>
interest in producing such transactions, they will be produced and they<br>
will wind up in blocks. This is what we see -- and it&#39;s why we are<br>
talking about eliminating the data carrier filters and not about<br>
eliminating, say, the MINIMALIF rule on pre-segwit transactions.<br>
<br>
&lt;snip&gt;<br>
<br>
-- <br>
Andrew Poelstra<br>
Director, Blockstream Research<br>
Email: apoelstra at <a href=3D"http://wpsoftware.net" rel=3D"noreferrer nor=
eferrer" target=3D"_blank">wpsoftware.net</a><br>
Web:=C2=A0 =C2=A0<a href=3D"https://www.wpsoftware.net/andrew" rel=3D"noref=
errer noreferrer" target=3D"_blank">https://www.wpsoftware.net/andrew</a><b=
r>
<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" rel=3D=
"noreferrer" target=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.=
<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/aNnIvR5Naea8pXCe%40mail.wpsoftware.net" rel=3D"noreferrer norefe=
rrer" target=3D"_blank">https://groups.google.com/d/msgid/bitcoindev/aNnIvR=
5Naea8pXCe%40mail.wpsoftware.net</a>.<br><br>
</blockquote></div></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/CALiT-ZqxbLmRDuWMqubYDeSvawSg0xgQ8khet%2Bw6YTJKy7aqeQ%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CALiT-ZqxbLmRDuWMqubYDeSvawSg0xgQ8khet%2Bw6YTJKy7aqeQ%40ma=
il.gmail.com</a>.<br />

--000000000000d284d1063ff0cba6--