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 <jeremy....@gmail.com> 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 <alice...@gmail.com> 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 <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.