* [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
` (2 more replies)
0 siblings, 3 replies; 25+ 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] 25+ 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
2025-09-25 14:33 ` Luke Dashjr
2025-09-28 1:22 ` /dev /fd0
2 siblings, 2 replies; 25+ 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] 25+ 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; 25+ 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] 25+ 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; 25+ 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] 25+ 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
2025-09-25 2:20 ` bigshiny
0 siblings, 1 reply; 25+ 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] 25+ 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
2025-09-25 9:21 ` yes_please
2025-09-25 17:52 ` Chris Guida
0 siblings, 2 replies; 25+ 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] 25+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-24 20:01 ` Greg Maxwell
@ 2025-09-25 2:20 ` bigshiny
0 siblings, 0 replies; 25+ messages in thread
From: bigshiny @ 2025-09-25 2:20 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 8412 bytes --]
I believe the proper framing of this situation is ‘distributed autonomy’
not ‘distributed authoritarianism’ - which is incredibly misleading and
completely incorrect.
Authoritarianism is about centralized imposed control.
So if an individual makes a choice — say, filtering, blocking, or setting
boundaries in a network — that’s personal autonomy, not authoritarianism.
They’re exercising their own agency, not asserting control over everyone
else.
On Wednesday, September 24, 2025 at 4:47:07 PM UTC-4 Greg Maxwell wrote:
> 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 <chris...@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 <gmax...@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 <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+...@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/c26c2e30-3a74-4afa-b6b8-209c711b8167n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 11077 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-24 22:49 ` Greg Maxwell
@ 2025-09-25 9:21 ` yes_please
2025-09-25 20:03 ` Greg Maxwell
2025-09-25 17:52 ` Chris Guida
1 sibling, 1 reply; 25+ messages in thread
From: yes_please @ 2025-09-25 9:21 UTC (permalink / raw)
To: Greg Maxwell; +Cc: Aiden McClelland, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 5935 bytes --]
Sorry Greg, could you please elaborate further on your ideas? Some are not
exactly clear:
1) Allowing node runners to configure their node as they please and refuse
to relay some txs is considered authoritarian, censorship, and an attempt
to regulate third parties conduct. On the other hand, forcing nodes to
merge towards a single shared configuration (by preventing them to block
txs) is not considered authoritarian because this imposition does not
discriminate towards any txs and is thus non-authoritarian? Did I get the
reasoning correctly here?
2) If the aim is to have a homogenous mempool state and to model what will
get mined, shouldn’t we reach this state through distributed independent
nodes who decide independently on what they prefer this homogenous state to
be? If we don’t reach this state through this distributed/independent
mechanism, then how are we to reach this state? Who gets to decide and
steer the direction so that we all converge towards this homogenous state?
One of the strongest aspects of bitcoin is the fact that no single party
can force a change/direction, and the network has to somehow reach a shared
agreement through independent decision makers who act in what manner they
think is best. The proposed BIP seems to be aligned with such a principle,
I fail to see any authoritarian aspect here.
3) I share your sentiment and the aim to have a homogenous mempool state,
but I am skeptical of the manner in which we are to achieve this according
to the ideas you have here expressed (namely not through a distributed
independent organic manner)
Respectfully, yes_please
On Thu, Sep 25, 2025 at 12:50 AM Greg Maxwell <gmaxwell@gmail•com> 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 <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
> <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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAPDT2SRyVY4rh%3DHegG%2Bkk5nnDf6qzYuRkUyxCC8iE-ydsh63ew%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 8806 bytes --]
^ permalink raw reply [flat|nested] 25+ 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-25 14:33 ` Luke Dashjr
2025-09-28 1:22 ` /dev /fd0
2 siblings, 0 replies; 25+ messages in thread
From: Luke Dashjr @ 2025-09-25 14:33 UTC (permalink / raw)
To: bitcoindev
On 9/24/25 14:18, Aiden McClelland wrote:
> 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
Javascript implementations are notoriously bad at safe sandboxing. The
most well-maintained, V8, has security vulnerabilities fixed nearly
every month.
Additionally, using the filesystem as such is a "power user" task, while
many people running nodes are (or should be) ordinary end users who
don't necessarily understand these concepts.
I think a better path forward would be some kind of simple
domain-specific language. This way it could be designed to make abuse
(eg, for censorship) difficult, have an end-user friendly interface, and
allow for transparent native optimisations (or even profile at runtime
to reorder classifiers as optimal for the fastest reject).
However, I do understand this increases the complexity significantly,
and so your concept may be "good enough" in practice, at least as an
initial proof-of-concept. But I would finish and test that POC in the
real world first, before exploring a BIP for the interface.
Luke
--
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/b5688bf9-f872-4655-ae68-8876348479e1%40dashjr.org.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-24 22:49 ` Greg Maxwell
2025-09-25 9:21 ` yes_please
@ 2025-09-25 17:52 ` Chris Guida
2025-09-25 20:46 ` Greg Maxwell
2025-09-25 23:33 ` Andrew Poelstra
1 sibling, 2 replies; 25+ messages in thread
From: Chris Guida @ 2025-09-25 17:52 UTC (permalink / raw)
To: Greg Maxwell; +Cc: Aiden McClelland, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 5953 bytes --]
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 <gmaxwell@gmail•com> 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 <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
> <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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAANnUxBTRzE1PLe9oJU_ukmp3a_y799W_7Ez4rOUOYPhdu26A%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 8161 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-25 9:21 ` yes_please
@ 2025-09-25 20:03 ` Greg Maxwell
2025-09-25 20:51 ` Aiden McClelland
0 siblings, 1 reply; 25+ messages in thread
From: Greg Maxwell @ 2025-09-25 20:03 UTC (permalink / raw)
To: yes_please; +Cc: Aiden McClelland, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 8377 bytes --]
> 1) Allowing node
Who said anything about allowing? Everyone is allowed to do whatever they
want. Drill a hole in your head if you like, not my concern. None of this
thread is about what people are allowed to do-- that's off the table. The
design and licensing of Bitcoin is such that no one gets to stop anyone
else from what they want to do anyways (which is, in fact, a big part of
the issue here). To think otherwise is to be stuck in a kind of serf
thinking where you can only do what other people allow you to do. That has
never been what Bitcoin was about.
Rather, the question is should people who care about Bitcoin spend their
time and money developing infrastructure that would be useful, even
primarily useful, for censorship. I say no. Especially because any time
spent on it is time away from anti-censorship pro-privacy tools and because
the effort spent doing so would undermine anti-censorship and pro-privacy
efforts because they would inevitably moot the efforts expected getting
into peoples business and filtering their transactions.
You don't have to agree, and you're free to do your own thing just as I'm
free to say that I think it's a bad direction. From the very beginning
Bitcoin has stood against the freedom to transact being overridden by some
admin based on their judgment call weighing principles against other
concerns, or at the behest of their superiors. So many Bitcoiner will
stand against, route around, and do what they can do to make ineffectual
the blocking of consensual transactions. It might not seem as many at the
moment, but the pro-privacy and anti-censorship 'side' doesn't have a paid
PR and influence campaign, but it also doesn't matter so much because
Bitcoin takes advantage of the nature of information being easy to spread
and hard to stifel and it doesn't that that huge an effort to route around
censorship efforts.
There are elements of anti-censorship in Bitcoin that have been so far
underdeveloped. It's unfortunate that their further development might be
forced at a time when efforts are needed on other areas. But perhaps they
wouldn't get done without a concrete motivation. Such is life.
On Thu, Sep 25, 2025 at 9:21 AM yes_please <caucasianjazz12@gmail•com>
wrote:
> Sorry Greg, could you please elaborate further on your ideas? Some are not
> exactly clear:
>
> 1) Allowing node runners to configure their node as they please and
> refuse to relay some txs is considered authoritarian, censorship, and an
> attempt to regulate third parties conduct. On the other hand, forcing nodes
> to merge towards a single shared configuration (by preventing them to block
> txs) is not considered authoritarian because this imposition does not
> discriminate towards any txs and is thus non-authoritarian? Did I get the
> reasoning correctly here?
>
> 2) If the aim is to have a homogenous mempool state and to model what
> will get mined, shouldn’t we reach this state through distributed
> independent nodes who decide independently on what they prefer this
> homogenous state to be? If we don’t reach this state through this
> distributed/independent mechanism, then how are we to reach this state? Who
> gets to decide and steer the direction so that we all converge towards this
> homogenous state? One of the strongest aspects of bitcoin is the fact that
> no single party can force a change/direction, and the network has to
> somehow reach a shared agreement through independent decision makers who
> act in what manner they think is best. The proposed BIP seems to be aligned
> with such a principle, I fail to see any authoritarian aspect here.
>
> 3) I share your sentiment and the aim to have a homogenous mempool state,
> but I am skeptical of the manner in which we are to achieve this according
> to the ideas you have here expressed (namely not through a distributed
> independent organic manner)
>
>
> Respectfully, yes_please
>
> On Thu, Sep 25, 2025 at 12:50 AM Greg Maxwell <gmaxwell@gmail•com> 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 <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
>> <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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgSmiKhmQGAEo2eSQJmen-4kT1vD7dY8UESV4dQrjXau7w%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 11857 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-25 17:52 ` Chris Guida
@ 2025-09-25 20:46 ` Greg Maxwell
2025-09-25 21:02 ` Chris Guida
2025-09-25 23:33 ` Andrew Poelstra
1 sibling, 1 reply; 25+ messages in thread
From: Greg Maxwell @ 2025-09-25 20:46 UTC (permalink / raw)
To: Chris Guida; +Cc: Aiden McClelland, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 6427 bytes --]
I'm a little confused by the tone of this reply while simultaneously you're
on twitter calling me unhinged and retweeting bizarre insults about my
posting. Pardon the bluntness, but I suspect your interactions here are
flatly insincere.
On Thu, Sep 25, 2025 at 5:52 PM Chris Guida <chrisguida@gmail•com> wrote:
> 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 <gmaxwell@gmail•com> 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 <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
>> <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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgQ8aY5ejB2e%2BmywnFcTccXmoE%3D9WOFcxqA1XEsgJVKEiQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 8819 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-25 20:03 ` Greg Maxwell
@ 2025-09-25 20:51 ` Aiden McClelland
2025-09-25 21:14 ` Greg Maxwell
0 siblings, 1 reply; 25+ messages in thread
From: Aiden McClelland @ 2025-09-25 20:51 UTC (permalink / raw)
To: Greg Maxwell; +Cc: yes_please, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 9737 bytes --]
Greg,
Let me assume for a minute, for the sake of argument, that I agree that
transaction censorship due to widespread use of transaction filters is a
bad thing (I'm not really taking a stance on that right now). It is an
irrefutable fact that a very large portion of the user base wants to filter
transactions. So many so, that you yourself are worried they will reach the
80% needed to prevent certain types of transactions from propogating.
Wouldn't it then be *worse* if these 80% of users went and ran an
alternative implementation, most likely written by it's most radical
supporters? Or even worse still, felt compelled to coordinate a UASF to
block these transactions entirely?
I at no point intended to insinuate that you or any other core contributer
be compelled to implement a proposal like this. It's up to its supporters
to do so. The real question is, are you willing to work with and compromise
with people who are looking for a solution like this? Or are you going to
force them to abandon the Core project entirely?
Best,
*Aiden McClelland*
On Thu, Sep 25, 2025, 2:03 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
> > 1) Allowing node
>
> Who said anything about allowing? Everyone is allowed to do whatever they
> want. Drill a hole in your head if you like, not my concern. None of this
> thread is about what people are allowed to do-- that's off the table. The
> design and licensing of Bitcoin is such that no one gets to stop anyone
> else from what they want to do anyways (which is, in fact, a big part of
> the issue here). To think otherwise is to be stuck in a kind of serf
> thinking where you can only do what other people allow you to do. That has
> never been what Bitcoin was about.
>
> Rather, the question is should people who care about Bitcoin spend their
> time and money developing infrastructure that would be useful, even
> primarily useful, for censorship. I say no. Especially because any time
> spent on it is time away from anti-censorship pro-privacy tools and because
> the effort spent doing so would undermine anti-censorship and pro-privacy
> efforts because they would inevitably moot the efforts expected getting
> into peoples business and filtering their transactions.
>
> You don't have to agree, and you're free to do your own thing just as I'm
> free to say that I think it's a bad direction. From the very beginning
> Bitcoin has stood against the freedom to transact being overridden by
> some admin based on their judgment call weighing principles against other
> concerns, or at the behest of their superiors. So many Bitcoiner will
> stand against, route around, and do what they can do to make ineffectual
> the blocking of consensual transactions. It might not seem as many at the
> moment, but the pro-privacy and anti-censorship 'side' doesn't have a paid
> PR and influence campaign, but it also doesn't matter so much because
> Bitcoin takes advantage of the nature of information being easy to spread
> and hard to stifel and it doesn't that that huge an effort to route around
> censorship efforts.
>
> There are elements of anti-censorship in Bitcoin that have been so far
> underdeveloped. It's unfortunate that their further development might be
> forced at a time when efforts are needed on other areas. But perhaps they
> wouldn't get done without a concrete motivation. Such is life.
>
>
>
>
>
> On Thu, Sep 25, 2025 at 9:21 AM yes_please <caucasianjazz12@gmail•com>
> wrote:
>
>> Sorry Greg, could you please elaborate further on your ideas? Some are
>> not exactly clear:
>>
>> 1) Allowing node runners to configure their node as they please and
>> refuse to relay some txs is considered authoritarian, censorship, and an
>> attempt to regulate third parties conduct. On the other hand, forcing nodes
>> to merge towards a single shared configuration (by preventing them to block
>> txs) is not considered authoritarian because this imposition does not
>> discriminate towards any txs and is thus non-authoritarian? Did I get the
>> reasoning correctly here?
>>
>> 2) If the aim is to have a homogenous mempool state and to model what
>> will get mined, shouldn’t we reach this state through distributed
>> independent nodes who decide independently on what they prefer this
>> homogenous state to be? If we don’t reach this state through this
>> distributed/independent mechanism, then how are we to reach this state? Who
>> gets to decide and steer the direction so that we all converge towards this
>> homogenous state? One of the strongest aspects of bitcoin is the fact that
>> no single party can force a change/direction, and the network has to
>> somehow reach a shared agreement through independent decision makers who
>> act in what manner they think is best. The proposed BIP seems to be aligned
>> with such a principle, I fail to see any authoritarian aspect here.
>>
>> 3) I share your sentiment and the aim to have a homogenous mempool
>> state, but I am skeptical of the manner in which we are to achieve this
>> according to the ideas you have here expressed (namely not through a
>> distributed independent organic manner)
>>
>>
>> Respectfully, yes_please
>>
>> On Thu, Sep 25, 2025 at 12:50 AM Greg Maxwell <gmaxwell@gmail•com> 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 <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
>>> <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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAOSz24TJU-4Q76MtzL%2BoYYFpXQvrOay5XtdrR0DxVBUAFz%3D5og%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 13844 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-25 20:46 ` Greg Maxwell
@ 2025-09-25 21:02 ` Chris Guida
0 siblings, 0 replies; 25+ messages in thread
From: Chris Guida @ 2025-09-25 21:02 UTC (permalink / raw)
To: Greg Maxwell; +Cc: Aiden McClelland, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 7261 bytes --]
Hi Greg -
Yes, I imagine my emails would get filtered from this list if I were to
post my honest, unfiltered reaction to your prior statements on this
thread. Such things seem much better suited for twitter than the bitcoindev
ML.
No, I am not being insincere; I genuinely want to know if I'm
misunderstanding your point of view, though this current reply is not
helping clarify things.
We can take this to twitter if that is more appropriate; I did not know you
were active there. I am happy to delete/retract my posts on twitter if I
have misrepresented your position.
Kind regards,
--Chris Guida
On Thu, Sep 25, 2025 at 2:47 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
> I'm a little confused by the tone of this reply while
> simultaneously you're on twitter calling me unhinged and retweeting bizarre
> insults about my posting. Pardon the bluntness, but I suspect your
> interactions here are flatly insincere.
>
>
> On Thu, Sep 25, 2025 at 5:52 PM Chris Guida <chrisguida@gmail•com> wrote:
>
>> 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 <gmaxwell@gmail•com> 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 <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
>>> <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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAANnUx%3DWrmpm4coJOE6EPaO6sSx3OtTGcKyONn5VHXPhJLnbQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 9941 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-25 20:51 ` Aiden McClelland
@ 2025-09-25 21:14 ` Greg Maxwell
2025-09-25 21:25 ` Aiden McClelland
0 siblings, 1 reply; 25+ messages in thread
From: Greg Maxwell @ 2025-09-25 21:14 UTC (permalink / raw)
To: Aiden McClelland; +Cc: yes_please, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 13717 bytes --]
I am not a core developer. I have not been for some eight years now.
> that you yourself are worried they will reach the 80% needed
I have no idea what you're referring to there. If lots of people run nodes
that screw up propagation they'll be routed around. I developed the
technical concepts required to get nearly 100% tx coverage even if almost
all nodes are blocking them quite a few years ago (
https://arxiv.org/pdf/1905.10518 ), but deployment of the implementation
has gone slow due to other factors (you know, such as the most
experienced developers being hit with billions of dollars in lawsuits as a
cost for their support of Bitcoin)... I expect if censoring actually
becomes widespread that technological improvements which further moot it
will be developed.
These are just vulnerabilities that should be closed anyways-- after all
anyone at any time can just spin up any number of "nodes" that behave in
arbitrary ways, at ant time. It's been a lower priority because there are
other countermeasures (addnode-a-friend, manually setbanning bad peers,
etc.) and aforementione distractions.
> censorship due to widespread use of transaction filters is a bad thing
(I'm not really taking a stance on that right now).
I would point you to the history of discussion on Bitcoin starting back
with Satoshi's earliest announcements, and perhaps to help you understand
that if you want that what you want isn't bitcoin. If after consideration
you don't think censorship wouldn't be very bad, then really you and I have
nothing further to discuss.
> are you willing to work with and compromise with people who are looking
for a solution like this? Or are you going to force them to abandon the
Core project entirely
I don't really think there is any space to compromise with people who think
it's okay to add censorship to Bitcoin-- I mean sure whatever exact relay
policy there is there is plenty of tradeoffs but from the start of this new
filter debate the filter proponents have immediately come out with vile
insults accusing developers of promoting child sexual abuse and shitcoins
and what not---- that isn't some attempt to navigate a technical/political
trademark, it's an effort to villify and destory the opposition. And
unambiguously so as luke has said outright that his goal is to destroy
Bitcoin Core. So what's the compromise there?
> Or even worse still, felt compelled to coordinate a UASF to block these
transactions entirely?
I very much think people should do that-- they should actually make some
consensus rules for their filters to fork off and we can see what the
market thinks. -- And also even if the market prefers censored Bitcoin,
that's also fine with me, in the sense in my view Bitcoin was created to be
money as largely free from human judgement as possible. When it was
created most of the world was doing something else and didn't know they
needed freedom money. If it's still the case that most of the world
doesn't want freedom money that would be no shock. They should be free to
have what they want and people who want freedom money should be free to
have what they want. I got into bitcoin before it was worth practically
anything because of the freedom it provides, and I think that's paramount.
Perhaps you should consider why they *don't* do that? I'd say it's because
(1) it won't work, and (2) it's not actually what the world wants-- an
outspoken influence campaign is not necessarily all that reflective of much
of anything. Particularly given how inaccurate and emotionally pandering
the filter advocacy has been. But, hey, I've been wrong before.
On Thu, Sep 25, 2025 at 8:51 PM Aiden McClelland <me@drbonez•dev> wrote:
> Greg,
>
> Let me assume for a minute, for the sake of argument, that I agree that
> transaction censorship due to widespread use of transaction filters is a
> bad thing (I'm not really taking a stance on that right now). It is an
> irrefutable fact that a very large portion of the user base wants to filter
> transactions. So many so, that you yourself are worried they will reach the
> 80% needed to prevent certain types of transactions from propogating.
> Wouldn't it then be *worse* if these 80% of users went and ran an
> alternative implementation, most likely written by it's most radical
> supporters? Or even worse still, felt compelled to coordinate a UASF to
> block these transactions entirely?
>
> I at no point intended to insinuate that you or any other core contributer
> be compelled to implement a proposal like this. It's up to its supporters
> to do so. The real question is, are you willing to work with and compromise
> with people who are looking for a solution like this? Or are you going to
> force them to abandon the Core project entirely?
>
> Best,
> *Aiden McClelland*
>
> On Thu, Sep 25, 2025, 2:03 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
>
>> > 1) Allowing node
>>
>> Who said anything about allowing? Everyone is allowed to do whatever
>> they want. Drill a hole in your head if you like, not my concern. None of
>> this thread is about what people are allowed to do-- that's off the table.
>> The design and licensing of Bitcoin is such that no one gets to stop anyone
>> else from what they want to do anyways (which is, in fact, a big part of
>> the issue here). To think otherwise is to be stuck in a kind of serf
>> thinking where you can only do what other people allow you to do. That has
>> never been what Bitcoin was about.
>>
>> Rather, the question is should people who care about Bitcoin spend their
>> time and money developing infrastructure that would be useful, even
>> primarily useful, for censorship. I say no. Especially because any time
>> spent on it is time away from anti-censorship pro-privacy tools and because
>> the effort spent doing so would undermine anti-censorship and pro-privacy
>> efforts because they would inevitably moot the efforts expected getting
>> into peoples business and filtering their transactions.
>>
>> You don't have to agree, and you're free to do your own thing just as I'm
>> free to say that I think it's a bad direction. From the very beginning
>> Bitcoin has stood against the freedom to transact being overridden by
>> some admin based on their judgment call weighing principles against other
>> concerns, or at the behest of their superiors. So many Bitcoiner will
>> stand against, route around, and do what they can do to make ineffectual
>> the blocking of consensual transactions. It might not seem as many at the
>> moment, but the pro-privacy and anti-censorship 'side' doesn't have a paid
>> PR and influence campaign, but it also doesn't matter so much because
>> Bitcoin takes advantage of the nature of information being easy to spread
>> and hard to stifel and it doesn't that that huge an effort to route around
>> censorship efforts.
>>
>> There are elements of anti-censorship in Bitcoin that have been so far
>> underdeveloped. It's unfortunate that their further development might be
>> forced at a time when efforts are needed on other areas. But perhaps they
>> wouldn't get done without a concrete motivation. Such is life.
>>
>>
>>
>>
>>
>> On Thu, Sep 25, 2025 at 9:21 AM yes_please <caucasianjazz12@gmail•com>
>> wrote:
>>
>>> Sorry Greg, could you please elaborate further on your ideas? Some are
>>> not exactly clear:
>>>
>>> 1) Allowing node runners to configure their node as they please and
>>> refuse to relay some txs is considered authoritarian, censorship, and an
>>> attempt to regulate third parties conduct. On the other hand, forcing nodes
>>> to merge towards a single shared configuration (by preventing them to block
>>> txs) is not considered authoritarian because this imposition does not
>>> discriminate towards any txs and is thus non-authoritarian? Did I get the
>>> reasoning correctly here?
>>>
>>> 2) If the aim is to have a homogenous mempool state and to model what
>>> will get mined, shouldn’t we reach this state through distributed
>>> independent nodes who decide independently on what they prefer this
>>> homogenous state to be? If we don’t reach this state through this
>>> distributed/independent mechanism, then how are we to reach this state? Who
>>> gets to decide and steer the direction so that we all converge towards this
>>> homogenous state? One of the strongest aspects of bitcoin is the fact that
>>> no single party can force a change/direction, and the network has to
>>> somehow reach a shared agreement through independent decision makers who
>>> act in what manner they think is best. The proposed BIP seems to be aligned
>>> with such a principle, I fail to see any authoritarian aspect here.
>>>
>>> 3) I share your sentiment and the aim to have a homogenous mempool
>>> state, but I am skeptical of the manner in which we are to achieve this
>>> according to the ideas you have here expressed (namely not through a
>>> distributed independent organic manner)
>>>
>>>
>>> Respectfully, yes_please
>>>
>>> On Thu, Sep 25, 2025 at 12:50 AM Greg Maxwell <gmaxwell@gmail•com>
>>> 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 <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
>>>> <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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgRGCbNNxGHbSy1Ej3Kr9EnYDa5TYrVTCsfFsMnCbjYcfQ%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 18290 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-25 21:14 ` Greg Maxwell
@ 2025-09-25 21:25 ` Aiden McClelland
2025-09-25 21:51 ` Greg Maxwell
0 siblings, 1 reply; 25+ messages in thread
From: Aiden McClelland @ 2025-09-25 21:25 UTC (permalink / raw)
To: Greg Maxwell; +Cc: yes_please, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 14537 bytes --]
>I have no idea what you're referring to there.
It's something I inferred from your primary argument that seems to be that
user-configurable filters are bad because they would cause censorship. But
it also sounds like you're saying such filters are completely ineffective
at any sort of censorship at all. I don't really understand how these two
viewpoints can coexist. What am I missing here?
Best,
*Aiden McClelland*
On Thu, Sep 25, 2025, 3:14 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
> I am not a core developer. I have not been for some eight years now.
>
> > that you yourself are worried they will reach the 80% needed
>
> I have no idea what you're referring to there. If lots of people run
> nodes that screw up propagation they'll be routed around. I developed the
> technical concepts required to get nearly 100% tx coverage even if almost
> all nodes are blocking them quite a few years ago (
> https://arxiv.org/pdf/1905.10518 ), but deployment of the implementation
> has gone slow due to other factors (you know, such as the most
> experienced developers being hit with billions of dollars in lawsuits as a
> cost for their support of Bitcoin)... I expect if censoring actually
> becomes widespread that technological improvements which further moot it
> will be developed.
>
> These are just vulnerabilities that should be closed anyways-- after all
> anyone at any time can just spin up any number of "nodes" that behave in
> arbitrary ways, at ant time. It's been a lower priority because there are
> other countermeasures (addnode-a-friend, manually setbanning bad peers,
> etc.) and aforementione distractions.
>
> > censorship due to widespread use of transaction filters is a bad thing
> (I'm not really taking a stance on that right now).
>
> I would point you to the history of discussion on Bitcoin starting back
> with Satoshi's earliest announcements, and perhaps to help you understand
> that if you want that what you want isn't bitcoin. If after consideration
> you don't think censorship wouldn't be very bad, then really you and I have
> nothing further to discuss.
>
> > are you willing to work with and compromise with people who are looking
> for a solution like this? Or are you going to force them to abandon the
> Core project entirely
>
> I don't really think there is any space to compromise with people who
> think it's okay to add censorship to Bitcoin-- I mean sure whatever exact
> relay policy there is there is plenty of tradeoffs but from the start of
> this new filter debate the filter proponents have immediately come out with
> vile insults accusing developers of promoting child sexual abuse and
> shitcoins and what not---- that isn't some attempt to navigate a
> technical/political trademark, it's an effort to villify and destory the
> opposition. And unambiguously so as luke has said outright that his goal
> is to destroy Bitcoin Core. So what's the compromise there?
>
> > Or even worse still, felt compelled to coordinate a UASF to block these
> transactions entirely?
>
> I very much think people should do that-- they should actually make some
> consensus rules for their filters to fork off and we can see what the
> market thinks. -- And also even if the market prefers censored Bitcoin,
> that's also fine with me, in the sense in my view Bitcoin was created to be
> money as largely free from human judgement as possible. When it was
> created most of the world was doing something else and didn't know they
> needed freedom money. If it's still the case that most of the world
> doesn't want freedom money that would be no shock. They should be free to
> have what they want and people who want freedom money should be free to
> have what they want. I got into bitcoin before it was worth practically
> anything because of the freedom it provides, and I think that's paramount.
>
> Perhaps you should consider why they *don't* do that? I'd say it's
> because (1) it won't work, and (2) it's not actually what the world wants--
> an outspoken influence campaign is not necessarily all that reflective of
> much of anything. Particularly given how inaccurate and emotionally
> pandering the filter advocacy has been. But, hey, I've been wrong
> before.
>
>
>
> On Thu, Sep 25, 2025 at 8:51 PM Aiden McClelland <me@drbonez•dev> wrote:
>
>> Greg,
>>
>> Let me assume for a minute, for the sake of argument, that I agree that
>> transaction censorship due to widespread use of transaction filters is a
>> bad thing (I'm not really taking a stance on that right now). It is an
>> irrefutable fact that a very large portion of the user base wants to filter
>> transactions. So many so, that you yourself are worried they will reach the
>> 80% needed to prevent certain types of transactions from propogating.
>> Wouldn't it then be *worse* if these 80% of users went and ran an
>> alternative implementation, most likely written by it's most radical
>> supporters? Or even worse still, felt compelled to coordinate a UASF to
>> block these transactions entirely?
>>
>> I at no point intended to insinuate that you or any other core
>> contributer be compelled to implement a proposal like this. It's up to its
>> supporters to do so. The real question is, are you willing to work with and
>> compromise with people who are looking for a solution like this? Or are you
>> going to force them to abandon the Core project entirely?
>>
>> Best,
>> *Aiden McClelland*
>>
>> On Thu, Sep 25, 2025, 2:03 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
>>
>>> > 1) Allowing node
>>>
>>> Who said anything about allowing? Everyone is allowed to do whatever
>>> they want. Drill a hole in your head if you like, not my concern. None of
>>> this thread is about what people are allowed to do-- that's off the table.
>>> The design and licensing of Bitcoin is such that no one gets to stop anyone
>>> else from what they want to do anyways (which is, in fact, a big part of
>>> the issue here). To think otherwise is to be stuck in a kind of serf
>>> thinking where you can only do what other people allow you to do. That has
>>> never been what Bitcoin was about.
>>>
>>> Rather, the question is should people who care about Bitcoin spend their
>>> time and money developing infrastructure that would be useful, even
>>> primarily useful, for censorship. I say no. Especially because any time
>>> spent on it is time away from anti-censorship pro-privacy tools and because
>>> the effort spent doing so would undermine anti-censorship and pro-privacy
>>> efforts because they would inevitably moot the efforts expected getting
>>> into peoples business and filtering their transactions.
>>>
>>> You don't have to agree, and you're free to do your own thing just as
>>> I'm free to say that I think it's a bad direction. From the very beginning
>>> Bitcoin has stood against the freedom to transact being overridden by
>>> some admin based on their judgment call weighing principles against other
>>> concerns, or at the behest of their superiors. So many Bitcoiner will
>>> stand against, route around, and do what they can do to make ineffectual
>>> the blocking of consensual transactions. It might not seem as many at the
>>> moment, but the pro-privacy and anti-censorship 'side' doesn't have a paid
>>> PR and influence campaign, but it also doesn't matter so much because
>>> Bitcoin takes advantage of the nature of information being easy to spread
>>> and hard to stifel and it doesn't that that huge an effort to route around
>>> censorship efforts.
>>>
>>> There are elements of anti-censorship in Bitcoin that have been so far
>>> underdeveloped. It's unfortunate that their further development might be
>>> forced at a time when efforts are needed on other areas. But perhaps they
>>> wouldn't get done without a concrete motivation. Such is life.
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Sep 25, 2025 at 9:21 AM yes_please <caucasianjazz12@gmail•com>
>>> wrote:
>>>
>>>> Sorry Greg, could you please elaborate further on your ideas? Some are
>>>> not exactly clear:
>>>>
>>>> 1) Allowing node runners to configure their node as they please and
>>>> refuse to relay some txs is considered authoritarian, censorship, and an
>>>> attempt to regulate third parties conduct. On the other hand, forcing nodes
>>>> to merge towards a single shared configuration (by preventing them to block
>>>> txs) is not considered authoritarian because this imposition does not
>>>> discriminate towards any txs and is thus non-authoritarian? Did I get the
>>>> reasoning correctly here?
>>>>
>>>> 2) If the aim is to have a homogenous mempool state and to model what
>>>> will get mined, shouldn’t we reach this state through distributed
>>>> independent nodes who decide independently on what they prefer this
>>>> homogenous state to be? If we don’t reach this state through this
>>>> distributed/independent mechanism, then how are we to reach this state? Who
>>>> gets to decide and steer the direction so that we all converge towards this
>>>> homogenous state? One of the strongest aspects of bitcoin is the fact that
>>>> no single party can force a change/direction, and the network has to
>>>> somehow reach a shared agreement through independent decision makers who
>>>> act in what manner they think is best. The proposed BIP seems to be aligned
>>>> with such a principle, I fail to see any authoritarian aspect here.
>>>>
>>>> 3) I share your sentiment and the aim to have a homogenous mempool
>>>> state, but I am skeptical of the manner in which we are to achieve this
>>>> according to the ideas you have here expressed (namely not through a
>>>> distributed independent organic manner)
>>>>
>>>>
>>>> Respectfully, yes_please
>>>>
>>>> On Thu, Sep 25, 2025 at 12:50 AM Greg Maxwell <gmaxwell@gmail•com>
>>>> 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 <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
>>>>> <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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAOSz24SdZeV%3D1PwDeXfoMgY7QbcfYkLysnGdqSWVrnRzqvHSOg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 19480 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-25 21:25 ` Aiden McClelland
@ 2025-09-25 21:51 ` Greg Maxwell
2025-09-26 2:06 ` Chris Riley
0 siblings, 1 reply; 25+ messages in thread
From: Greg Maxwell @ 2025-09-25 21:51 UTC (permalink / raw)
To: Aiden McClelland; +Cc: yes_please, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 17720 bytes --]
"There are levels of survival we are prepared to accept."
Black and white thinking is not very helpful here particularly because the
goals of pro-filtering and anti-censorship aren't exact opposites.
A widely censored world would greatly degrade the value of
Bitcoin, particularly if the censors managed to enlist significant miners.
It would be routed around at great cost, and with much less freedom
provided for the world. But just like people continue to buy racy
magazines or other completely lawful targets of operation chokepoint with
USD, people would still route around Bitcoin censorship. But why even use
Bitcoin if it's in a similar space of your transactions being capriciously
blocks, your funds frozen, etc. as exists with legacy infrastructure?
But the irony is that the traffic that people most desperately want to stop
would be among the least impeded-- already today the spam traffic exists at
all because it's well funded (or really existed a year ago, we are long
past the huge spam floods-- they were depleted by costs and fizzled as
predicted-- and Ocean Mining is fighting yesterday's battle. But what
exists exists because its well funded). Meanwhile joe blow sending funds
p2p to friends or family in far off places doesn't have the funds or
technical acumen to deal with censorship potentially targeting him, his
activities, or his payees. The effect of censorship is basically to
require people to learn how to be money launderers to freely transact, and
those who don't suffer.
The case is even stronger re: the recently filtering arguments because
unlike some consensus rule anyone can just mine a block (rent hashpower,
you don't have to own it) or even more so the stuff like op_return limits
have long been bypassed by major miners. So the policy restriction was
already not working. So in some sense there are arguments getting
conflated: The op_return policy limit has already failed. So when people
point out that it doesn't work it's just a statement of fact rather than
speculation. But basically the 'bad' traffic has a lot easier time than
more innocent traffic, which is part of why filters can be both ineffective
and dangerous. It's also the case that existing filter efforts are not
backed by civil litigation or state mandates, but building infrastructure
creates an obvious stepping stone to that (in part because of the
insufficient effectiveness of filtering)-- it's just a bad road that will
almost inevitably lead to more escalations. Bitcoin is just better of
adopting the position that other people's transactions aren't our business,
even if they're stupid or drive fees up a bit for some periods and create
annoyances, because the alternative is easily much worse.
On Thu, Sep 25, 2025 at 9:26 PM Aiden McClelland <me@drbonez•dev> wrote:
> >I have no idea what you're referring to there.
>
> It's something I inferred from your primary argument that seems to be that
> user-configurable filters are bad because they would cause censorship. But
> it also sounds like you're saying such filters are completely ineffective
> at any sort of censorship at all. I don't really understand how these two
> viewpoints can coexist. What am I missing here?
>
> Best,
> *Aiden McClelland*
>
> On Thu, Sep 25, 2025, 3:14 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
>
>> I am not a core developer. I have not been for some eight years now.
>>
>> > that you yourself are worried they will reach the 80% needed
>>
>> I have no idea what you're referring to there. If lots of people run
>> nodes that screw up propagation they'll be routed around. I developed the
>> technical concepts required to get nearly 100% tx coverage even if almost
>> all nodes are blocking them quite a few years ago (
>> https://arxiv.org/pdf/1905.10518 ), but deployment of the implementation
>> has gone slow due to other factors (you know, such as the most
>> experienced developers being hit with billions of dollars in lawsuits as a
>> cost for their support of Bitcoin)... I expect if censoring actually
>> becomes widespread that technological improvements which further moot it
>> will be developed.
>>
>> These are just vulnerabilities that should be closed anyways-- after all
>> anyone at any time can just spin up any number of "nodes" that behave in
>> arbitrary ways, at ant time. It's been a lower priority because there are
>> other countermeasures (addnode-a-friend, manually setbanning bad peers,
>> etc.) and aforementione distractions.
>>
>> > censorship due to widespread use of transaction filters is a bad thing
>> (I'm not really taking a stance on that right now).
>>
>> I would point you to the history of discussion on Bitcoin starting back
>> with Satoshi's earliest announcements, and perhaps to help you understand
>> that if you want that what you want isn't bitcoin. If after consideration
>> you don't think censorship wouldn't be very bad, then really you and I have
>> nothing further to discuss.
>>
>> > are you willing to work with and compromise with people who are looking
>> for a solution like this? Or are you going to force them to abandon the
>> Core project entirely
>>
>> I don't really think there is any space to compromise with people who
>> think it's okay to add censorship to Bitcoin-- I mean sure whatever exact
>> relay policy there is there is plenty of tradeoffs but from the start of
>> this new filter debate the filter proponents have immediately come out with
>> vile insults accusing developers of promoting child sexual abuse and
>> shitcoins and what not---- that isn't some attempt to navigate a
>> technical/political trademark, it's an effort to villify and destory the
>> opposition. And unambiguously so as luke has said outright that his goal
>> is to destroy Bitcoin Core. So what's the compromise there?
>>
>> > Or even worse still, felt compelled to coordinate a UASF to block these
>> transactions entirely?
>>
>> I very much think people should do that-- they should actually make some
>> consensus rules for their filters to fork off and we can see what the
>> market thinks. -- And also even if the market prefers censored Bitcoin,
>> that's also fine with me, in the sense in my view Bitcoin was created to be
>> money as largely free from human judgement as possible. When it was
>> created most of the world was doing something else and didn't know they
>> needed freedom money. If it's still the case that most of the world
>> doesn't want freedom money that would be no shock. They should be free to
>> have what they want and people who want freedom money should be free to
>> have what they want. I got into bitcoin before it was worth practically
>> anything because of the freedom it provides, and I think that's paramount.
>>
>> Perhaps you should consider why they *don't* do that? I'd say it's
>> because (1) it won't work, and (2) it's not actually what the world wants--
>> an outspoken influence campaign is not necessarily all that reflective of
>> much of anything. Particularly given how inaccurate and emotionally
>> pandering the filter advocacy has been. But, hey, I've been wrong
>> before.
>>
>>
>>
>> On Thu, Sep 25, 2025 at 8:51 PM Aiden McClelland <me@drbonez•dev> wrote:
>>
>>> Greg,
>>>
>>> Let me assume for a minute, for the sake of argument, that I agree that
>>> transaction censorship due to widespread use of transaction filters is a
>>> bad thing (I'm not really taking a stance on that right now). It is an
>>> irrefutable fact that a very large portion of the user base wants to filter
>>> transactions. So many so, that you yourself are worried they will reach the
>>> 80% needed to prevent certain types of transactions from propogating.
>>> Wouldn't it then be *worse* if these 80% of users went and ran an
>>> alternative implementation, most likely written by it's most radical
>>> supporters? Or even worse still, felt compelled to coordinate a UASF to
>>> block these transactions entirely?
>>>
>>> I at no point intended to insinuate that you or any other core
>>> contributer be compelled to implement a proposal like this. It's up to its
>>> supporters to do so. The real question is, are you willing to work with and
>>> compromise with people who are looking for a solution like this? Or are you
>>> going to force them to abandon the Core project entirely?
>>>
>>> Best,
>>> *Aiden McClelland*
>>>
>>> On Thu, Sep 25, 2025, 2:03 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
>>>
>>>> > 1) Allowing node
>>>>
>>>> Who said anything about allowing? Everyone is allowed to do whatever
>>>> they want. Drill a hole in your head if you like, not my concern. None of
>>>> this thread is about what people are allowed to do-- that's off the table.
>>>> The design and licensing of Bitcoin is such that no one gets to stop anyone
>>>> else from what they want to do anyways (which is, in fact, a big part of
>>>> the issue here). To think otherwise is to be stuck in a kind of serf
>>>> thinking where you can only do what other people allow you to do. That has
>>>> never been what Bitcoin was about.
>>>>
>>>> Rather, the question is should people who care about Bitcoin spend
>>>> their time and money developing infrastructure that would be useful, even
>>>> primarily useful, for censorship. I say no. Especially because any time
>>>> spent on it is time away from anti-censorship pro-privacy tools and because
>>>> the effort spent doing so would undermine anti-censorship and pro-privacy
>>>> efforts because they would inevitably moot the efforts expected getting
>>>> into peoples business and filtering their transactions.
>>>>
>>>> You don't have to agree, and you're free to do your own thing just as
>>>> I'm free to say that I think it's a bad direction. From the very beginning
>>>> Bitcoin has stood against the freedom to transact being overridden by
>>>> some admin based on their judgment call weighing principles against other
>>>> concerns, or at the behest of their superiors. So many Bitcoiner will
>>>> stand against, route around, and do what they can do to make ineffectual
>>>> the blocking of consensual transactions. It might not seem as many at the
>>>> moment, but the pro-privacy and anti-censorship 'side' doesn't have a paid
>>>> PR and influence campaign, but it also doesn't matter so much because
>>>> Bitcoin takes advantage of the nature of information being easy to spread
>>>> and hard to stifel and it doesn't that that huge an effort to route around
>>>> censorship efforts.
>>>>
>>>> There are elements of anti-censorship in Bitcoin that have been so far
>>>> underdeveloped. It's unfortunate that their further development might be
>>>> forced at a time when efforts are needed on other areas. But perhaps they
>>>> wouldn't get done without a concrete motivation. Such is life.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Sep 25, 2025 at 9:21 AM yes_please <caucasianjazz12@gmail•com>
>>>> wrote:
>>>>
>>>>> Sorry Greg, could you please elaborate further on your ideas? Some are
>>>>> not exactly clear:
>>>>>
>>>>> 1) Allowing node runners to configure their node as they please and
>>>>> refuse to relay some txs is considered authoritarian, censorship, and an
>>>>> attempt to regulate third parties conduct. On the other hand, forcing nodes
>>>>> to merge towards a single shared configuration (by preventing them to block
>>>>> txs) is not considered authoritarian because this imposition does not
>>>>> discriminate towards any txs and is thus non-authoritarian? Did I get the
>>>>> reasoning correctly here?
>>>>>
>>>>> 2) If the aim is to have a homogenous mempool state and to model what
>>>>> will get mined, shouldn’t we reach this state through distributed
>>>>> independent nodes who decide independently on what they prefer this
>>>>> homogenous state to be? If we don’t reach this state through this
>>>>> distributed/independent mechanism, then how are we to reach this state? Who
>>>>> gets to decide and steer the direction so that we all converge towards this
>>>>> homogenous state? One of the strongest aspects of bitcoin is the fact that
>>>>> no single party can force a change/direction, and the network has to
>>>>> somehow reach a shared agreement through independent decision makers who
>>>>> act in what manner they think is best. The proposed BIP seems to be aligned
>>>>> with such a principle, I fail to see any authoritarian aspect here.
>>>>>
>>>>> 3) I share your sentiment and the aim to have a homogenous mempool
>>>>> state, but I am skeptical of the manner in which we are to achieve this
>>>>> according to the ideas you have here expressed (namely not through a
>>>>> distributed independent organic manner)
>>>>>
>>>>>
>>>>> Respectfully, yes_please
>>>>>
>>>>> On Thu, Sep 25, 2025 at 12:50 AM Greg Maxwell <gmaxwell@gmail•com>
>>>>> 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 <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
>>>>>> <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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAS2fgSXX5_TU86r%3DQOQAvg84tpRa7o9ha5%3DEn3tPmTUBrrqhw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 23027 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-25 17:52 ` Chris Guida
2025-09-25 20:46 ` Greg Maxwell
@ 2025-09-25 23:33 ` Andrew Poelstra
2025-09-26 7:58 ` Garlo Nicon
1 sibling, 1 reply; 25+ messages in thread
From: Andrew Poelstra @ 2025-09-25 23:33 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 1605 bytes --]
On Thu, Sep 25, 2025 at 11:52:02AM -0600, Chris Guida wrote:
>
> 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.
>
Once a transaction is in a block, you need to relay the transaction if
you want to relay a block. You cannot pick and choose which parts of a
block you like and which parts are "abusive". This is what it means for
something to be a consensus system.
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) and to help the
network (which would otherwise have poor propagation properties).
Any sort of filtering beyond that done by miners is contrary to this
purpose of the mempool. This is a technical fact. It has nothing to do
with "bitcoin's ethos", except its ethos as a consensus system, which
directly contradicts your point.
--
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/aNXRSd7ygh6NqE1V%40mail.wpsoftware.net.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-25 21:51 ` Greg Maxwell
@ 2025-09-26 2:06 ` Chris Riley
2025-09-26 2:17 ` Aiden McClelland
0 siblings, 1 reply; 25+ messages in thread
From: Chris Riley @ 2025-09-26 2:06 UTC (permalink / raw)
To: Greg Maxwell
Cc: Aiden McClelland, yes_please, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 19450 bytes --]
One concern is that even if filter scripts are local and opt-in initially,
social or economic pressure will push them toward "standardization"—and
from there toward implicit coercion—so the risk of soft censorship
increases over time. If relay policies start drifting, the mempool ceases
to reflect miner behavior and fragments into incompatible local views,
undermining its role as a shared substrate. Instead of decentralizing
control, filter modules may simply externalize it: those who author
“popular” (perhaps through demagoguery) filters gain outsized influence
over what the rest see. The path to robustness is not more policy layers,
but maintaining a minimal, common relay system.
On Thu, Sep 25, 2025 at 6:29 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
> "There are levels of survival we are prepared to accept."
>
> Black and white thinking is not very helpful here particularly because the
> goals of pro-filtering and anti-censorship aren't exact opposites.
>
> A widely censored world would greatly degrade the value of
> Bitcoin, particularly if the censors managed to enlist significant miners.
> It would be routed around at great cost, and with much less freedom
> provided for the world. But just like people continue to buy racy
> magazines or other completely lawful targets of operation chokepoint with
> USD, people would still route around Bitcoin censorship. But why even use
> Bitcoin if it's in a similar space of your transactions being capriciously
> blocks, your funds frozen, etc. as exists with legacy infrastructure?
>
> But the irony is that the traffic that people most desperately want to
> stop would be among the least impeded-- already today the spam traffic
> exists at all because it's well funded (or really existed a year ago, we
> are long past the huge spam floods-- they were depleted by costs and
> fizzled as predicted-- and Ocean Mining is fighting yesterday's battle. But
> what exists exists because its well funded). Meanwhile joe blow sending
> funds p2p to friends or family in far off places doesn't have the funds or
> technical acumen to deal with censorship potentially targeting him, his
> activities, or his payees. The effect of censorship is basically to
> require people to learn how to be money launderers to freely transact, and
> those who don't suffer.
>
> The case is even stronger re: the recently filtering arguments because
> unlike some consensus rule anyone can just mine a block (rent hashpower,
> you don't have to own it) or even more so the stuff like op_return limits
> have long been bypassed by major miners. So the policy restriction was
> already not working. So in some sense there are arguments getting
> conflated: The op_return policy limit has already failed. So when people
> point out that it doesn't work it's just a statement of fact rather than
> speculation. But basically the 'bad' traffic has a lot easier time than
> more innocent traffic, which is part of why filters can be both ineffective
> and dangerous. It's also the case that existing filter efforts are not
> backed by civil litigation or state mandates, but building infrastructure
> creates an obvious stepping stone to that (in part because of the
> insufficient effectiveness of filtering)-- it's just a bad road that will
> almost inevitably lead to more escalations. Bitcoin is just better of
> adopting the position that other people's transactions aren't our business,
> even if they're stupid or drive fees up a bit for some periods and create
> annoyances, because the alternative is easily much worse.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, Sep 25, 2025 at 9:26 PM Aiden McClelland <me@drbonez•dev> wrote:
>
>> >I have no idea what you're referring to there.
>>
>> It's something I inferred from your primary argument that seems to be
>> that user-configurable filters are bad because they would cause censorship.
>> But it also sounds like you're saying such filters are completely
>> ineffective at any sort of censorship at all. I don't really understand how
>> these two viewpoints can coexist. What am I missing here?
>>
>> Best,
>> *Aiden McClelland*
>>
>> On Thu, Sep 25, 2025, 3:14 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
>>
>>> I am not a core developer. I have not been for some eight years now.
>>>
>>> > that you yourself are worried they will reach the 80% needed
>>>
>>> I have no idea what you're referring to there. If lots of people run
>>> nodes that screw up propagation they'll be routed around. I developed the
>>> technical concepts required to get nearly 100% tx coverage even if almost
>>> all nodes are blocking them quite a few years ago (
>>> https://arxiv.org/pdf/1905.10518 ), but deployment of the
>>> implementation has gone slow due to other factors (you know, such as the
>>> most experienced developers being hit with billions of dollars in lawsuits
>>> as a cost for their support of Bitcoin)... I expect if censoring actually
>>> becomes widespread that technological improvements which further moot it
>>> will be developed.
>>>
>>> These are just vulnerabilities that should be closed anyways-- after all
>>> anyone at any time can just spin up any number of "nodes" that behave in
>>> arbitrary ways, at ant time. It's been a lower priority because there are
>>> other countermeasures (addnode-a-friend, manually setbanning bad peers,
>>> etc.) and aforementione distractions.
>>>
>>> > censorship due to widespread use of transaction filters is a bad thing
>>> (I'm not really taking a stance on that right now).
>>>
>>> I would point you to the history of discussion on Bitcoin starting back
>>> with Satoshi's earliest announcements, and perhaps to help you understand
>>> that if you want that what you want isn't bitcoin. If after consideration
>>> you don't think censorship wouldn't be very bad, then really you and I have
>>> nothing further to discuss.
>>>
>>> > are you willing to work with and compromise with people who are
>>> looking for a solution like this? Or are you going to force them to abandon
>>> the Core project entirely
>>>
>>> I don't really think there is any space to compromise with people who
>>> think it's okay to add censorship to Bitcoin-- I mean sure whatever exact
>>> relay policy there is there is plenty of tradeoffs but from the start of
>>> this new filter debate the filter proponents have immediately come out with
>>> vile insults accusing developers of promoting child sexual abuse and
>>> shitcoins and what not---- that isn't some attempt to navigate a
>>> technical/political trademark, it's an effort to villify and destory the
>>> opposition. And unambiguously so as luke has said outright that his goal
>>> is to destroy Bitcoin Core. So what's the compromise there?
>>>
>>> > Or even worse still, felt compelled to coordinate a UASF to block
>>> these transactions entirely?
>>>
>>> I very much think people should do that-- they should actually make some
>>> consensus rules for their filters to fork off and we can see what the
>>> market thinks. -- And also even if the market prefers censored Bitcoin,
>>> that's also fine with me, in the sense in my view Bitcoin was created to be
>>> money as largely free from human judgement as possible. When it was
>>> created most of the world was doing something else and didn't know they
>>> needed freedom money. If it's still the case that most of the world
>>> doesn't want freedom money that would be no shock. They should be free to
>>> have what they want and people who want freedom money should be free to
>>> have what they want. I got into bitcoin before it was worth practically
>>> anything because of the freedom it provides, and I think that's paramount.
>>>
>>> Perhaps you should consider why they *don't* do that? I'd say it's
>>> because (1) it won't work, and (2) it's not actually what the world wants--
>>> an outspoken influence campaign is not necessarily all that reflective of
>>> much of anything. Particularly given how inaccurate and emotionally
>>> pandering the filter advocacy has been. But, hey, I've been wrong
>>> before.
>>>
>>>
>>>
>>> On Thu, Sep 25, 2025 at 8:51 PM Aiden McClelland <me@drbonez•dev> wrote:
>>>
>>>> Greg,
>>>>
>>>> Let me assume for a minute, for the sake of argument, that I agree that
>>>> transaction censorship due to widespread use of transaction filters is a
>>>> bad thing (I'm not really taking a stance on that right now). It is an
>>>> irrefutable fact that a very large portion of the user base wants to filter
>>>> transactions. So many so, that you yourself are worried they will reach the
>>>> 80% needed to prevent certain types of transactions from propogating.
>>>> Wouldn't it then be *worse* if these 80% of users went and ran an
>>>> alternative implementation, most likely written by it's most radical
>>>> supporters? Or even worse still, felt compelled to coordinate a UASF to
>>>> block these transactions entirely?
>>>>
>>>> I at no point intended to insinuate that you or any other core
>>>> contributer be compelled to implement a proposal like this. It's up to its
>>>> supporters to do so. The real question is, are you willing to work with and
>>>> compromise with people who are looking for a solution like this? Or are you
>>>> going to force them to abandon the Core project entirely?
>>>>
>>>> Best,
>>>> *Aiden McClelland*
>>>>
>>>> On Thu, Sep 25, 2025, 2:03 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
>>>>
>>>>> > 1) Allowing node
>>>>>
>>>>> Who said anything about allowing? Everyone is allowed to do whatever
>>>>> they want. Drill a hole in your head if you like, not my concern. None of
>>>>> this thread is about what people are allowed to do-- that's off the table.
>>>>> The design and licensing of Bitcoin is such that no one gets to stop anyone
>>>>> else from what they want to do anyways (which is, in fact, a big part of
>>>>> the issue here). To think otherwise is to be stuck in a kind of serf
>>>>> thinking where you can only do what other people allow you to do. That has
>>>>> never been what Bitcoin was about.
>>>>>
>>>>> Rather, the question is should people who care about Bitcoin spend
>>>>> their time and money developing infrastructure that would be useful, even
>>>>> primarily useful, for censorship. I say no. Especially because any time
>>>>> spent on it is time away from anti-censorship pro-privacy tools and because
>>>>> the effort spent doing so would undermine anti-censorship and pro-privacy
>>>>> efforts because they would inevitably moot the efforts expected getting
>>>>> into peoples business and filtering their transactions.
>>>>>
>>>>> You don't have to agree, and you're free to do your own thing just as
>>>>> I'm free to say that I think it's a bad direction. From the very beginning
>>>>> Bitcoin has stood against the freedom to transact being overridden by
>>>>> some admin based on their judgment call weighing principles against other
>>>>> concerns, or at the behest of their superiors. So many Bitcoiner will
>>>>> stand against, route around, and do what they can do to make ineffectual
>>>>> the blocking of consensual transactions. It might not seem as many at the
>>>>> moment, but the pro-privacy and anti-censorship 'side' doesn't have a paid
>>>>> PR and influence campaign, but it also doesn't matter so much because
>>>>> Bitcoin takes advantage of the nature of information being easy to spread
>>>>> and hard to stifel and it doesn't that that huge an effort to route around
>>>>> censorship efforts.
>>>>>
>>>>> There are elements of anti-censorship in Bitcoin that have been so far
>>>>> underdeveloped. It's unfortunate that their further development might be
>>>>> forced at a time when efforts are needed on other areas. But perhaps they
>>>>> wouldn't get done without a concrete motivation. Such is life.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 25, 2025 at 9:21 AM yes_please <caucasianjazz12@gmail•com>
>>>>> wrote:
>>>>>
>>>>>> Sorry Greg, could you please elaborate further on your ideas? Some
>>>>>> are not exactly clear:
>>>>>>
>>>>>> 1) Allowing node runners to configure their node as they please and
>>>>>> refuse to relay some txs is considered authoritarian, censorship, and an
>>>>>> attempt to regulate third parties conduct. On the other hand, forcing nodes
>>>>>> to merge towards a single shared configuration (by preventing them to block
>>>>>> txs) is not considered authoritarian because this imposition does not
>>>>>> discriminate towards any txs and is thus non-authoritarian? Did I get the
>>>>>> reasoning correctly here?
>>>>>>
>>>>>> 2) If the aim is to have a homogenous mempool state and to model
>>>>>> what will get mined, shouldn’t we reach this state through distributed
>>>>>> independent nodes who decide independently on what they prefer this
>>>>>> homogenous state to be? If we don’t reach this state through this
>>>>>> distributed/independent mechanism, then how are we to reach this state? Who
>>>>>> gets to decide and steer the direction so that we all converge towards this
>>>>>> homogenous state? One of the strongest aspects of bitcoin is the fact that
>>>>>> no single party can force a change/direction, and the network has to
>>>>>> somehow reach a shared agreement through independent decision makers who
>>>>>> act in what manner they think is best. The proposed BIP seems to be aligned
>>>>>> with such a principle, I fail to see any authoritarian aspect here.
>>>>>>
>>>>>> 3) I share your sentiment and the aim to have a homogenous mempool
>>>>>> state, but I am skeptical of the manner in which we are to achieve this
>>>>>> according to the ideas you have here expressed (namely not through a
>>>>>> distributed independent organic manner)
>>>>>>
>>>>>>
>>>>>> Respectfully, yes_please
>>>>>>
>>>>>> On Thu, Sep 25, 2025 at 12:50 AM Greg Maxwell <gmaxwell@gmail•com>
>>>>>> 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 <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
>>>>>>> <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 bitcoindev+unsubscribe@googlegroups•com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgSXX5_TU86r%3DQOQAvg84tpRa7o9ha5%3DEn3tPmTUBrrqhw%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgSXX5_TU86r%3DQOQAvg84tpRa7o9ha5%3DEn3tPmTUBrrqhw%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/CAL5BAw2E2nupsgrZE6z2T2Fd4VWnF-NvPOZXXaOtbOLHSTWi-g%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 25283 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-26 2:06 ` Chris Riley
@ 2025-09-26 2:17 ` Aiden McClelland
2025-09-26 2:28 ` Chris Riley
0 siblings, 1 reply; 25+ messages in thread
From: Aiden McClelland @ 2025-09-26 2:17 UTC (permalink / raw)
To: Chris Riley; +Cc: Greg Maxwell, yes_please, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 20050 bytes --]
Chris,
Can you elaborate further on what economic incentives there would be
towards filter standardization?
Thanks,
*Aiden McClelland*
On Thu, Sep 25, 2025, 8:06 PM Chris Riley <criley@gmail•com> wrote:
> One concern is that even if filter scripts are local and opt-in initially,
> social or economic pressure will push them toward "standardization"—and
> from there toward implicit coercion—so the risk of soft censorship
> increases over time. If relay policies start drifting, the mempool ceases
> to reflect miner behavior and fragments into incompatible local views,
> undermining its role as a shared substrate. Instead of decentralizing
> control, filter modules may simply externalize it: those who author
> “popular” (perhaps through demagoguery) filters gain outsized influence
> over what the rest see. The path to robustness is not more policy layers,
> but maintaining a minimal, common relay system.
>
> On Thu, Sep 25, 2025 at 6:29 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
>
>> "There are levels of survival we are prepared to accept."
>>
>> Black and white thinking is not very helpful here particularly because
>> the goals of pro-filtering and anti-censorship aren't exact opposites.
>>
>> A widely censored world would greatly degrade the value of
>> Bitcoin, particularly if the censors managed to enlist significant miners.
>> It would be routed around at great cost, and with much less freedom
>> provided for the world. But just like people continue to buy racy
>> magazines or other completely lawful targets of operation chokepoint with
>> USD, people would still route around Bitcoin censorship. But why even use
>> Bitcoin if it's in a similar space of your transactions being capriciously
>> blocks, your funds frozen, etc. as exists with legacy infrastructure?
>>
>> But the irony is that the traffic that people most desperately want to
>> stop would be among the least impeded-- already today the spam traffic
>> exists at all because it's well funded (or really existed a year ago, we
>> are long past the huge spam floods-- they were depleted by costs and
>> fizzled as predicted-- and Ocean Mining is fighting yesterday's battle. But
>> what exists exists because its well funded). Meanwhile joe blow sending
>> funds p2p to friends or family in far off places doesn't have the funds or
>> technical acumen to deal with censorship potentially targeting him, his
>> activities, or his payees. The effect of censorship is basically to
>> require people to learn how to be money launderers to freely transact, and
>> those who don't suffer.
>>
>> The case is even stronger re: the recently filtering arguments because
>> unlike some consensus rule anyone can just mine a block (rent hashpower,
>> you don't have to own it) or even more so the stuff like op_return limits
>> have long been bypassed by major miners. So the policy restriction was
>> already not working. So in some sense there are arguments getting
>> conflated: The op_return policy limit has already failed. So when people
>> point out that it doesn't work it's just a statement of fact rather than
>> speculation. But basically the 'bad' traffic has a lot easier time than
>> more innocent traffic, which is part of why filters can be both ineffective
>> and dangerous. It's also the case that existing filter efforts are not
>> backed by civil litigation or state mandates, but building infrastructure
>> creates an obvious stepping stone to that (in part because of the
>> insufficient effectiveness of filtering)-- it's just a bad road that will
>> almost inevitably lead to more escalations. Bitcoin is just better of
>> adopting the position that other people's transactions aren't our business,
>> even if they're stupid or drive fees up a bit for some periods and create
>> annoyances, because the alternative is easily much worse.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Sep 25, 2025 at 9:26 PM Aiden McClelland <me@drbonez•dev> wrote:
>>
>>> >I have no idea what you're referring to there.
>>>
>>> It's something I inferred from your primary argument that seems to be
>>> that user-configurable filters are bad because they would cause censorship.
>>> But it also sounds like you're saying such filters are completely
>>> ineffective at any sort of censorship at all. I don't really understand how
>>> these two viewpoints can coexist. What am I missing here?
>>>
>>> Best,
>>> *Aiden McClelland*
>>>
>>> On Thu, Sep 25, 2025, 3:14 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
>>>
>>>> I am not a core developer. I have not been for some eight years now.
>>>>
>>>> > that you yourself are worried they will reach the 80% needed
>>>>
>>>> I have no idea what you're referring to there. If lots of people run
>>>> nodes that screw up propagation they'll be routed around. I developed the
>>>> technical concepts required to get nearly 100% tx coverage even if almost
>>>> all nodes are blocking them quite a few years ago (
>>>> https://arxiv.org/pdf/1905.10518 ), but deployment of the
>>>> implementation has gone slow due to other factors (you know, such as the
>>>> most experienced developers being hit with billions of dollars in lawsuits
>>>> as a cost for their support of Bitcoin)... I expect if censoring actually
>>>> becomes widespread that technological improvements which further moot it
>>>> will be developed.
>>>>
>>>> These are just vulnerabilities that should be closed anyways-- after
>>>> all anyone at any time can just spin up any number of "nodes" that behave
>>>> in arbitrary ways, at ant time. It's been a lower priority because there
>>>> are other countermeasures (addnode-a-friend, manually setbanning bad peers,
>>>> etc.) and aforementione distractions.
>>>>
>>>> > censorship due to widespread use of transaction filters is a bad
>>>> thing (I'm not really taking a stance on that right now).
>>>>
>>>> I would point you to the history of discussion on Bitcoin starting back
>>>> with Satoshi's earliest announcements, and perhaps to help you understand
>>>> that if you want that what you want isn't bitcoin. If after consideration
>>>> you don't think censorship wouldn't be very bad, then really you and I have
>>>> nothing further to discuss.
>>>>
>>>> > are you willing to work with and compromise with people who are
>>>> looking for a solution like this? Or are you going to force them to abandon
>>>> the Core project entirely
>>>>
>>>> I don't really think there is any space to compromise with people who
>>>> think it's okay to add censorship to Bitcoin-- I mean sure whatever exact
>>>> relay policy there is there is plenty of tradeoffs but from the start of
>>>> this new filter debate the filter proponents have immediately come out with
>>>> vile insults accusing developers of promoting child sexual abuse and
>>>> shitcoins and what not---- that isn't some attempt to navigate a
>>>> technical/political trademark, it's an effort to villify and destory the
>>>> opposition. And unambiguously so as luke has said outright that his goal
>>>> is to destroy Bitcoin Core. So what's the compromise there?
>>>>
>>>> > Or even worse still, felt compelled to coordinate a UASF to block
>>>> these transactions entirely?
>>>>
>>>> I very much think people should do that-- they should actually make
>>>> some consensus rules for their filters to fork off and we can see what the
>>>> market thinks. -- And also even if the market prefers censored Bitcoin,
>>>> that's also fine with me, in the sense in my view Bitcoin was created to be
>>>> money as largely free from human judgement as possible. When it was
>>>> created most of the world was doing something else and didn't know they
>>>> needed freedom money. If it's still the case that most of the world
>>>> doesn't want freedom money that would be no shock. They should be free to
>>>> have what they want and people who want freedom money should be free to
>>>> have what they want. I got into bitcoin before it was worth practically
>>>> anything because of the freedom it provides, and I think that's paramount.
>>>>
>>>> Perhaps you should consider why they *don't* do that? I'd say it's
>>>> because (1) it won't work, and (2) it's not actually what the world wants--
>>>> an outspoken influence campaign is not necessarily all that reflective of
>>>> much of anything. Particularly given how inaccurate and emotionally
>>>> pandering the filter advocacy has been. But, hey, I've been wrong
>>>> before.
>>>>
>>>>
>>>>
>>>> On Thu, Sep 25, 2025 at 8:51 PM Aiden McClelland <me@drbonez•dev>
>>>> wrote:
>>>>
>>>>> Greg,
>>>>>
>>>>> Let me assume for a minute, for the sake of argument, that I agree
>>>>> that transaction censorship due to widespread use of transaction filters is
>>>>> a bad thing (I'm not really taking a stance on that right now). It is an
>>>>> irrefutable fact that a very large portion of the user base wants to filter
>>>>> transactions. So many so, that you yourself are worried they will reach the
>>>>> 80% needed to prevent certain types of transactions from propogating.
>>>>> Wouldn't it then be *worse* if these 80% of users went and ran an
>>>>> alternative implementation, most likely written by it's most radical
>>>>> supporters? Or even worse still, felt compelled to coordinate a UASF to
>>>>> block these transactions entirely?
>>>>>
>>>>> I at no point intended to insinuate that you or any other core
>>>>> contributer be compelled to implement a proposal like this. It's up to its
>>>>> supporters to do so. The real question is, are you willing to work with and
>>>>> compromise with people who are looking for a solution like this? Or are you
>>>>> going to force them to abandon the Core project entirely?
>>>>>
>>>>> Best,
>>>>> *Aiden McClelland*
>>>>>
>>>>> On Thu, Sep 25, 2025, 2:03 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
>>>>>
>>>>>> > 1) Allowing node
>>>>>>
>>>>>> Who said anything about allowing? Everyone is allowed to do whatever
>>>>>> they want. Drill a hole in your head if you like, not my concern. None of
>>>>>> this thread is about what people are allowed to do-- that's off the table.
>>>>>> The design and licensing of Bitcoin is such that no one gets to stop anyone
>>>>>> else from what they want to do anyways (which is, in fact, a big part of
>>>>>> the issue here). To think otherwise is to be stuck in a kind of serf
>>>>>> thinking where you can only do what other people allow you to do. That has
>>>>>> never been what Bitcoin was about.
>>>>>>
>>>>>> Rather, the question is should people who care about Bitcoin spend
>>>>>> their time and money developing infrastructure that would be useful, even
>>>>>> primarily useful, for censorship. I say no. Especially because any time
>>>>>> spent on it is time away from anti-censorship pro-privacy tools and because
>>>>>> the effort spent doing so would undermine anti-censorship and pro-privacy
>>>>>> efforts because they would inevitably moot the efforts expected getting
>>>>>> into peoples business and filtering their transactions.
>>>>>>
>>>>>> You don't have to agree, and you're free to do your own thing just as
>>>>>> I'm free to say that I think it's a bad direction. From the very beginning
>>>>>> Bitcoin has stood against the freedom to transact being overridden
>>>>>> by some admin based on their judgment call weighing principles against
>>>>>> other concerns, or at the behest of their superiors. So many Bitcoiner
>>>>>> will stand against, route around, and do what they can do to make
>>>>>> ineffectual the blocking of consensual transactions. It might not seem as
>>>>>> many at the moment, but the pro-privacy and anti-censorship 'side' doesn't
>>>>>> have a paid PR and influence campaign, but it also doesn't matter so much
>>>>>> because Bitcoin takes advantage of the nature of information being easy to
>>>>>> spread and hard to stifel and it doesn't that that huge an effort to route
>>>>>> around censorship efforts.
>>>>>>
>>>>>> There are elements of anti-censorship in Bitcoin that have been so
>>>>>> far underdeveloped. It's unfortunate that their further development might
>>>>>> be forced at a time when efforts are needed on other areas. But perhaps
>>>>>> they wouldn't get done without a concrete motivation. Such is life.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 25, 2025 at 9:21 AM yes_please <caucasianjazz12@gmail•com>
>>>>>> wrote:
>>>>>>
>>>>>>> Sorry Greg, could you please elaborate further on your ideas? Some
>>>>>>> are not exactly clear:
>>>>>>>
>>>>>>> 1) Allowing node runners to configure their node as they please and
>>>>>>> refuse to relay some txs is considered authoritarian, censorship, and an
>>>>>>> attempt to regulate third parties conduct. On the other hand, forcing nodes
>>>>>>> to merge towards a single shared configuration (by preventing them to block
>>>>>>> txs) is not considered authoritarian because this imposition does not
>>>>>>> discriminate towards any txs and is thus non-authoritarian? Did I get the
>>>>>>> reasoning correctly here?
>>>>>>>
>>>>>>> 2) If the aim is to have a homogenous mempool state and to model
>>>>>>> what will get mined, shouldn’t we reach this state through distributed
>>>>>>> independent nodes who decide independently on what they prefer this
>>>>>>> homogenous state to be? If we don’t reach this state through this
>>>>>>> distributed/independent mechanism, then how are we to reach this state? Who
>>>>>>> gets to decide and steer the direction so that we all converge towards this
>>>>>>> homogenous state? One of the strongest aspects of bitcoin is the fact that
>>>>>>> no single party can force a change/direction, and the network has to
>>>>>>> somehow reach a shared agreement through independent decision makers who
>>>>>>> act in what manner they think is best. The proposed BIP seems to be aligned
>>>>>>> with such a principle, I fail to see any authoritarian aspect here.
>>>>>>>
>>>>>>> 3) I share your sentiment and the aim to have a homogenous mempool
>>>>>>> state, but I am skeptical of the manner in which we are to achieve this
>>>>>>> according to the ideas you have here expressed (namely not through a
>>>>>>> distributed independent organic manner)
>>>>>>>
>>>>>>>
>>>>>>> Respectfully, yes_please
>>>>>>>
>>>>>>> On Thu, Sep 25, 2025 at 12:50 AM Greg Maxwell <gmaxwell@gmail•com>
>>>>>>> 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 <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
>>>>>>>> <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 bitcoindev+unsubscribe@googlegroups•com.
>> To view this discussion visit
>> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgSXX5_TU86r%3DQOQAvg84tpRa7o9ha5%3DEn3tPmTUBrrqhw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgSXX5_TU86r%3DQOQAvg84tpRa7o9ha5%3DEn3tPmTUBrrqhw%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/CAOSz24SZ9x_c%3D3eXY0McxQbivbG5zHOfTiaZjR%2B%3DuAju4%2BpC3Q%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 25763 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-26 2:17 ` Aiden McClelland
@ 2025-09-26 2:28 ` Chris Riley
0 siblings, 0 replies; 25+ messages in thread
From: Chris Riley @ 2025-09-26 2:28 UTC (permalink / raw)
To: Aiden McClelland
Cc: Greg Maxwell, yes_please, Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 21307 bytes --]
Hi,
I'd think things like propagation effectiveness (e.g. if your filters are
too different from everyone else's, you won't relay what others will and
your own transactions may fail to propagate), convenience (e.g. most people
are going to just pick a pack of filters vs picking ones so you'll have a
handful of curated packages of filters), miner incentives (e.g. if a large
miner picks on those preferences could trickle down), reputation and
liability fears (e.g. if you are an outlier you may worry about accusations
of relaying "bad" transactions so you'd be pressured to standardize with
regulated entities, and network effects so that your not in the divergent
mempool. Would it be a feedback loop? Maybe, There probably are others
too, but that was just a quick thought. :-)
On Thu, Sep 25, 2025 at 10:17 PM Aiden McClelland <me@drbonez•dev> wrote:
> Chris,
>
> Can you elaborate further on what economic incentives there would be
> towards filter standardization?
>
> Thanks,
> *Aiden McClelland*
>
> On Thu, Sep 25, 2025, 8:06 PM Chris Riley <criley@gmail•com> wrote:
>
>> One concern is that even if filter scripts are local and opt-in
>> initially, social or economic pressure will push them toward
>> "standardization"—and from there toward implicit coercion—so the risk of
>> soft censorship increases over time. If relay policies start drifting, the
>> mempool ceases to reflect miner behavior and fragments into incompatible
>> local views, undermining its role as a shared substrate. Instead of
>> decentralizing control, filter modules may simply externalize it: those who
>> author “popular” (perhaps through demagoguery) filters gain outsized
>> influence over what the rest see. The path to robustness is not more policy
>> layers, but maintaining a minimal, common relay system.
>>
>> On Thu, Sep 25, 2025 at 6:29 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
>>
>>> "There are levels of survival we are prepared to accept."
>>>
>>> Black and white thinking is not very helpful here particularly because
>>> the goals of pro-filtering and anti-censorship aren't exact opposites.
>>>
>>> A widely censored world would greatly degrade the value of
>>> Bitcoin, particularly if the censors managed to enlist significant miners.
>>> It would be routed around at great cost, and with much less freedom
>>> provided for the world. But just like people continue to buy racy
>>> magazines or other completely lawful targets of operation chokepoint with
>>> USD, people would still route around Bitcoin censorship. But why even use
>>> Bitcoin if it's in a similar space of your transactions being capriciously
>>> blocks, your funds frozen, etc. as exists with legacy infrastructure?
>>>
>>> But the irony is that the traffic that people most desperately want to
>>> stop would be among the least impeded-- already today the spam traffic
>>> exists at all because it's well funded (or really existed a year ago, we
>>> are long past the huge spam floods-- they were depleted by costs and
>>> fizzled as predicted-- and Ocean Mining is fighting yesterday's battle. But
>>> what exists exists because its well funded). Meanwhile joe blow sending
>>> funds p2p to friends or family in far off places doesn't have the funds or
>>> technical acumen to deal with censorship potentially targeting him, his
>>> activities, or his payees. The effect of censorship is basically to
>>> require people to learn how to be money launderers to freely transact, and
>>> those who don't suffer.
>>>
>>> The case is even stronger re: the recently filtering arguments because
>>> unlike some consensus rule anyone can just mine a block (rent hashpower,
>>> you don't have to own it) or even more so the stuff like op_return limits
>>> have long been bypassed by major miners. So the policy restriction was
>>> already not working. So in some sense there are arguments getting
>>> conflated: The op_return policy limit has already failed. So when people
>>> point out that it doesn't work it's just a statement of fact rather than
>>> speculation. But basically the 'bad' traffic has a lot easier time than
>>> more innocent traffic, which is part of why filters can be both ineffective
>>> and dangerous. It's also the case that existing filter efforts are not
>>> backed by civil litigation or state mandates, but building infrastructure
>>> creates an obvious stepping stone to that (in part because of the
>>> insufficient effectiveness of filtering)-- it's just a bad road that will
>>> almost inevitably lead to more escalations. Bitcoin is just better of
>>> adopting the position that other people's transactions aren't our business,
>>> even if they're stupid or drive fees up a bit for some periods and create
>>> annoyances, because the alternative is easily much worse.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Sep 25, 2025 at 9:26 PM Aiden McClelland <me@drbonez•dev> wrote:
>>>
>>>> >I have no idea what you're referring to there.
>>>>
>>>> It's something I inferred from your primary argument that seems to be
>>>> that user-configurable filters are bad because they would cause censorship.
>>>> But it also sounds like you're saying such filters are completely
>>>> ineffective at any sort of censorship at all. I don't really understand how
>>>> these two viewpoints can coexist. What am I missing here?
>>>>
>>>> Best,
>>>> *Aiden McClelland*
>>>>
>>>> On Thu, Sep 25, 2025, 3:14 PM Greg Maxwell <gmaxwell@gmail•com> wrote:
>>>>
>>>>> I am not a core developer. I have not been for some eight years now.
>>>>>
>>>>> > that you yourself are worried they will reach the 80% needed
>>>>>
>>>>> I have no idea what you're referring to there. If lots of people run
>>>>> nodes that screw up propagation they'll be routed around. I developed the
>>>>> technical concepts required to get nearly 100% tx coverage even if almost
>>>>> all nodes are blocking them quite a few years ago (
>>>>> https://arxiv.org/pdf/1905.10518 ), but deployment of the
>>>>> implementation has gone slow due to other factors (you know, such as the
>>>>> most experienced developers being hit with billions of dollars in lawsuits
>>>>> as a cost for their support of Bitcoin)... I expect if censoring actually
>>>>> becomes widespread that technological improvements which further moot it
>>>>> will be developed.
>>>>>
>>>>> These are just vulnerabilities that should be closed anyways-- after
>>>>> all anyone at any time can just spin up any number of "nodes" that behave
>>>>> in arbitrary ways, at ant time. It's been a lower priority because there
>>>>> are other countermeasures (addnode-a-friend, manually setbanning bad peers,
>>>>> etc.) and aforementione distractions.
>>>>>
>>>>> > censorship due to widespread use of transaction filters is a bad
>>>>> thing (I'm not really taking a stance on that right now).
>>>>>
>>>>> I would point you to the history of discussion on Bitcoin starting
>>>>> back with Satoshi's earliest announcements, and perhaps to help you
>>>>> understand that if you want that what you want isn't bitcoin. If after
>>>>> consideration you don't think censorship wouldn't be very bad, then really
>>>>> you and I have nothing further to discuss.
>>>>>
>>>>> > are you willing to work with and compromise with people who are
>>>>> looking for a solution like this? Or are you going to force them to abandon
>>>>> the Core project entirely
>>>>>
>>>>> I don't really think there is any space to compromise with people who
>>>>> think it's okay to add censorship to Bitcoin-- I mean sure whatever exact
>>>>> relay policy there is there is plenty of tradeoffs but from the start of
>>>>> this new filter debate the filter proponents have immediately come out with
>>>>> vile insults accusing developers of promoting child sexual abuse and
>>>>> shitcoins and what not---- that isn't some attempt to navigate a
>>>>> technical/political trademark, it's an effort to villify and destory the
>>>>> opposition. And unambiguously so as luke has said outright that his goal
>>>>> is to destroy Bitcoin Core. So what's the compromise there?
>>>>>
>>>>> > Or even worse still, felt compelled to coordinate a UASF to block
>>>>> these transactions entirely?
>>>>>
>>>>> I very much think people should do that-- they should actually make
>>>>> some consensus rules for their filters to fork off and we can see what the
>>>>> market thinks. -- And also even if the market prefers censored Bitcoin,
>>>>> that's also fine with me, in the sense in my view Bitcoin was created to be
>>>>> money as largely free from human judgement as possible. When it was
>>>>> created most of the world was doing something else and didn't know they
>>>>> needed freedom money. If it's still the case that most of the world
>>>>> doesn't want freedom money that would be no shock. They should be free to
>>>>> have what they want and people who want freedom money should be free to
>>>>> have what they want. I got into bitcoin before it was worth practically
>>>>> anything because of the freedom it provides, and I think that's paramount.
>>>>>
>>>>> Perhaps you should consider why they *don't* do that? I'd say it's
>>>>> because (1) it won't work, and (2) it's not actually what the world wants--
>>>>> an outspoken influence campaign is not necessarily all that reflective of
>>>>> much of anything. Particularly given how inaccurate and emotionally
>>>>> pandering the filter advocacy has been. But, hey, I've been wrong
>>>>> before.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Sep 25, 2025 at 8:51 PM Aiden McClelland <me@drbonez•dev>
>>>>> wrote:
>>>>>
>>>>>> Greg,
>>>>>>
>>>>>> Let me assume for a minute, for the sake of argument, that I agree
>>>>>> that transaction censorship due to widespread use of transaction filters is
>>>>>> a bad thing (I'm not really taking a stance on that right now). It is an
>>>>>> irrefutable fact that a very large portion of the user base wants to filter
>>>>>> transactions. So many so, that you yourself are worried they will reach the
>>>>>> 80% needed to prevent certain types of transactions from propogating.
>>>>>> Wouldn't it then be *worse* if these 80% of users went and ran an
>>>>>> alternative implementation, most likely written by it's most radical
>>>>>> supporters? Or even worse still, felt compelled to coordinate a UASF to
>>>>>> block these transactions entirely?
>>>>>>
>>>>>> I at no point intended to insinuate that you or any other core
>>>>>> contributer be compelled to implement a proposal like this. It's up to its
>>>>>> supporters to do so. The real question is, are you willing to work with and
>>>>>> compromise with people who are looking for a solution like this? Or are you
>>>>>> going to force them to abandon the Core project entirely?
>>>>>>
>>>>>> Best,
>>>>>> *Aiden McClelland*
>>>>>>
>>>>>> On Thu, Sep 25, 2025, 2:03 PM Greg Maxwell <gmaxwell@gmail•com>
>>>>>> wrote:
>>>>>>
>>>>>>> > 1) Allowing node
>>>>>>>
>>>>>>> Who said anything about allowing? Everyone is allowed to do
>>>>>>> whatever they want. Drill a hole in your head if you like, not my
>>>>>>> concern. None of this thread is about what people are allowed to do--
>>>>>>> that's off the table. The design and licensing of Bitcoin is such that no
>>>>>>> one gets to stop anyone else from what they want to do anyways (which is,
>>>>>>> in fact, a big part of the issue here). To think otherwise is to be stuck
>>>>>>> in a kind of serf thinking where you can only do what other people allow
>>>>>>> you to do. That has never been what Bitcoin was about.
>>>>>>>
>>>>>>> Rather, the question is should people who care about Bitcoin spend
>>>>>>> their time and money developing infrastructure that would be useful, even
>>>>>>> primarily useful, for censorship. I say no. Especially because any time
>>>>>>> spent on it is time away from anti-censorship pro-privacy tools and because
>>>>>>> the effort spent doing so would undermine anti-censorship and pro-privacy
>>>>>>> efforts because they would inevitably moot the efforts expected getting
>>>>>>> into peoples business and filtering their transactions.
>>>>>>>
>>>>>>> You don't have to agree, and you're free to do your own thing just
>>>>>>> as I'm free to say that I think it's a bad direction. From the very
>>>>>>> beginning Bitcoin has stood against the freedom to transact being overridden
>>>>>>> by some admin based on their judgment call weighing principles against
>>>>>>> other concerns, or at the behest of their superiors. So many Bitcoiner
>>>>>>> will stand against, route around, and do what they can do to make
>>>>>>> ineffectual the blocking of consensual transactions. It might not seem as
>>>>>>> many at the moment, but the pro-privacy and anti-censorship 'side' doesn't
>>>>>>> have a paid PR and influence campaign, but it also doesn't matter so much
>>>>>>> because Bitcoin takes advantage of the nature of information being easy to
>>>>>>> spread and hard to stifel and it doesn't that that huge an effort to route
>>>>>>> around censorship efforts.
>>>>>>>
>>>>>>> There are elements of anti-censorship in Bitcoin that have been so
>>>>>>> far underdeveloped. It's unfortunate that their further development might
>>>>>>> be forced at a time when efforts are needed on other areas. But perhaps
>>>>>>> they wouldn't get done without a concrete motivation. Such is life.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Sep 25, 2025 at 9:21 AM yes_please <
>>>>>>> caucasianjazz12@gmail•com> wrote:
>>>>>>>
>>>>>>>> Sorry Greg, could you please elaborate further on your ideas? Some
>>>>>>>> are not exactly clear:
>>>>>>>>
>>>>>>>> 1) Allowing node runners to configure their node as they please
>>>>>>>> and refuse to relay some txs is considered authoritarian, censorship, and
>>>>>>>> an attempt to regulate third parties conduct. On the other hand, forcing
>>>>>>>> nodes to merge towards a single shared configuration (by preventing them to
>>>>>>>> block txs) is not considered authoritarian because this imposition does not
>>>>>>>> discriminate towards any txs and is thus non-authoritarian? Did I get the
>>>>>>>> reasoning correctly here?
>>>>>>>>
>>>>>>>> 2) If the aim is to have a homogenous mempool state and to model
>>>>>>>> what will get mined, shouldn’t we reach this state through distributed
>>>>>>>> independent nodes who decide independently on what they prefer this
>>>>>>>> homogenous state to be? If we don’t reach this state through this
>>>>>>>> distributed/independent mechanism, then how are we to reach this state? Who
>>>>>>>> gets to decide and steer the direction so that we all converge towards this
>>>>>>>> homogenous state? One of the strongest aspects of bitcoin is the fact that
>>>>>>>> no single party can force a change/direction, and the network has to
>>>>>>>> somehow reach a shared agreement through independent decision makers who
>>>>>>>> act in what manner they think is best. The proposed BIP seems to be aligned
>>>>>>>> with such a principle, I fail to see any authoritarian aspect here.
>>>>>>>>
>>>>>>>> 3) I share your sentiment and the aim to have a homogenous mempool
>>>>>>>> state, but I am skeptical of the manner in which we are to achieve this
>>>>>>>> according to the ideas you have here expressed (namely not through a
>>>>>>>> distributed independent organic manner)
>>>>>>>>
>>>>>>>>
>>>>>>>> Respectfully, yes_please
>>>>>>>>
>>>>>>>> On Thu, Sep 25, 2025 at 12:50 AM Greg Maxwell <gmaxwell@gmail•com>
>>>>>>>> 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 <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
>>>>>>>>> <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 bitcoindev+unsubscribe@googlegroups•com.
>>> To view this discussion visit
>>> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgSXX5_TU86r%3DQOQAvg84tpRa7o9ha5%3DEn3tPmTUBrrqhw%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgSXX5_TU86r%3DQOQAvg84tpRa7o9ha5%3DEn3tPmTUBrrqhw%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/CAL5BAw2RYHkUj4iREYL%2BNca_CYP-BwLB5pZg3xY8%3D4-sf0ompg%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 27471 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-25 23:33 ` Andrew Poelstra
@ 2025-09-26 7:58 ` Garlo Nicon
2025-09-27 14:44 ` 'OJ' via Bitcoin Development Mailing List
0 siblings, 1 reply; 25+ messages in thread
From: Garlo Nicon @ 2025-09-26 7:58 UTC (permalink / raw)
To: Andrew Poelstra; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 3580 bytes --]
> You cannot pick and choose which parts of a block you like and which
parts are "abusive".
In the current implementation, yes. But if you accept a proof, that a block
is valid, instead of accepting a block in plaintext, then you can land on
the same chain. Because after all, pruned nodes care only about the last
288 blocks, or something like that. If they can update their UTXO set, and
always land on a valid chain, then they don't need transaction data in
plaintext. They just need to update their UTXO database in a way, where
attacking it would require breaking ECDSA, SHA-256, or similar things (a
proof-based system, which would not weaken existing cryptographic
assumptions, would be sufficient).
And the same is true about Initial Blockchain Download. Only today, you
have to download hundreds of GBs, to synchronize the new node from scratch.
But it can be changed, and as the size of the whole chain will grow, people
will be pushed, to start deploying some optimizations. Otherwise, there
will be even less nodes, if node operators will decide to trust centralized
solutions instead, or do things, which already happened in some altcoins,
where people passed around an already synced node data, and trusted, that
it is valid (especially in CPU-mined coins, where verifying thousands
blocks required similar effort, than mining a new block).
pt., 26 wrz 2025 o 02:25 Andrew Poelstra <apoelstra@wpsoftware•net>
napisał(a):
> On Thu, Sep 25, 2025 at 11:52:02AM -0600, Chris Guida wrote:
> >
> > 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.
> >
>
> Once a transaction is in a block, you need to relay the transaction if
> you want to relay a block. You cannot pick and choose which parts of a
> block you like and which parts are "abusive". This is what it means for
> something to be a consensus system.
>
> 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) and to help the
> network (which would otherwise have poor propagation properties).
>
> Any sort of filtering beyond that done by miners is contrary to this
> purpose of the mempool. This is a technical fact. It has nothing to do
> with "bitcoin's ethos", except its ethos as a consensus system, which
> directly contradicts your point.
>
> --
> 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/aNXRSd7ygh6NqE1V%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/CAN7kyNgxnKoX7OBLOiHZWLg%2B9rvisbpmEMrs9RsSMDfeT-sw3w%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4651 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-26 7:58 ` Garlo Nicon
@ 2025-09-27 14:44 ` 'OJ' via Bitcoin Development Mailing List
2025-09-27 16:49 ` Bryan Bishop
0 siblings, 1 reply; 25+ messages in thread
From: 'OJ' via Bitcoin Development Mailing List @ 2025-09-27 14:44 UTC (permalink / raw)
To: garlonicon; +Cc: apoelstra, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 5451 bytes --]
I fail to understand how we come from "filters do not work" to "filters adopted by a majority is censorship". There seems to be a confusion too regarding filtering arbitrary data and censorship of consensus valid tx, like OFAC compliant block. Those two are different. Chris G has pointed out many times as well that spam cannot be stopped with consensus rules change, only via policy it can be filtered to make the spammers attempt more difficult.
Invoking Satoshi by Greg Maxwell is also disingenuous when he was the first to have policy in place to prevent specific script into blocks.
Also the thinking that miners control the network is also bad as its imposing behaviour on nodes runners such that the relay network mempool should always be consistent with what gets mined.
Each node is a free agent that determine what its mempool should be and conversely miners are the one that should take notice of what the relay network homogeneous mempool is.
This BIP proposal move in the right direction in regards to finding a compromise while not disparaging anyones right as a free agent node runner.
Best regards,
-------- Original Message --------
On 9/26/25 2:03 PM, Garlo Nicon wrote:
>> You cannot pick and choose which parts of a block you like and which parts are "abusive".
>
> In the current implementation, yes. But if you accept a proof, that a block is valid, instead of accepting a block in plaintext, then you can land on the same chain. Because after all, pruned nodes care only about the last 288 blocks, or something like that. If they can update their UTXO set, and always land on a valid chain, then they don't need transaction data in plaintext. They just need to update their UTXO database in a way, where attacking it would require breaking ECDSA, SHA-256, or similar things (a proof-based system, which would not weaken existing cryptographic assumptions, would be sufficient).
>
> And the same is true about Initial Blockchain Download. Only today, you have to download hundreds of GBs, to synchronize the new node from scratch. But it can be changed, and as the size of the whole chain will grow, people will be pushed, to start deploying some optimizations. Otherwise, there will be even less nodes, if node operators will decide to trust centralized solutions instead, or do things, which already happened in some altcoins, where people passed around an already synced node data, and trusted, that it is valid (especially in CPU-mined coins, where verifying thousands blocks required similar effort, than mining a new block).
>
> pt., 26 wrz 2025 o 02:25 Andrew Poelstra <apoelstra@wpsoftware•net> napisał(a):
>
>> On Thu, Sep 25, 2025 at 11:52:02AM -0600, Chris Guida wrote:
>>>
>>> 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.
>>>
>>
>> Once a transaction is in a block, you need to relay the transaction if
>> you want to relay a block. You cannot pick and choose which parts of a
>> block you like and which parts are "abusive". This is what it means for
>> something to be a consensus system.
>>
>> 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) and to help the
>> network (which would otherwise have poor propagation properties).
>>
>> Any sort of filtering beyond that done by miners is contrary to this
>> purpose of the mempool. This is a technical fact. It has nothing to do
>> with "bitcoin's ethos", except its ethos as a consensus system, which
>> directly contradicts your point.
>>
>> --
>> 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](mailto:bitcoindev%2Bunsubscribe@googlegroups•com).
>> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aNXRSd7ygh6NqE1V%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/CAN7kyNgxnKoX7OBLOiHZWLg%2B9rvisbpmEMrs9RsSMDfeT-sw3w%40mail.gmail.com](https://groups.google.com/d/msgid/bitcoindev/CAN7kyNgxnKoX7OBLOiHZWLg%2B9rvisbpmEMrs9RsSMDfeT-sw3w%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/Rr9InzRLdLOAtNdtSzmgBmCX634eSgDHEPS4fW-0WCCA31XHfbTSWQ1tweH0GeNhH9BhCREn_2sU5AR2SmXXgOm8SpkkVwciq7ql8K7yBiE%3D%40proton.me.
[-- Attachment #2: Type: text/html, Size: 6810 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
2025-09-27 14:44 ` 'OJ' via Bitcoin Development Mailing List
@ 2025-09-27 16:49 ` Bryan Bishop
0 siblings, 0 replies; 25+ messages in thread
From: Bryan Bishop @ 2025-09-27 16:49 UTC (permalink / raw)
Cc: Andrew Poelstra, Bitcoin Development Mailing List, Bryan Bishop
[-- Attachment #1: Type: text/plain, Size: 8807 bytes --]
It's rich to see someone lecturing andytoshi about the benefits of
replacing block content with succinct proofs. To be clear, pruning is not
the same thing as replacing blocks with proofs. Schemes like mimblewimble
or whatever else came after that he worked on are not SPV style abandonment
of verification. Or maybe we have forgotten?
Anyway, let's keep in mind that nobody is saying you cannot run a filter or
install one yourself. Anyone can run any software on their machine they
want. But you cannot force others to run it... or at least developers
around here won't go along with trying to force unremovable auto updates
etc.
The question at hand isn't the existence or possibility of filters, nor of
existence of bitcoin p2p protocol users that choose to filter, it's instead
about pressuring Bitcoin Core developers to release and endorse software
that includes certain filters--- which sets bad precedent against bitcoin
ethos (by which I mean "these transactions are argued to be harmful to
bitcoin so Core should do something even more harmful to bitcoin" is bad
precedent), also these people either don't want to do it or don't agree
with doing so and have been refusing to go along with the demands; going
along with the demands is itself another way to set a bad precedent. Such
pressure should first before all else be unilaterally rejected, as there is
no obligation expressed or implied, not to mention the coercive nature of
trying to force someone to act against their personal judgement or
values....
My reply below.
On Sat, Sep 27, 2025, 10:22 AM 'OJ' via Bitcoin Development Mailing List <
bitcoindev@googlegroups.com> wrote:
> I fail to understand how we come from "filters do not work" to "filters
> adopted by a majority is censorship".
>
If the goal of your mempool transaction filters is to prohibit certain
content on your node, then filters do not work because filters are not
applied to received blocks. You might not want to run bitcoin at all, even
in blocksonly mode + pruning, if you don't want bitcoin data on your
machine, actually.
If the goal of your filters is to prohibit content in other people's
mempools, then your local filters cannot achieve that because anyone can
put anything they want into their mempool even without your knowledge. This
is even true if a Bitcoin Core release was to ship new, overbearing default
filters etc.
Yes, even with a Core release, still developers around the world cannot
dictate what software or rules the protocol users choose to run themselves,
nor the contents of their mempools.
For those purposes it is clear that your filters do not work. They don't
achieve those goals, in answer to your question.
If you want to run a mempool with filters, then you have not been unable to
do that. If you want to run a node that does not gossip transactions or run
a mempool, then you are again not restricted from doing so. Use blocksonly,
use pruning, or even write your own software and place it on a webpage for
others to voluntarily download. For people who want to extra filter this
should be fantastic news because if they previously believed filters must
be distributed by a Core release, then now they are free from the burden of
that false belief and should feel relieved.
Even if relay filters are adopted by a majority of the p2p network, it
still doesn't work to stop the transactions because the transactions get
encoded into blocks, and then you receive blocks.... unless you don't
download blocks or run bitcoin.
As for the censorship question, perhaps instead ask what the purpose and
function of a mempool is. Why might a node have a mempool? After all, if
what you want is to see or have a history of transactions, then you have
the blocks of executed transactions. What then is the purpose of a node
having a mempool? It should seem absurd to you.
Maybe even the answers to these questions might help us to understand the
motivations or goals of developers as to what is included or not in the
software they write?
It's a possibility.
There seems to be a confusion too regarding filtering arbitrary data and
> censorship of consensus valid tx, like OFAC compliant block. Those two are
> different.
>
They aren't different; anyone is free to filter just as anyone is free to
mine your-so-called compliance block, which by the way leaves valuable fees
to others.
> Also the thinking that miners control the network is also bad as its
>
Who has argued that? What does control even mean here?
> miners are the one that should take notice of what the relay network
> homogeneous mempool is.
>
What?
> This BIP proposal move in the right direction in regards to finding a
> compromise while not disparaging anyones right as a free agent node runner.
>
If you honestly believe that, then I have very good news for you: you don't
need a BIP or Core release: users can simply download, write or use
whatever software with whatever filters they want. Mom compromise is
needed, because the bitcoin status quo already enables the
freedom-nondisparagement you seek. In fact, I would argue that you should
prefer that it does not need to be a default or a BIP, because enabling the
coordination and distribution of the tools of censorship seems contrary to
the purpose and goals of bitcoin.
- Bryan
https://x.com/kanzure
>
> -------- Original Message --------
> On 9/26/25 2:03 PM, Garlo Nicon wrote:
>
> > You cannot pick and choose which parts of a block you like and which
> parts are "abusive".
>
> In the current implementation, yes. But if you accept a proof, that a
> block is valid, instead of accepting a block in plaintext, then you can
> land on the same chain. Because after all, pruned nodes care only about the
> last 288 blocks, or something like that. If they can update their UTXO set,
> and always land on a valid chain, then they don't need transaction data in
> plaintext. They just need to update their UTXO database in a way, where
> attacking it would require breaking ECDSA, SHA-256, or similar things (a
> proof-based system, which would not weaken existing cryptographic
> assumptions, would be sufficient).
>
> And the same is true about Initial Blockchain Download. Only today, you
> have to download hundreds of GBs, to synchronize the new node from scratch.
> But it can be changed, and as the size of the whole chain will grow, people
> will be pushed, to start deploying some optimizations. Otherwise, there
> will be even less nodes, if node operators will decide to trust centralized
> solutions instead, or do things, which already happened in some altcoins,
> where people passed around an already synced node data, and trusted, that
> it is valid (especially in CPU-mined coins, where verifying thousands
> blocks required similar effort, than mining a new block).
>
> pt., 26 wrz 2025 o 02:25 Andrew Poelstra <apoelstra@wpsoftware•net>
> napisał(a):
>
>> On Thu, Sep 25, 2025 at 11:52:02AM -0600, Chris Guida wrote:
>> >
>> > 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.
>> >
>>
>> Once a transaction is in a block, you need to relay the transaction if
>> you want to relay a block. You cannot pick and choose which parts of a
>> block you like and which parts are "abusive". This is what it means for
>> something to be a consensus system.
>>
>> 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) and to help the
>> network (which would otherwise have poor propagation properties).
>>
>> Any sort of filtering beyond that done by miners is contrary to this
>> purpose of the mempool. This is a technical fact. It has nothing to do
>> with "bitcoin's ethos", except its ethos as a consensus system, which
>> directly contradicts your point.
>>
>> --
>> 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/CABaSBaywaebTUgoVKnNfnhy7psd-%3D08GnePCbBJmF1WvcZqkYw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 12025 bytes --]
^ permalink raw reply [flat|nested] 25+ 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-25 14:33 ` Luke Dashjr
@ 2025-09-28 1:22 ` /dev /fd0
2 siblings, 0 replies; 25+ messages in thread
From: /dev /fd0 @ 2025-09-28 1:22 UTC (permalink / raw)
To: me; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 2331 bytes --]
Hi Aiden,
There is an easy solution based on my understanding of [transaction
validation][0] although I have not tested it:
1. Add a config option `txnotify` similar to `blocknotify` that executes
commands or script when a new transaction is received from a peer.
2. Add a function `ExecuteTxNotify()` that will run the script provided by
the user in step 1. Script should either return 'accept' for 'reject' and
function would return true/false accordingly.
3. Call `ExecuteTxNotify()` in ` AcceptToMemoryPool()` so that rejected
transactions do not enter the mempool.
[0]: https://bitcoincore.academy/transaction-validation.html
/dev/fd0
floppy disk guy
On Thu, Sep 25, 2025 at 12:00 AM 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/CALiT-ZqFhMV8VfgOdNyamG4oLgyCL5E7W8s3F9gB_k0ihyUAgA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 3352 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2025-09-28 1:38 UTC | newest]
Thread overview: 25+ 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-25 9:21 ` yes_please
2025-09-25 20:03 ` Greg Maxwell
2025-09-25 20:51 ` Aiden McClelland
2025-09-25 21:14 ` Greg Maxwell
2025-09-25 21:25 ` Aiden McClelland
2025-09-25 21:51 ` Greg Maxwell
2025-09-26 2:06 ` Chris Riley
2025-09-26 2:17 ` Aiden McClelland
2025-09-26 2:28 ` Chris Riley
2025-09-25 17:52 ` Chris Guida
2025-09-25 20:46 ` Greg Maxwell
2025-09-25 21:02 ` Chris Guida
2025-09-25 23:33 ` Andrew Poelstra
2025-09-26 7:58 ` Garlo Nicon
2025-09-27 14:44 ` 'OJ' via Bitcoin Development Mailing List
2025-09-27 16:49 ` Bryan Bishop
2025-09-24 19:16 ` Chris Guida
2025-09-24 20:01 ` Greg Maxwell
2025-09-25 2:20 ` bigshiny
2025-09-25 14:33 ` Luke Dashjr
2025-09-28 1:22 ` /dev /fd0
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox