Greg , Policy divergence already exists through client forks and custom patches, so the question isn't whether filtering should exist but whether it should be transparent and user-controlled versus opaque and developer-controlled. This BIP makes existing policy differences explicit rather than hidden, providing transparency where users may unknowingly participate in filtering through different client implementations. Given that miners increasingly bypass relay networks through direct submission channels, mempool policy is primarily about local resource management rather than modeling mining behavior, making user-defined policies a tool for node operators to manage their own resources. While concerns about censorship infrastructure are valid, transparent policy scripting is more aligned with Bitcoin's anti-censorship principles than the current situation of scattered, opaque policy differences across forks .
On Wednesday, October 1, 2025 at 4:32:39 AM UTC+5:30 Aiden McClelland wrote: > Jeremy, > > That's actually really clever. I had wanted the scripts to be able to > manage mempool size, and handle prioritization of higher feerate > transactions (hence the evict() fn and minFeerate part of the api), which I > don't think could be done with script, and I'm not sure we'd want to add > opcodes to make that possible, given that it only makes sense in this > context. But maybe that part doesn't need to be part of the dynamic > scripts? Definitely gives me a lot to think about. > > Thanks, > Aiden McClelland > > > On September 30, 2025 3:09:15 PM MDT, jeremy <[email protected]> wrote: > >> Bitcoin already has a built in user defined script language: Bitcoin >> Script. >> >> If you add a couple conditionally verified opcodes (the same ones >> necessary for covenants), you could write whatever filter you like, and >> we'd learn more about what the best opcodes are for writing covenants. >> >> You would execute the script "pretending" to be input 0. >> >> We would then at least learn something about covenants. >> On Tuesday, September 30, 2025 at 2:22:10 AM UTC-4 Aiden McClelland wrote: >> >>> /dev/fd0, >>> >>> I appreciate the comments. A txnotify solution could work, although it >>> loses a lot of the modularity and sandboxing of what I'm proposing. It >>> would probably result in a single external binary, running all of the >>> policy validation logic, rather than a bundle of scripts you can mix and >>> match. And it might encourage solutions that involve fetching relay >>> policies over the internet, which is probably not ideal. Ideally, updating >>> policy should require user action. >>> >>> Thanks, >>> Aiden McClelland >>> >>> >>> >>> On September 27, 2025 7:22:28 PM MDT, /dev /fd0 <[email protected]> >>> wrote: >>> >>>> 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 <[email protected]> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> I'd like to share for discussion a draft BIP to allow for a modular >>>>> mempool/relay policy: https://github.com/bitcoin/bips/pull/1985 >>>>> >>>>> I think it could potentially reduce conflict within the community >>>>> around relay policy, as an alternative to running lots of different node >>>>> implementations/forks when there are disagreements. >>>>> >>>>> I am working on a reference implementation using Bellard's QuickJS, >>>>> but it has been almost a decade since I've written C++, so it's slow >>>>> going >>>>> and I'm sure doesn't follow best-practices. Once it's working, it can be >>>>> cleaned up. >>>>> >>>>> Thanks, >>>>> Aiden McClelland >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Bitcoin Development Mailing List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion visit >>>>> https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0-6c68c6554f56n%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/bitcoindev/cbdab6fa-93bc-44c9-80f0-6c68c6554f56n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/5ace10fe-0cc1-4d6c-89f2-46f4c04330a3n%40googlegroups.com.
