Hi Aiden -

This is a very interesting proposal! It certainly has the potential to reduce tension over mempool policy by removing decisions over mempool policy from bitcoin core's maintainers, who, if I understand correctly, are not very interested in being the arbiters of policy over the bitcoin network anyway.

This seems like an excellent way to let users decide which transactions they will relay and which ones they won't, which core maintainers have no control over anyway.

I'm cautiously optimistic that this proposal can help break the logjam.

Greg -

I'm somewhat confused as to your reaction here. This proposal democratizes access to filter authorship; it does not seem in any way "authoritarian" to me. On the contrary, this proposal seems less "authoritarian" than the current state of affairs, which is that the core maintainers decide all the defaults.

>If you're not doing that you might as well set blocks only.

Why is running blocksonly more beneficial than relaying some transactions and not others? Why does bitcoin core not default to blocksonly (or no filters at all) if partial filtration is undesirable?

Kind regards,

--Chris Guida

On Wed, Sep 24, 2025 at 12:47 PM Greg Maxwell <gmaxwell@gmail.com> wrote:
This appears to substantially misunderstands the purpose of the mempool broadly in the network-- it's purpose is to model what will get mined.  If you're not doing that you might as well set blocks only.  Significant discrepancies are harmful to the system and promote centralization and fail to achieve a useful purpose in any case.  What marginal benefits might be provided do not justify building and deploying the technological infrastructure for massive censorship.

If you think this is important, I advise you to select another cryptocurrency which is compatible with such authoritarian leanings.  -- though I am unsure if any exist since it is such a transparently pointless direction.


On Wed, Sep 24, 2025 at 6:30 PM Aiden McClelland <me@drbonez.dev> wrote:
Hi all,

I'd like to share for discussion a draft BIP to allow for a modular mempool/relay policy: https://github.com/bitcoin/bips/pull/1985

I think it could potentially reduce conflict within the community around relay policy, as an alternative to running lots of different node implementations/forks when there are disagreements.

I am working on a reference implementation using Bellard's QuickJS, but it has been almost a decade since I've written C++, so it's slow going and I'm sure doesn't follow best-practices. Once it's working, it can be cleaned up.

Thanks,
Aiden McClelland

--
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/cbdab6fa-93bc-44c9-80f0-6c68c6554f56n%40googlegroups.com.

--
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/CAAS2fgRFP%2BBJUZR7h01%3D7%3DqamD5qEW6OYJikTMR%3D5RkxTCEMZg%40mail.gmail.com.

--
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/CAAANnUzf4SfgcixLuS0Uwe6pNyFWAtufzLuJrDdpnBwyU2bU7A%40mail.gmail.com.