BIP: User-Defined Dynamic Relay Policy Scripts

dr-bonez commented at 6:17 pm on September 24, 2025: none

Draft: Mempool Validation and Relay Policy via User-Defined Scripts 9c219ee39f

Add Rationale 5d94245d82

jonatack added the label New BIP on Sep 24, 2025

jonatack commented at 8:56 pm on September 24, 2025: member

Link to related ML post: https://groups.google.com/g/bitcoindev/c/o3JZhiOa2PQ

chrisguida commented at 9:13 pm on September 24, 2025: none

@dr-bonez looks cool!

Curious what would have been the issue with just the raw tx hex being the format for the external interface.

dr-bonez commented at 9:21 pm on September 24, 2025: none

@dr-bonez looks cool!

Curious what would have been the issue with just the raw tx hex being the format for the external interface. @chrisguida That would require a significant amount of TX parsing code to be implemented in JS. Ideally the scripts should be fast and minimal. Plus the node implementation will generally have this data pre-parsed anyway, and implementing as getters will prevent unnecessary expensive computations if any of that data representation isn’t used by the scripts

martinmutonga commented at 6:11 am on September 25, 2025: none

This is a huge step toward lowering friction in Bitcoin modular relay policy could ease years of tension around mempool disagreements and help the network evolve without constant forks. By making relay policy modular, with a clean reference build (QuickJS + C++), devs get the freedom to experiment while keeping Bitcoin Core consensus intact, which is a far better design surface than battling over one rigid policy. Excited to see how the community can contribute here especially reviewers and C++ hands to help refine the reference implementation.

PLEB, x.com/mutonganakamoto

xstoicunicornx commented at 4:54 pm on September 25, 2025: none

Allows users to eliminate or extend mempool policies

The motivation for this BIP seems to make the assumption that allowing users to eliminate or extend mempool policies is sufficient motivation in itself, however I am not sure I am convinced of this assumption. Can you expand on what the motivation of allowing users to eliminate or extend mempool policies would be?

Update bip-mempool-policy-scripts.md 1a56983cce

in bip-mempool-policy-scripts.md:4 in 5d94245d82

0@@ -0,0 +1,149 @@
1+```
2+  BIP: ?
3+  Layer: Peer Services
4+  Title: Mempool Validation and Relay Policies via User-Defined Scripts

jonatack commented at 9:10 pm on September 25, 2025:

Editor note: the BIP title can be maximum of 44 characters (see BIP 2), this one is 62.

dr-bonez renamed this:
~~BIP: Mempool Validation and Relay Policy via User-Defined Scripts~~
BIP: User-Defined Dynamic Relay Policy Scripts
on Sep 30, 2025

murchandamus commented at 11:37 pm on September 30, 2025: contributor

Thanks for the submission. Reading the discussion on the mailing list, it sounds like this proposal has had a tepid reception so far. Are you aware of any projects so far that have indicated interest in implementing this proposal?

jasonribble commented at 5:00 am on October 1, 2025: none

To encourage consistency across implementations, transaction data available to scripts should conform to a well-defined type

If type safety and consistency are important enough to warrant TypeScript definitions in the spec, why not use TypeScript as the scripting language?

in bip-mempool-policy-scripts.md:54 in 1a56983cce

49+     - If any script throws an error, the transaction is rejected with error code `script-policy-validation-failed` and a message referencing the failed script.
50+3. **Sandboxing**
51+   - Scripts MUST be executed in a restricted runtime environment (no filesystem or network access).
52+   - Available globals are limited to the transaction context and a standard library of pure functions.
53+4. **Error Handling**
54+   - Syntax errors at startup cause the node to fail script loading but do not prevent ordinary operation.

Giszmo commented at 8:23 am on October 8, 2025:

That means a misconfigured node could silently revert to a “no policy” state? I think there should be a strict mode (perhaps default) in which startup aborts if the configured scripts cannot be parsed, validated, or sandboxed successfully. Non-strict mode could optionally continue but write a loud, persistent warning to logs and RPC getnetworkinfo. Consider explicitly saying: Nodes SHOULD refuse to start if one or more mandatory policy scripts fail to load.

in bip-mempool-policy-scripts.md:14 in 1a56983cce

 9+  License: BSD-2-Clause
10+```
11+
12+## Abstract
13+
14+This BIP proposes a standardized mechanism to validate transactions for mempool acceptance using external scripts. Nodes load a directory of JavaScript (ES2020-compatible) scripts that define acceptance rules. Each submitted transaction (or transaction package) is passed through the configured scripts; if all scripts return successfully, the transaction is accepted into the mempool. If any script throws an error, the transaction is rejected. This framework allows flexible policy development without requiring changes to the node implementation.

Giszmo commented at 8:31 am on October 8, 2025:

I have concerns about embedding JavaScript directly in node implementations.

While the abstract’s goal of allowing flexible and externalized policy is good, mandating JS (and a specific runtime) substantially raises the attack surface both through the complexity of the embedded interpreter and through the broader API exposure inside the node process.

Instead of binding the proposal to a particular scripting engine, it might be safer and more modular to run policies in a local helper daemon that communicates with the node over an RPC interface (e.g. JSON‑RPC or protobuf).

Advantages of that architecture:

The validation engine remains language‑agnostic; policy developers can use any language. Crashes in the policy engine can’t bring down the node; it can be rate‑limited or restarted independently. Security review is simpler. In short, it would be more future‑proof to define an interface and message schema, not a language.

Giszmo commented at 10:06 am on October 8, 2025: contributor

Concept ACK with reservations.

In Bitcoin, policy and consensus have been maintained as separate concepts and “spam filters” were a thing deliberately from early on. To now portrait the mempool as and only as a best estimate of what the next block(s) will look like is a dangerous tendency. Many node operators want to help relaying what they consider not to be spam, some use the mempool for mining and thus have their own reservations about what they want to mine or not and others want to use policy to merely prevent DOS attacks. If mempool consistency is required, then we have to fix that so it will not be required but elevating policy to consensus severity is not the path to go. Therefore I support splitting policy (as far as possible) from how a node works. While I would prefer a “firewall” that keeps some transactions from getting to the node in a stateless way - with no modifications to the node itself - the more realistic is to at least have some coupling with the node. The filter needs to at least be aware of blockheight, minFeerate and mempool size.

BIP: User-Defined Dynamic Relay Policy Scripts #1985