Proposal: Pluggable Filter Framework

Protocol Design
1

First off, this is my first post. Hello to anyone who reads this. I’m a software engineer, and I’ve been a Bitcoiner for a long time, but I’m just now starting to study so that I can being contributing code and building in this space. Please critique.

Problem: Shipping hard-coded filters with on/off toggles centralizes policy. It opens the door for overreach & pressure to capitulate to the demands of nation states. It’s also a cat and mouse game.

Solution: Instead of baking in specific filters, ship a pluggable filter framework so that node operators can author and run their own policies. Node operators could then share effective filters organically.

Constraints:

  • Local policy modules only. Operators can add custom filters. Possibly as strings that are added to the config file or as flags.

  • Minimal, deterministic API. Pure function over tx/mempool context.

  • Safe execution. Sandbox, strict time & memory limits so a bad filter can’t wedge a node.

  • Observability. Local logs & metrics to tune false positives & false negatives.

  • Defaults: Ship the framework disabled. No active content filters by default.

Benefits:

  • Pushes policy to node operators, improving decentralization.

  • Upstream is no longer a single point of failure.

  • Lets communities iterate faster without waiting on node releases.

Trade-offs:

  • Still a cat-and-mouse game. This does not solve abuse - it decentralizes the response.

  • Operational overhead lands on node operators.

  • Risk of policy fragmentation.

1 Like
2

Prior art:

1 Like
3

Thanks! I’ll review these in the morning. I just read Greg’s wall of text and I’m now exhausted.

1 Like
4

His first response there is all you need to read - the purpose of the mempool is to model what’s going to be mined. If you understand that, it has great relevance to your proposal; for example, when you say

… surprisingly it’s the opposite that’s true: decentralization is improved by not pushing policy to node operators; if nodes are in sync on the candidates for mining, propagation and block reconstruction is faster (and fee estimation is better, side effect), which makes Bitcoin’s decentralization better. Mining would be more centralized if everyone was blocks-only, and that’s still true if everyone’s using different policies for what they see as candidates for mining.

(Not that I’m saying you shouldn’t have control over your node’s policy, of course, you do - I’m saying that it isn’t helping the network; it might help you in some way or other, e.g. if your node has specific constraints on resources perhaps)

5

I don’t think this is true for several policies used in bitcoin core. Example: dustrelayfee

/** Min feerate for defining dust.
 * Changing the dust limit changes which transactions are
 * standard and should be done with care and ideally rarely. It makes sense to
 * only increase the dust limit after prior releases were already not creating
 * outputs below the new threshold */
static constexpr unsigned int DUST_RELAY_TX_FEE{3000};
6

You are talking about the purpose of certain policies. That doesn’t contradict what I’m saying about the point of the mempool. Those are two different things.

Still you’re right to point out that simply “you might want to change things because you’re resource constrained” is overly simplistic. The various anti-DOS measures aren’t quite that trivial, but still I don’t think any of that changes the fundamental point I was making about decentralization and the purpose of mempools.