From: Dingocoin <dingocoin.luckydingo@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Mempool Validation and Relay Policies via User-Defined Scripts
Date: Tue, 30 Sep 2025 20:39:32 -0700 (PDT) [thread overview]
Message-ID: <5ace10fe-0cc1-4d6c-89f2-46f4c04330a3n@googlegroups.com> (raw)
In-Reply-To: <1A33D206-444A-49E7-B1F1-E9FE5F4E32FB@drbonez.dev>
[-- Attachment #1.1: Type: text/plain, Size: 5424 bytes --]
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 <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
>>>>> <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/5ace10fe-0cc1-4d6c-89f2-46f4c04330a3n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 7792 bytes --]
prev parent reply other threads:[~2025-10-01 7:38 UTC|newest]
Thread overview: 29+ 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
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
2025-09-30 4:21 ` 'Aiden McClelland' via Bitcoin Development Mailing List
2025-09-30 21:09 ` jeremy
2025-09-30 22:44 ` 'Aiden McClelland' via Bitcoin Development Mailing List
2025-10-01 3:39 ` Dingocoin [this message]
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=5ace10fe-0cc1-4d6c-89f2-46f4c04330a3n@googlegroups.com \
--to=dingocoin.luckydingo@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/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