Modularize mempool acceptance logic

[jasonfoura]

The changes to add support for Lua-based TX filtering were written in a hackathon context. As far as modularizing the mempool acceptance logic, I think we've been successful in proving:

• it's possible
• there's some community interest

That said, I'm 100% aware these changes are pretty far from being accepted into Knots. Even conceptually, I think there is a bit of work to do to determine which code changes we want to include.

[jasonfoura]

Re: #119 (comment)

@DeepDoge commented

Have you considered using WASM instead of Lua for TX filtering? WASM is bytecode, supported by multiple languages (including Lua), and could offer better performance while still providing strong sandboxing.

@luke-jr commented

But WASM requires compiling, therefore defeating the purpose as I understand it?

@DeepDoge commented

That’s true, but using WASM still wouldn’t require recompiling the node itself, only the individual user scripts. From what I understand, this is more like a plugin system?

I’m not sure what @jasonfoura’s exact vision is, but either way, having a script-based filtering option like this would be really useful. Just wanted to give my input.

[jasonfoura]

I think there are two key things for me to address here:

1. Lua, WASM, something else?

There wasn't a lot of consideration given to choosing Lua. Roughly, I considered:

• Lua (via sol) was reasonably easy for me to integrate with the existing C++ codebase, which was particularly useful given the hackathon context
• The language is designed and commonly used as an extension language

2. My "exact vision"

Really I was trying to gauge feasibility and interest in solving what I view as a problem: adding or modifying filtering logic requires rebuilding the Knots client. Consequently, releasing filter updates is a slow process.

Modularizing this logic could lead to some interesting possibilities e.g., better reactivity to new forms of "spam"; more customizable filtering logic; simpler opt-in/out of new/updated policies; simpler policy sharing between users. I'm sure creative minds will come up with more.

I had a few initial goals:

• Changes should be as drop-in as possible. Runtime modification is great, though needing to restart the node executable would still be better than having to rebuild (and, in some cases, redistribute) it.
• Users should be able to freely add, remove, modify, and inspect which policies are in effect.
• Policy management and distribution could become a responsibility outside of the Knots client itself.

I'm sure there were many things I did not address in my initial work, though a handful of things that were on my mind were:

• Better transaction "context" given to the policy script. As part of the proof-of-concept, only the string representation is provided. This has a good deal of information, but is far from a rich data structure.
• Runtime performance. At present, scripts are re-read from disk with each incoming transaction. The Lua context is recreated as well. Lua may or may not add some appreciable overhead to the transaction processing (I have not measured, nor am I aware of any hard performance targets). There may be other performance concerns.
• Security concerns. It's of course worth evaluating potential attack vectors, but I have not done so.
• Configuration of the scripts location
• Ordering of script execution - which could allow rejecting transactions quickly, without doing too much unnecessary processing.
• Richer response returned from the policy scripts. At present, a "truthy" response continues with subsequent filter execution, while a "falsey" response rejects the transaction's acceptance. It may be useful to provide the Knots client with more information e.g., a reason. Further, it may be useful to have three result categories:

1. Immediately reject the transaction (equivalent to a false response in the current state)
2. Continue with subsequent filter execution (equivalent to a true response in the current state)
3. Immediately accept the transaction (which would certainly require ordering of script execution) could be useful when composing more complex filter sets e.g., if the transaction matches some whitelist criteria accept it immediately, otherwise process additional filters.

[jasonfoura]

I do think WASM is an interesting idea that I had not considered. Initially I see some tradeoffs:

• WASM is almost certainly faster than Lua
• WASM requires compilation; Compilation in turn makes it more difficult for end-users to inspect (and therefore trust) any scripts
• WASM is supported by multiple languages, which enhances the community's ability to contribute. But requiring compilation significantly increases the effort required to develop a new filter, which diminishes contribution ability.

IMO the third one is the most intriguing, though I'm curious what others think here.

[luke-jr]

One of my thoughts for having scripts be "criteria", is that it enables the node to monitor execution time and re-order the scripts in real time. That also reduces the impact of DoS attempts: the node can react to them by optimising for the DoS-triggered check. This is probably a bit much for the first version, but it would make sense to design around that goal.

[jasonfoura]

Re: #119 (review)

@luke-jr commented

A lot of work to do here, so I'm going to convert the PR to a draft.

[jasonfoura]

I really just wanted to use this space to say thanks for your time and patience while we work through this.

[luke-jr]

I'm leaning toward a way to write "criteria" scripts in some sandboxed scripting language, with the ability to port it to C++ for performance later, and then a very simple miniscript-like syntax (and GUI editor) for the filter options. But it's a lot of work, and I'm having trouble finding a cross-platform sandbox I feel we can really trust for security isolation... :/

[gustavonmartins]

Something similar was done for NOSTR network to filter spam and I think you can benefit from that.

One of the most used relays ("node" in bitcoin language), strfry, has enabled the users to write filter plug-ins with the following capability:

1. ANY language can be used
2. Filter-plugins can be changed live, without having to restart the node

This incredibly lowers the barrier to code plugins, and make them shareable among many users.

