What would help now

The survey's records point at a short list of places where new tests, reviews and fixes would do the most good. Most IPC stability bugs so far were old code meeting a new kind of client, test or tool, so the most valuable work is to be that new client or test before a user is. The patterns page groups past bugs by mechanism; this page turns them into things to do.

Tests that reproduce several open bugs already exist as patches (each open bug page has a Reproduction section). Reviewing the pending fixes with those tests in hand is the quickest win.

Where help is most useful, in priority order

1. Open bugs without a fix, and pending fixes. No fix yet: call after destroy, destroy during a running call, negative or NaN wait timeout, client thread hangs when building a request throws, spawn close loop skipping the highest descriptor, the undiagnosed memory growth under mining clients, and the security-review findings added in October 2026 (listed under what is still open). Fixes in review that need adversarial testing: libmultiprocess#361, #335, #368 and #369, Bitcoin Core #35932, #36011, #36047, #36520 and #36525. A reproducing test for any of these is as useful as a new bug.
2. Mining interface methods and their inputs. Files: src/ipc/capnp/mining.capnp, mining-types.h, src/node/interfaces.cpp, src/node/block_template_manager.cpp, src/node/miner.cpp. For every field in BlockCreateOptions, BlockWaitOptions, BlockCheckOptions and every method argument: unset (Cap'n Proto default), zero, negative, NaN, huge; Assert and Assume reachable from wire input; calls during startup, during initial block download, after interrupt(), and after shutdown begins; one template used from two client threads; how much memory a template pins. Test with a Python (pycapnp) functional test like test/functional/interface_ipc_mining.py in a Debug build, where Assume aborts.
3. The shutdown path. Shutdown() in src/init.cpp, CapnpProtocol::disconnectIncoming in src/ipc/capnp/protocol.cpp, and event loop exit in src/mp/proxy.cpp. Look for node state freed while a call body still runs on a worker thread, callbacks that keep the loop alive, and handlers that run after their connection is gone. Test: hold each long call (waitNext, waitTipChanged, createNewBlock) in flight and stop the node with the stop RPC and with SIGINT, with the client connected, disconnecting, or already killed.
4. Cancellation in include/mp/type-context.h. The async request lambda, the cancel monitor, and access to request parameters and results on the worker thread versus the event loop thread. Windows are often a few instructions wide, so use the event loop testing hooks (testing_hook_async_request_start, _done, _misc in proxy-io.h) to disconnect or cancel at an exact point in mptest, and run under TSan and ASan.
5. Connection setup and listening. ConnectStream, ServeStream, _Serve and ListenConnections in proxy-io.h and proxy.cpp, plus src/ipc/capnp/protocol.cpp. Look at a peer disconnecting during bootstrap, the constructor of a server object failing, local versus remote close, and the connection-limit count. Existing tests to extend: test/mp/test/connect_tests.cpp, listen_tests.cpp.
6. Spawn and file descriptors. SpawnProcess and WaitProcess in src/mp/util.cpp and src/ipc/process.cpp: descriptors that reach the child, code between fork and exec that is not async-signal-safe, error paths that leak. Test: list open descriptors in the child from spawn_tests.cpp.
7. A foreign-client fuzzer or scripted client. The existing fuzz target (src/ipc/test/fuzz/ipc.cpp) drives the server through the generated C++ client, so it only produces call orders that client makes. A client written directly against the Cap'n Proto schema (pycapnp, or raw Cap'n Proto) should try: two requests on one server thread, a thread handle from another connection, a missing Context, calls after destroy, dropping a pending call, disconnecting at every step of a call, out-of-range enum values, and empty or oversized Data fields.

What makes a report or test most useful

• A failing test against the real code: a mptest case in libmultiprocess or a Bitcoin Core functional or unit test. A standalone program that models the pattern is much weaker evidence than one that runs the library.
• The exact interleaving: which threads, in what order, and where a delay or hook forces it.
• Whether a well-behaved peer (a C++, Rust or Python client used as documented, a client that crashes, or a normal shutdown) can trigger it, or only a malicious one.
• The effect you observed (crash, sanitizer report, hang) as distinct from the worst effect you think is possible.
• A short fix hint, if you have one.

Reports will be published on </> with a page per finding and credited anonymously unless you ask otherwise. If you find something that you think is exploitable without access to the IPC socket, report it privately first, as for any Bitcoin Core security issue.