Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts

From: Chris Guida <[email-masked]>
Date: Thu, 25 Sep 2025 11:52:02 -0600

Hi Greg -

I think it's worth pointing out that "just update configs instead of having
to update software" is exactly what this BIP is proposing, and it takes
this idea a step further by giving users the ability to update their filter
software without having to update their bitcoin node software.

For miners wanting to add customizations, a modular system like the one in
the BIP proposal is clearly a better experience than having to edit
hardcoded filters in bitcoind.

You seem to be arguing that miners should be able to change their local
policies but that non-mining nodes should have to update their policies to
match what miners are using, is that correct?

I don't see a problem with letting users relay (or refuse to relay)
whatever transactions they like. If a transaction format is not commonly
filtered, it will most likely get confirmed. Conversely, if a supermajority
of nodes filters it, it will probably not be confirmed. I very much doubt
that a supermajority of nodes would agree to filter something harmless. But
even if they do, there is always direct miner submission (additional work
is required to support small miners), so censorship is very unlikely.

As for your comments on "distributed authoritarianism"... it just seems
like you're saying "everyone might agree to do something core devs don't
want them to do, so we can't allow that". But perhaps I misunderstood?

Anyway, forcing users to relay transactions they consider abusive if they
want to relay any transactions at all does not seem in keeping with
bitcoin's ethos, not to mention that it obviously would never work.

Best regards,

--Chris Guida

On Wed, Sep 24, 2025 at 4:50 PM Greg Maxwell <[email-masked]> wrote:

> So that when the "consistent state" changes as a result of some issue you
> can update configs instead of having to update software-- which has
> considerable more costs and risks, especially if you're carrying local
> customizations as many miners do.
>
>
> On Wed, Sep 24, 2025 at 8:47 PM Aiden McClelland <[email-masked]> wrote:
>
>> If mempool consistency across the network is all that is important, why
>> allow any configuration of mempool relay policies at all?
>>
>> On Wednesday, September 24, 2025 at 12:47:28 PM UTC-6 Greg Maxwell 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 <[email-masked]>
>>> 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 [email-masked].
>>>> To view this discussion visit
>>>> https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0-6c68c6554f56n%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0-6c68c6554f56n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>> --
>> 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 [email-masked].
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/de4dae19-86f4-4d7a-a895-b48664babbfcn%40googlegroups.com
>> <https://groups.google.com/d/msgid/bitcoindev/de4dae19-86f4-4d7a-a895-b48664babbfcn%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
> --
> 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 [email-masked].
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAANnUxBTRzE1PLe9oJU_ukmp3a_y799W_7Ez4rOUOYPhdu26A%40mail.gmail.com.