AFAIK, this capability is done by letting the relay ask via command line (I guess stdin/out) if a certain transaction should be accepted or not. The standard for this communication is the JSON format. Then the plugin, which is installed in the same computer as the node, answers the question.

There is no "central" plugin, everyone is free to use their own plugin on their own node.

More details:

From strfry Github: Any programming language can be used to build a plugin using a simple line-based JSON interface.

Here is an example of some user-create plugin filter made in Deno

@hoytech seems to be the owner of the repo and might give you great insights!

[chrisguida]

Hey @gustavonmartins great suggestion! I'm curious how these plugins are distributed in the Nostr ecosystem... my worry would be incentivizing a centralized entity that creates and approves all filters, which would be the lowest-friction way to fight spam (but would create opportunities for censoring legitimate payments). Has the Nostr ecosystem discussed avoiding this outcome? It seems to me that we could circumvent the worst outcomes by simply having multiple distributors for filters.

[gustavonmartins]

Hey @gustavonmartins great suggestion! I'm curious how these plugins are distributed in the Nostr ecosystem... my worry would be incentivizing a centralized entity that creates and approves all filters, which would be the lowest-friction way to fight spam (but would create opportunities for censoring legitimate payments). Has the Nostr ecosystem discussed avoiding this outcome? It seems to me that we could circumvent the worst outcomes by simply having multiple distributors for filters.

Hi, I am sorry for the confusion. I will try to clarify:

In NOSTR, each "node" runs their own plugin, which the user itself decides what it will be. There is no central plugin authority. If there are 20 thousand people running nodes, anyone is free to have their own plugin filter, and each of them impact only the node running it, so there will be 20 thousand different filter plugins running.

Thus, there is no centralized entity to approve anything.

In the case of Bitcoin knots what could happen is that it comes with "default recommended filters", which the user can replace anyway if they please (and the replacement impacts only their own node, not anyone's else).

If people want to share plugins, they will share it in a web page or github, but no one has the obligation to use it.

I hope I made myself clearer, and I also edited my post for that.

[luke-jr]

Bitcoin nodes are the equivalent of nostr clients, not comparable to nostr relays in this respect.

Any solution needs to be usable for common end users. It can't require complicated steps like compiling, setting up complicate IPC, etc.

[chrisguida]

Yeah, it needs to strike a balance between usability and security.

If everyone is allowed to run arbitrary code, people could end up accidentally running malicious filters, etc. So there needs to be some kind of vetting of the filters before they are too widely distributed.

At the same time, the above centralization concern comes into play if everyone trusts one distributor to vet everything.

[rot13maxi]

some other environments to consider:

• ebpf: used in the linux kernel for sandboxed evaluation of packet filtering. has a sandboxed VM, has compiler tooling in LLVM, existing tooling. ebpf has been used in other non-kernel projects as well
• use an actual policy framework like OPA (Open Policy Agent) or some other predicate language. That way you don't have arbitrary programmability, and the tooling is closer to the the domain of writing policies

[psimoesbits]

I find this proposal amazing, how can I help in terms of programming

[chrisguida]

I would recommend building and running garbageman to get started https://github.com/chrisguida/bitcoin/tree/garbageman

It's likely that would be the first place this modular stuff goes

[chrisguida]

Hey Jason! Consider applying for funding from OpenSats to get this over the finish line

https://njump.me/nevent1qqstjrs3e850f4q00c08xmqk9ttqaz34ukfjf4s0eduuemceuxh22jgpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygqyey2a4mlw8qchlfe5g39vacus4qnflevppv3yre0xm56rm7lveypsgqqqqqqs7n2d44

[pithosian]

Just a possible alternative to consider: rather than building a sandboxed scripting engine into the node itself, you could have Knots optionally make a call (after doing its own internal checks) to some local filtering service(s) to make a filtering decision for it, outside of the node (eg API which takes a TX, returns an Option<RejectionReason>).

The filtering service can handle the complexity and security implications of a scripting engine, or can be written in a language which is easier to hack on/has faster compilation, etc.

The main complexity with that approach being 'what do you do if that service fails, is slow, etc', which is probably for configuration to decide, eg:

enum FilterServiceFailureBehaviour { Ignore, Reject, Retry(usize), Shutdown }
struct FilterService {
  endpoint: Uri,
  timeout: Duration,
  timeout_behaviour: FilterServiceFailureBehaviour,
  no_connection_behaviour: FilterServiceFailureBehaviour,
  error_response_behaviour: FilterServiceFailureBehaviour,
}

Supporting just one would be fine IMO, as that service itself could manage the complexity of additional services (and, not being exposed directly to the internet, could more safely be given the power to, eg, restart services).

[Earnestly]

I was going to suggest something a long these lines. Sending messages with crafted state information (this could be simple jsonlines or more efficient binary formats) over a socket which is then processed by an external tool. That external tool then returns an accept or reject-with-reason message for the given txn.

The use of a timeout and default timeout behaviour is a great addition.

The advantage of this approach is that the txn state information contained within the messages can be expanded over time based on requirement without breaking existing filter logic.