From: yes_please <caucasianjazz12@gmail•com>
To: Greg Maxwell <gmaxwell@gmail•com>
Cc: Aiden McClelland <me@drbonez•dev>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
Date: Thu, 25 Sep 2025 11:21:32 +0200 [thread overview]
Message-ID: <CAPDT2SRyVY4rh=HegG+kk5nnDf6qzYuRkUyxCC8iE-ydsh63ew@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgRABqRe1j6xzW0uhVrDiQnL6x1X6ALzfsJ7w4GztWVeNA@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2025-09-25 21:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-24 18:18 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 [this message]
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-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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAPDT2SRyVY4rh=HegG+kk5nnDf6qzYuRkUyxCC8iE-ydsh63ew@mail.gmail.com' \
--to=caucasianjazz12@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=gmaxwell@gmail$(echo .)com \
--cc=me@drbonez$(echo .)dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox