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 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 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 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 >>>> 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 >>>>> >>>>> . >>>>> >>>> -- >>> 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 >>> >>> . >>> >> -- >> 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 >> >> . >> > -- 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.