* [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
@ 2025-09-24 18:18 Aiden McClelland
2025-09-24 18:46 ` Greg Maxwell
0 siblings, 1 reply; 6+ messages in thread
From: Aiden McClelland @ 2025-09-24 18:18 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 971 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 1411 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-24 18:18 [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts Aiden McClelland
@ 2025-09-24 18:46 ` Greg Maxwell
2025-09-24 18:54 ` Aiden McClelland
2025-09-24 19:16 ` Chris Guida
0 siblings, 2 replies; 6+ messages in thread
From: Greg Maxwell @ 2025-09-24 18:46 UTC (permalink / raw)
To: me; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 2368 bytes --]
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
> <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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRFP%2BBJUZR7h01%3D7%3DqamD5qEW6OYJikTMR%3D5RkxTCEMZg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 3288 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-24 18:46 ` Greg Maxwell
@ 2025-09-24 18:54 ` Aiden McClelland
2025-09-24 22:49 ` Greg Maxwell
2025-09-24 19:16 ` Chris Guida
1 sibling, 1 reply; 6+ messages in thread
From: Aiden McClelland @ 2025-09-24 18:54 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 2638 bytes --]
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 <m...@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+...@googlegroups•com.
>> 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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/de4dae19-86f4-4d7a-a895-b48664babbfcn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 4354 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-24 18:46 ` Greg Maxwell
2025-09-24 18:54 ` Aiden McClelland
@ 2025-09-24 19:16 ` Chris Guida
2025-09-24 20:01 ` Greg Maxwell
1 sibling, 1 reply; 6+ messages in thread
From: Chris Guida @ 2025-09-24 19:16 UTC (permalink / raw)
To: Greg Maxwell; +Cc: me, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 4280 bytes --]
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
>> <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 bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRFP%2BBJUZR7h01%3D7%3DqamD5qEW6OYJikTMR%3D5RkxTCEMZg%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRFP%2BBJUZR7h01%3D7%3DqamD5qEW6OYJikTMR%3D5RkxTCEMZg%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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAANnUzf4SfgcixLuS0Uwe6pNyFWAtufzLuJrDdpnBwyU2bU7A%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5799 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-24 19:16 ` Chris Guida
@ 2025-09-24 20:01 ` Greg Maxwell
0 siblings, 0 replies; 6+ messages in thread
From: Greg Maxwell @ 2025-09-24 20:01 UTC (permalink / raw)
To: Chris Guida; +Cc: me, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 7607 bytes --]
Because if you have a need to regulate traffic through your node there is
one, simple, perfectly effective way-- blocksonly. Any other way is
ineffective (dramatically so if you wish to reduce traffic, as filtering
generally doesn't) and has collateral damage potential.
From the discussion in public the motivation to do otherwise is an attempt
to regulate the conduct of third parties. This is
fundamentally authoritarian, it would still be authoritarian even if
implemented in a distributed way. E.g. if a theocratic populist movement
acted to prohibit sex for any purpose except reproduction (as advocated by
the most prominent filter propents) such as by public stonings of people
caught fornicating it would be just as authoritarian as if established by a
dictator. In my view the fundamental nature of authoritarianism is people
who believe they know better to such an extent that they actively
interfere with the consensual conduct of third parties. Historically most
authoritarianism has taken centralized forms, but this is partially just an
implementation detail similar to how cultures have adopted representative
democracy over direct democracy. Centralized authoritarianism is itself
normally via a group like a state government, but just one with restricted
membership. Technology can enable distributed authoritarianism like the
cancel culture of filter proponents.
More importantly, I disagree that there is any meaningful democratization
here-- to have any significant effects on the behavior of third parties,
some external mechanism must coordinate the content of filters. Were this
not the case, you could simply say "my filtering node software exists and
is available, problem solved!" -- but you're not doing that, because to
have any effect (to the limited extent that you can) you essentially need
to convince everyone or at least most people to apply the same restrictions.
The fact that a mechanism isn't proposed here just obscures the matter
because one will arise out of necessity (or, alternatively, the proposal
would just not be used to a meaningful degree). In essence the proposal
(or ones like it like the one being developed in knots) are technological
instruments of authoritarian censorship. Sure they don't have all the
components yet to complete their natural conclusion.
> which is that the core maintainers decide all the defaults
Defaults? well duh, yes any author of software decides its defaults and
that is unchanged in this proposal. Nor does it change persons own ability
to change their node behavior, as adjustments to policy are quite simple
and with the LLMs that power most filter advocates arguments even a
non-programmer can adjust them. What it does accomplish over that is the
ability to take a live feed of censorship rules from a third party.
Why doesn't core ship blocks only? Core attempts to model what will get
mined. My blocks only recommendation was for parties that prioritize
conserving resources or avoiding various unconfirmed traffic over
accurately modeling what will get mined.
On Wed, Sep 24, 2025 at 7:16 PM Chris Guida <chrisguida@gmail•com> wrote:
> 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
>>> <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 bitcoindev+unsubscribe@googlegroups•com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRFP%2BBJUZR7h01%3D7%3DqamD5qEW6OYJikTMR%3D5RkxTCEMZg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRFP%2BBJUZR7h01%3D7%3DqamD5qEW6OYJikTMR%3D5RkxTCEMZg%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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgSCORx7DHD6NCynh2rhnRbFgofLShZdqD9QwWO3fxyRWw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9547 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-24 18:54 ` Aiden McClelland
@ 2025-09-24 22:49 ` Greg Maxwell
0 siblings, 0 replies; 6+ messages in thread
From: Greg Maxwell @ 2025-09-24 22:49 UTC (permalink / raw)
To: Aiden McClelland; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 3560 bytes --]
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 <me@drbonez•dev> 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 <m...@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+...@googlegroups•com.
>>> 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 bitcoindev+unsubscribe@googlegroups•com.
> 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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 5184 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2025-09-24 22:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-09-24 18:18 [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts Aiden McClelland
2025-09-24 18:46 ` Greg Maxwell
2025-09-24 18:54 ` Aiden McClelland
2025-09-24 22:49 ` Greg Maxwell
2025-09-24 19:16 ` Chris Guida
2025-09-24 20:01 ` Greg Maxwell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox