{ "number": 29409, "repo": "bitcoin/bitcoin", "url": "https://github.com/bitcoin/bitcoin/pull/29409", "title": "multiprocess: Add capnp wrapper for Chain interface", "author": "ryanofsky", "author_association": "MEMBER", "created_at": "2024-02-08T13:54:40Z", "updated_at": "2026-09-11T02:20:40Z", "age_days": 952, "draft": false, "labels": [ "IPC" ], "milestone": null, "base": "master", "head_sha": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "head_ref": "pr/ipc-chain", "head_repo": "ryanofsky/bitcoin", "head_history": [ { "t": "2024-02-08T20:45:31Z", "sha": "2fd10424c04397e50c6683a82db8a0bb68e0f6cc" }, { "t": "2024-02-28T16:08:29Z", "sha": "41831abe06d388ed18b5dbed739bc8fe76457f86" }, { "t": "2024-06-11T01:53:09Z", "sha": "6608b033c060c17be204beb8227333421c091816" }, { "t": "2024-06-11T19:10:50Z", "sha": "ab6b795f218b2074a9c9c05fcc94ec37eccca5a5" }, { "t": "2024-07-26T16:05:16Z", "sha": "eec0d31850aa1f7c520a46c417320f480f23fb1c" }, { "t": "2024-07-26T17:16:47Z", "sha": "43dc39eed47d83b2b7e72c911198bbdd401c78d8" }, { "t": "2024-09-19T10:43:13Z", "sha": "65c4edda94ead5c20969681f8337fd6a735182cc" }, { "t": "2024-09-26T14:00:53Z", "sha": "968f14fc7a634f65f4399dc042a37d4a39f2c703" }, { "t": "2024-11-12T16:26:25Z", "sha": "34d3e2a6eaaab9de5328c3e64739f1392696c7db" }, { "t": "2024-12-06T12:57:31Z", "sha": "64b833854a34d87cde4e0ca4173d75012c401a7a" }, { "t": "2025-02-11T03:42:17Z", "sha": "4fa7f72cb9d8f0290f56293989ec6ea950162c5b" }, { "t": "2025-06-03T20:08:10Z", "sha": "f92422e308ec33e2b211b866e218efacc77a4f7f" }, { "t": "2025-07-24T16:18:03Z", "sha": "c0d9515a3aef468bf4c5949c419ab1c9bab0dfa3" }, { "t": "2025-07-28T14:25:25Z", "sha": "b372063241fbd34d27d062f3e438a3e425a9dfc5" }, { "t": "2025-09-24T13:55:39Z", "sha": "7ba7ec9d08927f244da8d5c1a7a1d7ced3239465" }, { "t": "2025-09-30T13:58:07Z", "sha": "7a526a161fdb31a04b0afaaa112a137b9a595977" }, { "t": "2025-10-21T17:25:07Z", "sha": "2ae18d058562dd494f88328c6907c31c5d68b04e" }, { "t": "2025-10-22T09:28:49Z", "sha": "2763976d96663fcf013832cfbf771fd4050924ee" }, { "t": "2025-11-20T18:51:11Z", "sha": "d9efd1e49d1df154970b6a60229eedde3ba7cffe" }, { "t": "2025-12-12T12:18:00Z", "sha": "89cf624fe811d90d43f22d4519d859716d3ea958" }, { "t": "2025-12-16T02:09:40Z", "sha": "b2cbdd3c3297c5981895c7546fbfcbf1ea14fd02" }, { "t": "2026-01-06T20:58:39Z", "sha": "b7b6d6c316221f86914316e82e593fc35df1c92d" }, { "t": "2026-02-27T19:00:09Z", "sha": "46bc59f581bd90f3b0f73be86a913afadc022bb0" }, { "t": "2026-02-27T19:46:12Z", "sha": "5c2b520f6b7a2e14048df093c834410077c250bb" }, { "t": "2026-03-01T23:18:02Z", "sha": "e66150d2e4833ad2d6cf4955b3c793449c326494" }, { "t": "2026-03-02T00:57:59Z", "sha": "22f2c9a0d8817276c5738271b6389f47a9023809" }, { "t": "2026-03-31T17:42:26Z", "sha": "6e3ecc8f05b8ae7fc405fea353652c120a210fbe" }, { "t": "2026-03-31T18:51:17Z", "sha": "6833d5f2b49fed8182160c5996ae94d7dfb476a1" }, { "t": "2026-07-14T00:33:36Z", "sha": "9aee0eac079b93534e89e0c4b69767f36416fd71" }, { "t": "2026-07-14T12:14:21Z", "sha": "2eb914c6341591661b1632901c3e7b3991214d7a" }, { "t": "2026-08-24T17:06:22Z", "sha": "e914744ebacf73a5d1ab93e190ac40ccc470dd0c" }, { "t": "2026-09-08T18:25:57Z", "sha": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330" } ], "additions": 2190, "deletions": 429, "changed_files": 71, "commit_count": 7, "size_bucket": "XL", "mergeable_state": "clean", "bot": { "drahtbot": { "present": true, "reviews": { "concept_ack": [ { "login": "josibake", "url": "https://github.com/bitcoin/bitcoin/pull/29409#issuecomment-2377512124" }, { "login": "darosior", "url": "https://github.com/bitcoin/bitcoin/pull/29409#issuecomment-2546088852" }, { "login": "willcl-ark", "url": "https://github.com/bitcoin/bitcoin/pull/29409#pullrequestreview-4327707140" } ], "stale_ack": [ { "login": "cbergqvist", "url": "https://github.com/bitcoin/bitcoin/pull/29409#pullrequestreview-1906789449" }, { "login": "sedited", "url": "https://github.com/bitcoin/bitcoin/pull/29409#pullrequestreview-2490248963" } ] }, "conflicts": [ { "number": 36167, "title": "[RFC] Enable `-Wunused`", "author": "fanquake" }, { "number": 36097, "title": "mining: replace interrupt methods with cancellation arguments", "author": "xyzconstant" }, { "number": 35932, "title": "ipc: make ipc::disconnectIncoming wait for in-progress calls to complete", "author": "ryanofsky" }, { "number": 35911, "title": "Warn on and add missing [[noreturn]]", "author": "fanquake" }, { "number": 35511, "title": "RFC: consensus: Make `CAmount` a class", "author": "hodlinator" }, { "number": 32387, "title": "ipc: add windows support", "author": "ryanofsky" }, { "number": 31507, "title": "build: Use clang-cl to build on Windows natively", "author": "hebasto" } ] } }, "acks_parsed": { "josibake": { "kind": "concept_ack", "hash": null, "t": "2024-09-26T17:16:13Z", "stale": false }, "darosior": { "kind": "ack", "hash": "395d5eed0475558de2c2a66914d5a5814ce38f3c", "t": "2024-12-09T22:12:12Z", "stale": true }, "sedited": { "kind": "ack", "hash": "64b833854a34d87cde4e0ca4173d75012c401a7a", "t": "2024-12-09T22:25:33Z", "stale": true }, "willcl-ark": { "kind": "concept_ack", "hash": null, "t": "2026-05-20T11:19:54Z", "stale": false } }, "acks_tally": { "ack": 0, "stale_ack": 2, "concept_ack": 2, "approach_ack": 0, "nack": 0, "concept_nack": 0, "approach_nack": 0 }, "reviews": { "approved": 5, "changes_requested": 1, "distinct_reviewers": [ "Big621", "Sjors", "ariard", "cbergqvist", "darosior", "josibake", "l0rinc", "maflcko", "pseudoramdom", "sedited", "willcl-ark", "xyzconstant", "zaidmstrr" ] }, "signals": { "needs_rebase": false, "ci_failed": false, "mergeable_state": "clean", "last_author_activity": "2026-09-08T18:25:57Z", "last_reviewer_activity": "2026-09-09T16:20:47Z", "last_reviewer": "zaidmstrr", "author_silent_days": 8, "waiting_on_author_days": 7, "days_since_update": 6 }, "refs": { "mentioned": [ 10102, 19460, 19461, 26022, 29652, 30214, 30454, 30509, 30510, 30678, 30697, 31552, 31740, 31741, 32345, 32438, 32641, 32660, 32862, 33169, 33218, 33567, 33774, 34020, 34075, 34422, 34568, 34981, 35084, 35661, 36176 ], "depends_on": [], "fixes": [], "linked_issues": [], "references": [ { "number": 10102, "type": "pull", "state": "open", "merged": false, "merged_at": null, "title": "Multiprocess bitcoin" }, { "number": 35084, "type": "pull", "state": "closed", "merged": true, "merged_at": "2026-07-29", "title": "ipc: Add nonunix platform support" }, { "number": 19460, "type": "pull", "state": "open", "merged": false, "merged_at": null, "title": "multiprocess: Add bitcoin-wallet -ipcconnect option" }, { "number": 19461, "type": "pull", "state": "open", "merged": false, "merged_at": null, "title": "multiprocess: Add bitcoin-gui -ipcconnect option" }, { "number": 26022, "type": "pull", "state": "open", "merged": false, "merged_at": null, "title": "Add util::ResultPtr class" }, { "number": 29652, "type": "pull", "state": "closed", "merged": false, "merged_at": null, "title": "wallet: Avoid potentially writing incorrect best block locator" }, { "number": 30214, "type": "pull", "state": "closed", "merged": true, "merged_at": "2025-12-16", "title": "refactor: Improve assumeutxo state representation" }, { "number": 30454, "type": "pull", "state": "closed", "merged": true, "merged_at": "2024-08-28", "title": "build: Introduce CMake-based build system" }, { "number": 30509, "type": "pull", "state": "closed", "merged": true, "merged_at": "2024-09-09", "title": "multiprocess: Add -ipcbind option to bitcoin-node" }, { "number": 30510, "type": "pull", "state": "closed", "merged": true, "merged_at": "2024-09-25", "title": "multiprocess: Add IPC wrapper for Mining interface" }, { "number": 30678, "type": "pull", "state": "closed", "merged": true, "merged_at": "2024-09-23", "title": "wallet: Write best block to disk before backup" }, { "number": 30697, "type": "pull", "state": "closed", "merged": true, "merged_at": "2024-08-27", "title": "Bugfix: Ensure Atomicity in Wallet Settings Updates from Chain Interface" }, { "number": 31552, "type": "pull", "state": "closed", "merged": true, "merged_at": "2025-01-06", "title": "depends: Update capnproto to 1.1.0" }, { "number": 31740, "type": "pull", "state": "closed", "merged": true, "merged_at": "2025-01-29", "title": "depends: Update libmultiprocess library before converting to subtree" }, { "number": 31741, "type": "pull", "state": "closed", "merged": true, "merged_at": "2025-04-11", "title": "multiprocess: Add libmultiprocess git subtree" }, { "number": 32345, "type": "pull", "state": "closed", "merged": true, "merged_at": "2025-08-18", "title": "ipc: Handle unclean shutdowns better" }, { "number": 32438, "type": "pull", "state": "closed", "merged": true, "merged_at": "2025-05-09", "title": "refactor: Removals after bdb removal" }, { "number": 32641, "type": "pull", "state": "closed", "merged": true, "merged_at": "2025-05-30", "title": "Update libmultiprocess subtree to fix clang-tidy errors" }, { "number": 32660, "type": "pull", "state": "closed", "merged": true, "merged_at": "2025-07-08", "title": "rpc: Use type-safe exception to pass RPC help" }, { "number": 32862, "type": "pull", "state": "closed", "merged": true, "merged_at": "2025-07-08", "title": "rpc: use CScheduler for relocking wallet and remove RPCTimer" }, { "number": 33169, "type": "pull", "state": "closed", "merged": true, "merged_at": "2025-08-14", "title": "interfaces, chain, refactor: Remove unused getTipLocator and incaccurate getActiveChainLocator" }, { "number": 33218, "type": "pull", "state": "closed", "merged": true, "merged_at": "2025-10-28", "title": "refactor: rename `fees.{h,cpp}` to `fees/block_policy_estimator.{h,cpp}`" }, { "number": 33567, "type": "pull", "state": "closed", "merged": true, "merged_at": "2025-10-31", "title": "node: change a tx-relay on/off flag to enum" }, { "number": 33774, "type": "pull", "state": "closed", "merged": true, "merged_at": "2025-12-04", "title": "cmake: Move IPC tests to `ipc/test`" }, { "number": 34020, "type": "pull", "state": "closed", "merged": true, "merged_at": "2026-07-07", "title": "mining: add getTransactions(ByWitnessID) IPC methods" }, { "number": 34075, "type": "pull", "state": "closed", "merged": true, "merged_at": "2026-08-21", "title": "fees: Introduce Mempool Based Fee Estimation to reduce overestimation" }, { "number": 34422, "type": "pull", "state": "closed", "merged": true, "merged_at": "2026-03-03", "title": "Update libmultiprocess subtree to be more stable with rust IPC client" }, { "number": 34568, "type": "pull", "state": "closed", "merged": true, "merged_at": "2026-02-20", "title": "mining: Break compatibility with existing IPC mining clients" }, { "number": 34981, "type": "issue", "state": "open", "merged": false, "merged_at": null, "title": "multiprocess: expose existing interfaces or design new ones?" }, { "number": 35661, "type": "pull", "state": "closed", "merged": true, "merged_at": "2026-07-07", "title": "Update libmultiprocess subtree to add `ThreadMap.makePool` method" }, { "number": 36176, "type": "pull", "state": "closed", "merged": true, "merged_at": "2026-09-07", "title": "wallet: avoid a crash when creating a wallet with -nosettings" } ], "conflicts": [ 36167, 36097, 35932, 35911, 35511, 32387, 31507 ] }, "stack": { "shares_commits_with": [ 10102, 19460, 19461 ], "based_on": [], "base_for": [ 10102, 19460, 19461 ] }, "review_paths": [ "src/interfaces/chain.h", "src/ipc/capnp/chain-types.h", "src/ipc/capnp/chain.capnp", "src/ipc/capnp/chain.cpp", "src/ipc/capnp/common-types.h", "src/rpc/request.h" ], "body": "Changes making it possible to call `interface::Chain` over a socket.\n\nNote: The changes in this PR allow a `bitcoin-node` process to be controlled over a socket. The socket can either be an UNIX socket created by specifying the `-ipcbind` option, or it can be a socketpair created by a controlling process and passed to `bitcoin-node` via the `-ipcfd=` with a file descriptor number. This PR is a dependency of #10102 which allows the wallet code to run in a separate process and use the `Chain` interface.\n\n---\n\nThis PR is part of the [process separation project](https://github.com/bitcoin/bitcoin/issues/28722).\n\n**This is based on #.** The non-base commits are:\n\n- [`d9cfcf89bb5` build: suppress -Wc++23-lambda-attributes in warn_interface](https://github.com/bitcoin/bitcoin/pull/29409/commits/d9cfcf89bb58e83ff9620e7cfaf896a5275dc217)\n- [`ae6b583256c` Add capnp serialization code for bitcoin types](https://github.com/bitcoin/bitcoin/pull/29409/commits/ae6b583256cd0972a09f38ecf65d0005dbd34028)\n- [`4466e5ce9b7` Add capnp wrapper for Handler interface](https://github.com/bitcoin/bitcoin/pull/29409/commits/4466e5ce9b7652f8af32dd70d89124be67626240)\n- [`7b997424a95` Add capnp wrapper for Chain interface](https://github.com/bitcoin/bitcoin/pull/29409/commits/7b997424a951e7421a8d44d8f9ba3733eeff9ec6)\n- [`c2dfc0c57f3` multiprocess: Expose Chain interface](https://github.com/bitcoin/bitcoin/pull/29409/commits/c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330)", "commits": [ { "sha": "4c842beaae2e97d7934800c8433da9632b21c0ff", "date": "2026-09-08T08:13:51Z", "message": "Squashed 'src/ipc/libmultiprocess/' changes from e8de5c7b68e..4d454a81da6\n\n4d454a81da6 Merge bitcoin-core/libmultiprocess#358: refactor: Enable readability-container-contains\ndba99582b32 Merge bitcoin-core/libmultiprocess#357: doc: Update Cap'n Proto version to match minimum\n00923922ac3 Merge bitcoin-core/libmultiprocess#356: ci: Remove hard-coded -j4 from sanitize config\nfa101113b50 refactor: Enable readability-container-contains\n81f824b025f doc: Update Cap'n Proto version to match minimum\nfa30e2093c7 ci: Remove hard-coded -j4 from sanitize config\nf2e8df82ede Merge bitcoin-core/libmultiprocess#350: cmake: add type-unordered-set.h and version.h to public headers\n0e146c0468d Merge bitcoin-core/libmultiprocess#349: type-context: fix async disconnect race condition found by antithesis\n49f95e26326 Merge bitcoin-core/libmultiprocess#212: ci: add newdeps job testing newer versions of cmake and capnproto\n914dc839f27 proxy: fix data race between server request threads and disconnect handling\n275c8eefdfb Merge bitcoin-core/libmultiprocess#345: Remove trailing whitespace and Add -Wtrailing-whitespace to default ci config\ncd7162fb832 Merge bitcoin-core/libmultiprocess#304: proxy: fix BuildList to use non-const iteration for interface types\n9b136782af1 ci: Add -Wtrailing-whitespace to default config\n2f4be9ec6ea refactor: Remove trailing whitespace\n2448d282ccd cmake: add type-unordered-set.h and version.h to public headers\nb3fc922ee4a ci: add newdeps job testing newest versions of cmake and capnproto\n390b5f901f1 Merge bitcoin-core/libmultiprocess#344: test: listen_tests and connect_tests follow-ups\nd6f8588d1ab proxy: fix BuildList to use non-const iteration for interface types\ne18ca520f45 Merge bitcoin-core/libmultiprocess#343: test: fix race in connect_tests disconnect-deferred-failure test\nc39c7850c66 doc: note construct() call in valid init interface test\nb9c36c61751 test: close sockets unconditionally and check errors with KJ_SYSCALL\n7eb741e6359 test: drop unnecessary KJ_EXPECT(true)\n113f1d4d287 test: join server thread unconditionally in connect tests\n44bc4630bc1 test: drop mp:: prefixes in connect tests\n038d33eb31e test: share DefaultLogHandler between test files\nb54a1633085 test: drop TestSetup socket members in connect tests\n70467c5a727 test: add m_ prefix to TestSetup members in connect tests\ncc260f2526f test: replace capnp fix link with upstream PR\n137a6e4e039 test: fix race in connect_tests disconnect-deferred-failure test\n8dab0d4bdeb Merge bitcoin-core/libmultiprocess#341: ci: add -Wextra-semi to llvm config\nb3b134eed8b ci: add -Wextra-semi to llvm config\nbdd0cd69418 Merge bitcoin-core/libmultiprocess#339: refactor: add `[[noreturn]]` attributes\na779a09764c ci: add -Wmissing-noreturn\n636aaff576b refactor: add missing [[noreturn]] attributes\ncc11c2b1b41 Merge bitcoin-core/libmultiprocess#338: test: check ReadList return value\n2d6e863c77a Merge bitcoin-core/libmultiprocess#334: ci: Set CMAKE_BUILD_PARALLEL_LEVEL to enable parallelism by default\nd4d10ff98ab Merge bitcoin-core/libmultiprocess#332: ci: add -Wextra-semi to default config\nb540e70f25f Merge bitcoin-core/libmultiprocess#324: proxy: Name threads spawned by the event loop\ne5e367e785c Merge bitcoin-core/libmultiprocess#312: util: report back child errors to parent and throw\n2220df68c91 Merge bitcoin-core/libmultiprocess#298: Fix error handling when creating clients (`mp::ConnectStream`)\n51defb79ef7 Merge bitcoin-core/libmultiprocess#340: ci: Update `capnproto` prerequisites on NetBSD\n7e94790b08a ci: Update `capnproto` prerequisites on NetBSD\n9f25ffca5b0 test: Cover OS thread names for worker, pool, and async threads\n648a18589c4 proxy: Name threads spawned by the event loop\n49834b2609e ci: add -Wextra-semi to default config\nfae9a637e35 example: Remove unused kj/async.h include\nbb473690c97 Fix error handling when creating clients\n44d191420c6 Add test coverage for ConnectStream\n231361ae5af Correct stale UnixListener doc comment\n060c1a50d03 Extract `UnixListener` class to a dedicated file\n62f25af06c3 test: check ReadList return value\nce51d737255 ci: Set CMAKE_BUILD_PARALLEL_LEVEL to enable parallism in build jobs by default\n67302cd132a Merge bitcoin-core/libmultiprocess#331: Remove code for Cap'n Proto versions before 0.9\nf13c64ab54e Merge bitcoin-core/libmultiprocess#330: ci: Compile with minimum supported g++ in olddeps\n8e026f66252 Merge bitcoin-core/libmultiprocess#327: build: avoid unnecessary capnp-rpc dependency for mpgen\ne5206e9eb5b Merge bitcoin-core/libmultiprocess#325: cmake: Remove `QUIET` option from `find_package(CapnProto ...)`\n879efea2bc7 Merge bitcoin-core/libmultiprocess#321: ci: Roll NetBSD releases to 11.0, drop 9.4\nabf127a3141 Merge bitcoin-core/libmultiprocess#317: ipc: Fix mpgen capnp tool path for vcpkg/Windows builds\nc437d7f107e Merge bitcoin-core/libmultiprocess#310: test: cover immediate client disconnects for `ListenConnections`\n31bff8a673f Merge bitcoin-core/libmultiprocess#307: refactor: memcpy -> std::ranges::copy\nf355108b0a0 Merge bitcoin-core/libmultiprocess#303: type-chrono: Add CustomBuildField/CustomReadField overloads for std::chrono::time_point\n2d678177c14 Merge bitcoin-core/libmultiprocess#296: ci: Bump channel to nixos-26.05\n3f05b11624c util: kill and reap child on SpawnProcess error\n4a56c1837a7 util: report back child error to parent and throw\na9e70dbe775 ci: Add NetBSD release 11.0\n2d33b14fb0e ci: Switch to default compiler on NetBSD 9.4\n36f74002775 ci: Drop NetBSD release 9.4\nbd508311b56 refactor: Drop stray semicolons after function definitions\n788f17a8509 Remove code for Cap'n Proto versions before 0.9\n7402affd0ce ci: Pin oldeps config to older nixpkgs channel to compile older cmake with older gcc\nedf63435624 ci: Compile with minimum supported g++-11 in olddeps\nfa47449afe1 cmake: avoid unnecessary capnp-rpc dependency for mpgen\na494b764de5 cmake: Remove `QUIET` option from `find_package(CapnProto ...)`\n26452e02d75 refactor: memcpy -> std::ranges::copy\ne1dcc6eb182 Merge bitcoin-core/libmultiprocess#316: cmake: Fix stale codegen when mpgen binary changes\n7a72df02e2d type-chrono: Add CustomBuildField/CustomReadField overloads for std::chrono::time_point\n45b685c3f58 type-number, type-chrono: Fix static assert signed/unsigned comparisons\n45f6255975d type-number: exclude bool from the integral overload\n8d6d4649482 Merge bitcoin-core/libmultiprocess#315: Fix startup race in example\na6fc80d2547 Merge bitcoin-core/libmultiprocess#311: bugfix: clear FD_CLOEXEC in child instead of parent before fork\n496fb84e69f test: cover immediate client disconnects for `ListenConnections`\n36c6c63520e doc: Document reference-counted EventLoop lifetime\n3a997e113cf Fix startup race in mpexample\nf5c15ce33ff Merge bitcoin-core/libmultiprocess#323: refactor: access ThreadContext through CurrentThread(), ci: switch Bitcoin Core to master\n66298c737f4 ci: Switch back to Bitcoin Core's master branch\n86b48105018 refactor: access ThreadContext through CurrentThread()\neea9c64f6e1 cmake: Fix stale codegen when mpgen binary changes\na26a08496b8 cmake: Fix mpgen capnp tool path for vcpkg/Windows builds\n140d9ba6ff7 test: allow custom log handler in `ListenSetup`\n1e0c7ff9a51 util: Clear FD_CLOEXEC in child instead of parent before fork\n8550ee6a317 util, refactor: Add ChildFail helper for post-fork child errors\n17eab90b526 test: Fix typo in listen_tests.cpp\nce865a9ba86 refactor: Directly use value in CustomBuildField\n3f221b5bfd7 Merge bitcoin-core/libmultiprocess#274: Add nonunix platform support\n1b0f6056062 doc: Remove trailing whitespace\nd8f8ca3119f ipc: Wrap mpgen main() in try-catch to print errors\nfbe5a14ad46 ci: Check out bitcoin/bitcoin PR #35084 instead of master\n39d3690d83d types: Replace SFINAE with requires clauses to avoid MSVC C2039 error\nba68520203c proxy, refactor: Fix C4305 truncation warning in Accessor on MSVC\n1d81d47811e util, refactor: Fix PtrOrValue constructor for move-only types on MSVC\nb883fe1e527 proxy: Fix shutdownWrite() exception handling on macOS with dynamic libraries\n0012411ccc6 proxy: Call shutdownWrite() in Connection destructor\n38312ad1912 proxy, refactor: Change ConnectStream and ServeStream to accept stream objects\ne96d5d742ab proxy, refactor: Replace EventLoop wakeup fd integers with KJ stream objects\ndb4f9a3d739 cmake: Bump minimum required Cap'n Proto version to 0.9\n652934fb793 util, refactor: Add SocketPair() and use it in SpawnProcess\n1c6ef7a26c0 util, refactor: Do not fork() and exec() separately\n1389cf3132f util, refactor: Add SpawnConnectInfo type alias and use it\nc7ca1f00b62 util, refactor: Add SocketId type alias and use it\nbe46a35203c util, refactor: Add ProcessId type alias and use it\n91a78db7808 doc: Bump version 13 > 14\nfa2c56ec27f ci: Bump channel to nixos-26.05\n\ngit-subtree-dir: src/ipc/libmultiprocess\ngit-subtree-split: 4d454a81da61b1094cee939b80e5e2f9880d420d" }, { "sha": "567c2e020fd0bb115166bde963861b7bbbda5739", "date": "2026-09-08T08:13:51Z", "message": "Merge commit '4c842beaae2e97d7934800c8433da9632b21c0ff' into pr/subtree-14" }, { "sha": "d9cfcf89bb58e83ff9620e7cfaf896a5275dc217", "date": "2026-09-08T08:13:51Z", "message": "build: suppress -Wc++23-lambda-attributes in warn_interface\n\nLambda [[noreturn]] attributes before the parameter list are a C++23\nextension intentionally used in C++20 builds (needed for compatibility\nwith -Wmissing-noreturn). Suppress the extension warning rather than\nremoving the attributes or working around them.\n\nUses the existing IF_CHECK_PASSED idiom so GCC, which silently ignores\nunknown -Wno-* flags, is unaffected.\n\nCo-Authored-By: Claude Sonnet 4.6 " }, { "sha": "ae6b583256cd0972a09f38ecf65d0005dbd34028", "date": "2026-09-08T08:13:51Z", "message": "Add capnp serialization code for bitcoin types\n\n- Add capnp ToBlob, ToArray, Wrap, Serialize, and Unserialize helper functions\n- Add support for std::chrono::seconds capnp serialization\n- Add support for util::Result and util::Expected capnp serialization" }, { "sha": "4466e5ce9b7652f8af32dd70d89124be67626240", "date": "2026-09-08T08:13:51Z", "message": "Add capnp wrapper for Handler interface" }, { "sha": "7b997424a951e7421a8d44d8f9ba3733eeff9ec6", "date": "2026-09-08T08:13:51Z", "message": "Add capnp wrapper for Chain interface" }, { "sha": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "date": "2026-09-08T08:13:51Z", "message": "multiprocess: Expose Chain interface\n\nExpose Chain interface to external processes spawning or connecting to\nbitcoin-node." } ], "timeline": [ { "t": "2024-02-08T20:45:31Z", "kind": "force_push", "who": "ryanofsky", "commit": "2fd10424c04397e50c6683a82db8a0bb68e0f6cc" }, { "t": "2024-02-26T22:12:50Z", "kind": "review_comment", "who": "cbergqvist", "assoc": "CONTRIBUTOR", "path": "src/ipc/capnp/common-types.h", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "Nit: compiles with `value.has_value()` here, which is clearer than `operator bool()`. But maybe you were intending to support types which don't have `.has_value()`?" }, { "t": "2024-02-27T08:33:47Z", "kind": "review_comment", "who": "cbergqvist", "assoc": "CONTRIBUTOR", "path": "src/ipc/capnp/chain-types.h", "commit": "b372063241fbd34d27d062f3e438a3e425a9dfc5", "in_reply_to": null, "text": "Builds fine without `#include ` using `g++` on Linux?" }, { "t": "2024-02-28T13:51:28Z", "kind": "review_comment", "who": "cbergqvist", "assoc": "CONTRIBUTOR", "path": "src/ipc/capnp/common-types.h", "commit": "b372063241fbd34d27d062f3e438a3e425a9dfc5", "in_reply_to": null, "text": "Should this say ...\"vector\\ *and* GCSFilter::ElementSet set elements.\"?" }, { "t": "2024-02-28T13:56:58Z", "kind": "review", "who": "cbergqvist", "assoc": "CONTRIBUTOR", "state": "COMMENTED", "commit": "2fd10424c04397e50c6683a82db8a0bb68e0f6cc", "text": "I'm eager for multiprocess to get in, but unable to do in-depth reviews in tolerable time due to lack of domain-knowledge. Did a surface level review of 2fd1042. Hope you don't mind." }, { "t": "2024-02-28T15:25:51Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/ipc/capnp/common-types.h", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": 1503377237, "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#discussion_r1503377237\n\n[quoted text omitted]\nI mostly just don't agree it is clearer and I like the \"if value, use value\" pattern from c++ and python. I think it removes noise and makes code easier to read, also makes it easier for code to evolve, for example updating code using a plain pointer to switch to smart pointer.\n\nIn this case I am looking forward to this code working with `ResultPtr` from #26022, where operator bool and has_value have different meanings. Operator bool in that case is true if a pointer is contained AND the pointer value is not null. has_value is true in that case if a pointer is contained, whether or not it is null. After #26022, this code would look something like:\n\n```c++\nif (value) {\n BuildField(..., ValueAccessor, *value);\n}\nif (!value.has_value()) {\n BuildField(..., FailureAccessor, value.GetFailure());\n}\nBuildField(..., ErrorsAccessor, value.GetErrors());\nBuildField(..., WarningsAccessor, value.GetWarnings());\n```\n\nAnd if `value` is a `ResultPtr` the first line would need to be `if (value)` not `if value.has_value()` to work." }, { "t": "2024-02-28T15:26:01Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/ipc/capnp/chain-types.h", "commit": "b372063241fbd34d27d062f3e438a3e425a9dfc5", "in_reply_to": 1503832875, "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#discussion_r1503832875\n\n[quoted text omitted]\nGood catch, I think this must have been left over from a previous version of this file. Removed now." }, { "t": "2024-02-28T15:30:02Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/ipc/capnp/common-types.h", "commit": "b372063241fbd34d27d062f3e438a3e425a9dfc5", "in_reply_to": 1505998416, "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#discussion_r1505998416\n\n[quoted text omitted]\nI think it's technically correct because the the vectors _are_ the set elements but I changed the comment to make it clearer." }, { "t": "2024-02-28T16:08:29Z", "kind": "force_push", "who": "ryanofsky", "commit": "41831abe06d388ed18b5dbed739bc8fe76457f86" }, { "t": "2024-02-28T16:14:06Z", "kind": "review", "who": "ryanofsky", "assoc": "MEMBER", "state": "COMMENTED", "commit": "41831abe06d388ed18b5dbed739bc8fe76457f86", "text": "Thanks for the review!\n\nUpdated 2fd10424c04397e50c6683a82db8a0bb68e0f6cc -> 41831abe06d388ed18b5dbed739bc8fe76457f86 ([`pr/ipc-chain.2`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.2) -> [`pr/ipc-chain.3`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.3), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.2..pr/ipc-chain.3)) with suggested changes." }, { "t": "2024-02-28T16:58:02Z", "kind": "review", "who": "cbergqvist", "assoc": "CONTRIBUTOR", "state": "APPROVED", "commit": "41831abe06d388ed18b5dbed739bc8fe76457f86", "text": "Thanks for incorporating some of my suggestions. Surface-level ACK of 41831ab. :)" }, { "t": "2024-03-07T02:54:34Z", "kind": "review_comment", "who": "ariard", "assoc": "CONTRIBUTOR", "path": "src/ipc/capnp/common-types.h", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "i think `Wrap` could be parameterized with any `CAddress` version.\ne.g useful if someone wanna test the native crypto noise framework between bitcoin processes.\nor in the future experiment with better crypto-primitives for bip324." }, { "t": "2024-03-07T02:57:01Z", "kind": "review", "who": "ariard", "assoc": "CONTRIBUTOR", "state": "COMMENTED", "commit": "41831abe06d388ed18b5dbed739bc8fe76457f86", "text": "being able to work with any socket (TCP or UNIX) makes a lot of sense.\nyou could have `bitcoin-node` on some secure computing host.\nand then one or more `bitcoin-walet` on over-the-network hosts." }, { "t": "2024-06-11T01:53:09Z", "kind": "force_push", "who": "ryanofsky", "commit": "6608b033c060c17be204beb8227333421c091816" }, { "t": "2024-06-11T19:10:50Z", "kind": "force_push", "who": "ryanofsky", "commit": "ab6b795f218b2074a9c9c05fcc94ec37eccca5a5" }, { "t": "2024-07-05T10:14:06Z", "kind": "comment", "who": "sedited", "assoc": "MEMBER", "text": "I'm not sure what a good approach for reviewing this might be. How can I validate the changes without tests? Should I be running this as part of a parent pull request? The first two commits seem fairly mechanical, but the last one less so. The comments in the code are helpful, but some pointers in the PR description for what to look out for, or a broad description of the approaches taken would be helpful too. E.g. why is so much custom functionality introduced for `findBlock`?" }, { "t": "2024-07-08T16:38:44Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#issuecomment-2210605752\n\nThanks for the questions.\n\n[quoted text omitted]\nYou could test this as part of #10102, and I should probably add some unit test code to [ipc_test.cpp](https://github.com/bitcoin/bitcoin/blob/master/src/test/ipc_test.cpp) to make sure new runtime code in [capnp/chain.cpp](https://github.com/ryanofsky/bitcoin/tree/pr/ipc-chain/src/ipc/capnp/chain.cpp) and [capnp/common-types.h](https://github.com/ryanofsky/bitcoin/tree/pr/ipc-chain/src/ipc/capnp/common-types.h) functions has test coverage.\n\nMost of the code in the PR is evaluated at compile time though, so for example, if there is a mismatch in any of the interface declarations there will be build errors.\n\n[quoted text omitted]\nThis is helpful feedback, and I will try to add more comments. I know it needs more comments, but it's hard for me to know where to add them without being asked because I'm too familiar with everything here. This PR is a case where [\"Don't spend more than a few seconds trying to understand it\"](https://www.googblogs.com/code-health-understanding-code-in-review/) review really advice applies, so if something doesn't make sense, you should just ask so I can clarify. If something doesn't make sense to you, it probably doesn't make sense to other people either.\n\n[quoted text omitted]\nWill add a comment, but `Chain::findBlock` and the handful of other `Chain` methods taking [`FoundBlock`](https://github.com/ryanofsky/bitcoin/blob/ab6b795f218b2074a9c9c05fcc94ec37eccca5a5/src/interfaces/chain.h#L50-L81) input/output arguments need custom code because these are converted to [`FoundBlockParam`](https://github.com/ryanofsky/bitcoin/blob/ab6b795f218b2074a9c9c05fcc94ec37eccca5a5/src/ipc/capnp/chain.capnp#L150-L159) and [`FoundBlockResult`](https://github.com/ryanofsky/bitcoin/blob/ab6b795f218b2074a9c9c05fcc94ec37eccca5a5/src/ipc/capnp/chain.capnp#L161-L171) Cap'n Proto structs to make IPC calls, and these structs are recursive. Libmultiprocess has decent support for converting back and forth between C++ classes and capnp structs generally, but it would be hard for it support recursive structs. It also might have a hard time in this case because there is a not 1:1 mapping between fields in the c++ class and capnp structs. So the conversion for these types is completely custom.\n\nSimilar custom code also exists for the [C++ `BlockInfo`](https://github.com/ryanofsky/bitcoin/blob/ab6b795f218b2074a9c9c05fcc94ec37eccca5a5/src/interfaces/chain.h#L83-L97) struct which is complicated to translate to the [Capnp `BlockInfo`](https://github.com/ryanofsky/bitcoin/blob/ab6b795f218b2074a9c9c05fcc94ec37eccca5a5/src/ipc/capnp/chain.capnp#L173-L184) struct, because it has internal pointers and references, so it has [custom code](https://github.com/ryanofsky/bitcoin/blob/ab6b795f218b2074a9c9c05fcc94ec37eccca5a5/src/ipc/capnp/chain.cpp#L113-L164) because it can't really be converted automatically." }, { "t": "2024-07-26T16:05:16Z", "kind": "force_push", "who": "ryanofsky", "commit": "eec0d31850aa1f7c520a46c417320f480f23fb1c" }, { "t": "2024-07-26T16:19:38Z", "kind": "review_comment", "who": "sedited", "assoc": "MEMBER", "path": "src/ipc/capnp/common-types.h", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "Just a question: From what I gathered so far `UniValue` is required in these interfaces for error handling (like here) and to pass around the ban map. Is that correct? It seems unfortunate to me that `UniValue` types end up in the interfaces and need to be handled here. Is the intention to eventually refactor this?" }, { "t": "2024-07-26T16:29:15Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/ipc/capnp/common-types.h", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": 1515411394, "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#discussion_r1515411394\n\n[quoted text omitted]\nFor now the Wrap function is basically a workaround for not having a serialization option that says \"serialize all the data in this object to a stream, I don't care about the specific serialization format.\" So the formats here just chosen to preserve all data, and don't really matter otherwise.\n\nBut I could imagine use-cases like you are suggesting where we may want to customize which serialization format is used depending on the IPC connection. I think it would not be that hard to do by adding parameters to Wrap, which is not called many places, or by writing different CustomReadField/BuildField overloads which do not call Wrap. For now though the easiest thing is for the wrapped stream to just hardcode parameters that serialize all the data." }, { "t": "2024-07-26T16:34:51Z", "kind": "review", "who": "ryanofsky", "assoc": "MEMBER", "state": "COMMENTED", "commit": "eec0d31850aa1f7c520a46c417320f480f23fb1c", "text": "Updated ab6b795f218b2074a9c9c05fcc94ec37eccca5a5 -> eec0d31850aa1f7c520a46c417320f480f23fb1c ([`pr/ipc-chain.5`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.5) -> [`pr/ipc-chain.6`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.6), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.5-rebase..pr/ipc-chain.6)), rebasing and dropping no longer needed code after libmultiprocess update, adding comments and tests, and splitting up commits. There is still more to do to splitting up commits and adding tests, however.\n\nThis PR now shares a little bit of code with #30510, so will get smaller if #30510 is merged. #30510 is also simpler and should be easier to review, so will mark this as a draft, although feedback is still welcome on this PR especially if there are questions or things that need more explanation.\n\n---\n\nre: https://github.com/bitcoin/bitcoin/pull/29409#pullrequestreview-1921347149\n\n[quoted text omitted]\nYes this PR does not actually expose a socket but #30509 does, and #19460 uses it for the wallet (and #19461 uses it for the gui, and https://github.com/Sjors/bitcoin/pull/48 and https://github.com/bitcoin/bitcoin/pull/30437 use it for the mining interface" }, { "t": "2024-07-26T17:11:03Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/ipc/capnp/common-types.h", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": 1693315482, "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#discussion_r1693315482\n\n[quoted text omitted]\nIn general there are lots of ways current interfaces are not ideal and can be improved over time, to improve performance (especially to reduce round trips), reduce dependencies, and provide more flexibility.\n\nOn UniValue specifically, handling UniValue exceptions could go away if wallet processes would start their own RPC servers on their own ports instead of getting RPC requests forwarded to them by the bitcoin-node process. That wouldn't be hard to do, but it would be a UI change, and there's a chicken and egg problem because it doesn't really make sense to make wallets listen on different ports before wallets are able to run in separate processes.\n\nUniValue is also used to pass settings between processes. For example when GUI settings are changed, the GUI calls the updateRwSetting() function which takes a univalue parameter to save the setting. In this case I think it makes sense for the interface to use univalues, since the settings are saved as JSON, though of course alternatives are possible and might be more ideal.\n\nFor the ban map, maybe univalue is not ideal for some reason, but it also might be better than defining a new serialization format. I don't see a problem with the current approach in any of these cases, but making changes is always possible" }, { "t": "2024-07-26T17:16:47Z", "kind": "force_push", "who": "ryanofsky", "commit": "43dc39eed47d83b2b7e72c911198bbdd401c78d8" }, { "t": "2024-08-07T10:40:23Z", "kind": "comment", "who": "josibake", "assoc": "MEMBER", "text": "Small nit: can you update the description with what you mention in https://github.com/bitcoin/bitcoin/pull/29409#pullrequestreview-2202254574 , regarding #30509 ? I was surprised to see this PR in draft and it took me a bit of digging in the comments to learn why. It's more clear when reading the \"process separation\" issue, but I think it would also be helpful to mention in this PR description." }, { "t": "2024-08-07T14:43:54Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#issuecomment-2273166427\n\nThanks! Added following to the description:\n\n[quoted text omitted]" }, { "t": "2024-09-19T10:43:13Z", "kind": "force_push", "who": "ryanofsky", "commit": "65c4edda94ead5c20969681f8337fd6a735182cc" }, { "t": "2024-09-19T10:56:40Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "Rebased 43dc39eed47d83b2b7e72c911198bbdd401c78d8 -> 65c4edda94ead5c20969681f8337fd6a735182cc ([`pr/ipc-chain.7`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.7) -> [`pr/ipc-chain.8`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.8), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.7-rebase..pr/ipc-chain.8)) due to conflicts with #30697 and #30454\nRebased 65c4edda94ead5c20969681f8337fd6a735182cc -> 968f14fc7a634f65f4399dc042a37d4a39f2c703 ([`pr/ipc-chain.8`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.8) -> [`pr/ipc-chain.9`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.9), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.8-rebase..pr/ipc-chain.9)) after base PR #30510 merged" }, { "t": "2024-09-26T14:00:53Z", "kind": "force_push", "who": "ryanofsky", "commit": "968f14fc7a634f65f4399dc042a37d4a39f2c703" }, { "t": "2024-09-26T17:16:13Z", "kind": "comment", "who": "josibake", "assoc": "MEMBER", "text": "Concept ACK\n\nThanks for the rebase, I'll be digging into this next week!" }, { "t": "2024-11-08T12:17:10Z", "kind": "review_comment", "who": "sedited", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "b372063241fbd34d27d062f3e438a3e425a9dfc5", "in_reply_to": null, "text": "Looking at the usage of this endpoint I am wondering if it is even necessary? I.e. instead of getting it first and using it for `chainStateFlushed`, the `chainStateFlushed` implementation could just do that internally.\n\nMore generally I have been wondering if it would be a good idea to eventually strongly type these `Data` blobs (and similarly the enums)? For example here, wrapping it in a `BlockLocator` type. I don't think this is relevant as long as libmultiprocess is used to create the c++ wrappers, which do have the full data types, but I am not sure how other languages would do this if they were used as clients to the interfaces eventually. Do you know how this could look like?" }, { "t": "2024-11-08T12:43:01Z", "kind": "review_comment", "who": "sedited", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "b372063241fbd34d27d062f3e438a3e425a9dfc5", "in_reply_to": null, "text": "Nit: Shouldn't this be called `txid`?" }, { "t": "2024-11-08T12:54:50Z", "kind": "review_comment", "who": "sedited", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "b372063241fbd34d27d062f3e438a3e425a9dfc5", "in_reply_to": null, "text": "How does this `write` argument here map to the `action` argument in the c++ interface? They seem to have different types." }, { "t": "2024-11-08T12:57:57Z", "kind": "review_comment", "who": "sedited", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "d9efd1e49d1df154970b6a60229eedde3ba7cffe", "in_reply_to": null, "text": "Why is the `role` typed as `UInt32` when the other enums are typed as `Int32`?" }, { "t": "2024-11-08T13:05:56Z", "kind": "review_comment", "who": "sedited", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "Should this include the version as well at this point?" }, { "t": "2024-11-12T13:55:56Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "b372063241fbd34d27d062f3e438a3e425a9dfc5", "in_reply_to": 1834309312, "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#discussion_r1834309312\n\n[quoted text omitted]\nCurrent usages are a little unusual because chainStateFlushed() is used in the wallet both to receive notifications from the node about when to flush, but also internally in the wallet to flush its own data. I'm not sure if I understand the exact code change you are suggesting, but it could be reasonable and I also have a PR #29652 which removes getTipLocator and getActiveChainLocator.\n\n[quoted text omitted]\nYes all that makes sense. The tradeoff is just that defining capnproto structs for all the serialized classes adds more code that will need to be maintained, so I think it should probably be done selectively whenever use cases arise, probably by adding new versions of methods using new types. These changes can be implemented incrementally as needed, instead of all up front." }, { "t": "2024-11-12T13:59:24Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "b372063241fbd34d27d062f3e438a3e425a9dfc5", "in_reply_to": 1834348410, "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#discussion_r1834348410\n\n[quoted text omitted]\nNice catch, fixed! Might be a good idea to make sure these names are correct, even though they are just documentation and don't affect behavior." }, { "t": "2024-11-12T15:58:26Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "b372063241fbd34d27d062f3e438a3e425a9dfc5", "in_reply_to": 1834362068, "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#discussion_r1834362068\n\n[quoted text omitted]\nThis is a bug, and it should have been caught by the libmultiprocess library. https://github.com/chaincodelabs/libmultiprocess/pull/120 adds a static_assert to ensure that it would result in a compile error if a specified capnproto type is ever not compatible with a c++ enum type." }, { "t": "2024-11-12T16:02:02Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "d9efd1e49d1df154970b6a60229eedde3ba7cffe", "in_reply_to": 1834365825, "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#discussion_r1834365825\n\n[quoted text omitted]\nNow changed this to `Int32` to be consistent. Probably `UInt32` was used because this parameter was added at a later time than all the other code was written. The exact integer type used to represent the enum doesn't actually matter as long as it is wide enough to hold all the enum values, and as long as round-trip static casts from the enum type to the int type and back return the same enum value. After https://github.com/chaincodelabs/libmultiprocess/pull/120 it should also be a compile error if incompatible types are used" }, { "t": "2024-11-12T16:05:20Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": 1834376651, "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#discussion_r1834376651\n\n[quoted text omitted]\nYes, good catch. Added the version field and added a comment to JSONRPCRequest struct to prevent this type of bug in the future. I think this bug did not matter too much in practice because this capnp struct is only used to forward RPC requests from the node to the wallet and wallet shouldn't respond to requests differently based on JSONRPC version, but it is still a bug in the serialization that should be fixed." }, { "t": "2024-11-12T16:26:25Z", "kind": "force_push", "who": "ryanofsky", "commit": "34d3e2a6eaaab9de5328c3e64739f1392696c7db" }, { "t": "2024-11-12T16:27:40Z", "kind": "review", "who": "ryanofsky", "assoc": "MEMBER", "state": "COMMENTED", "commit": "34d3e2a6eaaab9de5328c3e64739f1392696c7db", "text": "Updated 968f14fc7a634f65f4399dc042a37d4a39f2c703 -> 34d3e2a6eaaab9de5328c3e64739f1392696c7db ([`pr/ipc-chain.9`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.9) -> [`pr/ipc-chain.10`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.10), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.9..pr/ipc-chain.10)) with review suggestions and fixes.\n\nThanks for the review!" }, { "t": "2024-11-19T11:47:01Z", "kind": "review", "who": "sedited", "assoc": "MEMBER", "state": "APPROVED", "commit": "34d3e2a6eaaab9de5328c3e64739f1392696c7db", "text": "lgtm ACK 34d3e2a6eaaab9de5328c3e64739f1392696c7db" }, { "t": "2024-12-04T20:33:54Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "Added 1 commit 34d3e2a6eaaab9de5328c3e64739f1392696c7db -> 395d5eed0475558de2c2a66914d5a5814ce38f3c ([`pr/ipc-chain.10`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.10) -> [`pr/ipc-chain.11`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.11), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.10...pr/ipc-chain.11)) exposing the Chain interface so it is easier to experiment with.\nUpdated 395d5eed0475558de2c2a66914d5a5814ce38f3c -> 64b833854a34d87cde4e0ca4173d75012c401a7a ([`pr/ipc-chain.11`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.11) -> [`pr/ipc-chain.12`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.12), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.11..pr/ipc-chain.12)) fixing FoundBlock locator serialization to fix `wallet_backup.py --descriptors` test failure in followup #10102 https://cirrus-ci.com/task/6269118947524608?logs=ci#L2529 in new test added #30678" }, { "t": "2024-12-05T14:50:46Z", "kind": "review_comment", "who": "darosior", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "What is the use for an `updatedBlockTip` notification with no information about the new tip?" }, { "t": "2024-12-06T12:57:31Z", "kind": "force_push", "who": "ryanofsky", "commit": "64b833854a34d87cde4e0ca4173d75012c401a7a" }, { "t": "2024-12-06T19:58:45Z", "kind": "comment", "who": "darosior", "assoc": "MEMBER", "text": "In order to test this PR i implemented a PoC of a Rust wallet (using [`BDK`](https://github.com/bitcoindevkit/)) consuming the `Chain` interface introduced here. I think it's also a good example of what multiprocess enables. See https://github.com/darosior/core_bdk_wallet." }, { "t": "2024-12-09T21:18:51Z", "kind": "review_comment", "who": "darosior", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "b372063241fbd34d27d062f3e438a3e425a9dfc5", "in_reply_to": null, "text": "Why are the `CFeeRate` serialized as `Data` whereas the other `CAmount` are `Int64`?" }, { "t": "2024-12-09T22:10:01Z", "kind": "review_comment", "who": "sedited", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": 1871523229, "text": "Adding this here for context: I guess one of the benefits of the `Notifications` and `NotificationsProxy` is avoiding raw pointer types in these interfaces. I went through the exercise of removing the pointer types from the validation interface before. Maybe this could eliminate the need for the logic in the `NotificationsProxy` in the first place. Not having to handle pointer types is also useful for the kernel API, where conveying the semantics of these pointers in the notifications to the using developer is tricky." }, { "t": "2024-12-09T22:12:12Z", "kind": "comment", "who": "darosior", "assoc": "MEMBER", "text": "tested ACK 395d5eed0475558de2c2a66914d5a5814ce38f3c\n\nI've tested this with the Rust wallet PoC i mentioned earlier: https://github.com/bitcoin/bitcoin/pull/29409#issuecomment-2524055170. This tool exercises the following methods: `getHeight`, `getBlockHash`, `hasBlocks`, `findAncestorByHeight`, `findAncestorByHash`, `findCommonAncestor`, `initMessage`, `showProgress` and `handleNotifications`. It also exercises all the `ChainNotifications` events.\n\nI tested numerous scenarii with this tool on regtest (some are documented [here](https://github.com/darosior/core_bdk_wallet?tab=readme-ov-file#3-build-the-rust-wallet-connect-it-and-test-a-few-scenarii)). I then proceeded to scan some existing Signet wallets while syncing a Signet node, as well as performing a rescan on a synced Signet node. I did not find any issue with this PR in all those tests (no crash, i get accurate wallet information and events under various conditions). I found a crash in #10102, but it's specific to the new logic introduced there and i could not reproduce it using this PR.\n\nI cursory-reviewed the rest of the interface not exercised in my Rust wallet and did not find any issue." }, { "t": "2024-12-09T22:25:33Z", "kind": "review", "who": "sedited", "assoc": "MEMBER", "state": "APPROVED", "commit": "64b833854a34d87cde4e0ca4173d75012c401a7a", "text": "Re-ACK 64b833854a34d87cde4e0ca4173d75012c401a7a\n\n[quoted text omitted]\nI should have seen that one though :| - good that those tests exist!" }, { "t": "2024-12-16T16:30:01Z", "kind": "comment", "who": "darosior", "assoc": "MEMBER", "text": "I found another segmentation fault in updating my previous ACK to the latest tip of this PR. Here are minimal steps to reproduce:\n1. Run a `bitcoin-node` from this PR. I tested on regtest with: `./multiprocbuild/src/bitcoin-node -regtest -datadir=$PWD/datadir_bdk_wallet -server=0 -ipcbind=unix -debug=ipc`\n2. Have a client connect. I used my tool for this. See usage [here](https://github.com/darosior/core_bdk_wallet?tab=readme-ov-file#usage). The command i ran: `cargo run -- ../bitcoin/datadir_bdk_wallet/regtest/node.sock`.\n3. Stop the `bitcoin-node` process. It will hang waiting for the client to exit.\n4. Stop the client. The `bitcoin-node` process will segfault.\n\nHere are the debug logs of `bitcoin-node` from when the client connected to the segfault.\n\nClick to see logs\n\n```\n2024-12-16T16:19:22Z Loading 1 mempool transactions from file...\n2024-12-16T16:19:22Z Loading addresses from DNS seed dummySeed.invalid.\n2024-12-16T16:19:22Z Imported mempool transactions from file: 1 succeeded, 0 failed, 0 expired, 0 already there, 0 waiting for initial broadcast\n2024-12-16T16:19:22Z initload thread exit\n2024-12-16T16:19:22Z 0 addresses found from DNS seeds\n2024-12-16T16:19:22Z dnsseed thread exit\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server recv request #1 Init.construct$Params ()\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server send response #1 Init.construct$Results (threadMap = )\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server recv request #2 Init.makeChain$Params (context = (thread = ))\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server post request #2 {bitcoin-node-8814/b-capnp-loop-8842 (from )}\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server send response #2 Init.makeChain$Results (result = )\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server recv request #3 Chain.initMessage$Params (context = (thread = ), message = \"Oxydation of the Bitcoin Core wallet in progress..\")\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server post request #3 {bitcoin-node-8814/b-capnp-loop-8842 (from )}\n2024-12-16T16:19:26Z init message: Oxydation of the Bitcoin Core wallet in progress..\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server send response #3 Chain.initMessage$Results ()\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server recv request #4 Chain.showProgress$Params (context = (thread = ), title = \"BDK Core startup\", progress = 1, resumePossible = false)\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server post request #4 {bitcoin-node-8814/b-capnp-loop-8842 (from )}\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server send response #4 Chain.showProgress$Results ()\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server recv request #5 Chain.getHeight$Params (context = (thread = ))\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server post request #5 {bitcoin-node-8814/b-capnp-loop-8842 (from )}\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server send response #5 Chain.getHeight$Results (result = 113, hasResult = true)\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server recv request #6 Chain.getBlockHash$Params (context = (thread = ), height = 113)\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server post request #6 {bitcoin-node-8814/b-capnp-loop-8842 (from )}\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server send response #6 Chain.getBlockHash$Results (result = \"H\\\\3678\\\\307#\\\\020|\\\\020\\\\017\\\\340\\\\2469\\\\330\\\\356\\\\335\\\\277\\\\341dOB{\\\\220\\\\327\\\\354[\\\\361\\\\036\\\\233\\\\301\\\\035DD\")\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server recv request #7 Chain.showProgress$Params (context = (thread = ), title = \"BDK Core startup\", progress = 100, resumePossible = true)\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server post request #7 {bitcoin-node-8814/b-capnp-loop-8842 (from )}\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server send response #7 Chain.showProgress$Results ()\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server recv request #8 Chain.handleNotifications$Params (context = (thread = ), notifications = )\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server post request #8 {bitcoin-node-8814/b-capnp-loop-8842 (from )}\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server send response #8 Chain.handleNotifications$Results (result = )\n2024-12-16T16:19:26Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server destroy N2mp11ProxyServerIN3ipc5capnp8messages7HandlerEEE\n^C2024-12-16T16:19:27Z tor: Thread interrupt\n2024-12-16T16:19:27Z Shutdown: In progress...\n2024-12-16T16:19:27Z addcon thread exit\n2024-12-16T16:19:27Z opencon thread exit\n2024-12-16T16:19:27Z torcontrol thread exit\n2024-12-16T16:19:27Z net thread exit\n2024-12-16T16:19:27Z msghand thread exit\n2024-12-16T16:19:27Z DumpAnchors: Flush 0 outbound block-relay-only peer addresses to anchors.dat started\n2024-12-16T16:19:27Z DumpAnchors: Flush 0 outbound block-relay-only peer addresses to anchors.dat completed (0.00s)\n2024-12-16T16:19:27Z scheduler thread exit\n2024-12-16T16:19:27Z Writing 1 mempool transactions to file...\n2024-12-16T16:19:27Z Writing 0 unbroadcast transactions to file.\n2024-12-16T16:19:27Z Dumped mempool: 0.000s to copy, 0.002s to dump, 289 bytes dumped to file\n2024-12-16T16:19:27Z Flushed fee estimates to fee_estimates.dat.\n2024-12-16T16:19:27Z [ipc] {bitcoin-node-8814/b-shutoff-8814} IPC client first request from current thread, constructing waiter\n2024-12-16T16:19:27Z [ipc] {bitcoin-node-8814/b-shutoff-8814} IPC client send ChainNotifications.chainStateFlushed$Params (context = (thread = , callbackThread = ), role = 0, locator = \"\\\\200\\\\021\\\\001\\\\000\\\\022H\\\\3678\\\\307#\\\\020|\\\\020\\\\017\\\\340\\\\2469\\\\330\\\\356\\\\335\\\\277\\\\341dOB{\\\\220\\\\327\\\\354[\\\\361\\\\036\\\\233\\\\301\\\\035DD\\\\tGm\\\\237]YbZDV9\\\\254\\\\252f\\\\205\\\\001\\\\323K\\\\375!\\\\340\\\\t\\\\367\\\\375\\\\346\\\\264W\\\\207\\\\000\\\\2101\\\\035:\\\\314\\\\233\\\\246\\\\275\\\\207\\\\v\\\\\\\\\\\\\\\\\\\\343\\\\202\\\\026\\\\274\\\\037\\\\213\\\\314\\\\303V\\\\2116<*+\\\\352\\\\255\\\\026\\\\204M\\\\332\\\\340\\\\nT\\\\306\\\\360Pa\\\\304\\\\002\\\\024\\\\356\\\\247\\\\220\\\\263\\\\257l\\\\230\\\\350\\\\362\\\\027Yl\\\\300\\\\316lk\\\\232\\\\f\\\\333\\\\235,\\\\234\\\\336\\\\204+JE\\\\263>\\\\237\\\\177\\\\305z\\\\017\\\\252\\\\311@\\\\341e\\\\026\\\\300dk\\\\305\\\\212V\\\\334\\\\377\\\\004cb\\\\217p\\\\n\\\\307w\\\\0046\\\\2261|\\\\024\\\\\\\\N\\\\336\\\\223G\\\\263~n\\\\271\\\\256\\\\264\\\\346\\\\227\\\\301\\\\032\\\\301\\\\030\\\\bw\\\\241Z.\\\\302\\\\261\\\\027 \\\\005\\\\374B\\\\357R\\\\231\\\\237Ct\\\\324\\\\232I\\\\322\\\\370\\\\303T\\\\253\\\\205\\\\354\\\\233\\\\337\\\\031C\\\\3215O\\\\3746\\\\016\\\\360b &\\\\300\\\\201\\\\244U\\\\221\\\\306 Pql+c\\\\212\\\\2524\\\\314a\\\\t\\\\216\\\\275=\\\\230b\\\\207ouv[\\\\365(\\\\3...\n2024-12-16T16:19:27Z [ipc] {bitcoin-node-8814/b-shutoff-8814} IPC client recv ChainNotifications.chainStateFlushed$Results ()\n2024-12-16T16:19:27Z Shutdown: done\n2024-12-16T16:19:32Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server destroy N2mp11ProxyServerIN3ipc5capnp8messages5ChainEEE\n2024-12-16T16:19:32Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server: socket disconnected.\n2024-12-16T16:19:32Z [ipc] {bitcoin-node-8814/b-capnp-loop-8816} IPC server destroy N2mp11ProxyServerIN3ipc5capnp8messages4InitEEE\nSegmentation fault\n```" }, { "t": "2025-01-15T19:02:16Z", "kind": "review", "who": "Big621", "assoc": "NONE", "state": "APPROVED", "commit": "64b833854a34d87cde4e0ca4173d75012c401a7a", "text": "" }, { "t": "2025-01-15T19:03:03Z", "kind": "review", "who": "Big621", "assoc": "NONE", "state": "APPROVED", "commit": "64b833854a34d87cde4e0ca4173d75012c401a7a", "text": "" }, { "t": "2025-02-10T19:21:49Z", "kind": "comment", "who": "pseudoramdom", "assoc": "MEMBER", "text": "Hi @ryanofsky! I'm new to this and I'm looking to test the feature on macOS. Couple of questions -\n1. Can I use the branch as is or would I need to rebase on `master` since I see some related changes like #31740, #31552 landed on `master`.\n2. Do I need to install `libmultiprocess` from source or is `MULTIPROCESS=1` needed? I see some related work in #31741 . Would I benefit from that?\n\nI tried building on this branch rebased on `master` and I got the following errors while building.\n\n ```\nmake -C depends HOST=aarch64-apple-darwin MULTIPROCESS=1 NO_QT=1\ncmake -B multiprocbuild/ --toolchain=depends/$HOST_PLATFORM/toolchain.cmake -DWITH_MULTIPROCESS=ON\n```\n\nBuild config\n\n```\nConfigure summary\n=================\nExecutables:\n bitcoind ............................ ON\n bitcoin-node (multiprocess) ......... ON\n bitcoin-qt (GUI) .................... OFF\n bitcoin-gui (GUI, multiprocess) ..... OFF\n bitcoin-cli ......................... ON\n bitcoin-tx .......................... ON\n bitcoin-util ........................ ON\n bitcoin-wallet ...................... ON\n bitcoin-chainstate (experimental) ... OFF\n libbitcoinkernel (experimental) ..... OFF\nOptional features:\n wallet support ...................... ON\n - descriptor wallets (SQLite) ...... ON\n - legacy wallets (Berkeley DB) ..... ON\n external signer ..................... ON\n ZeroMQ .............................. ON\n USDT tracing ........................ OFF\n QR code (GUI) ....................... OFF\n DBus (GUI, Linux only) .............. OFF\nTests:\n test_bitcoin ........................ ON\n test_bitcoin-qt ..................... OFF\n bench_bitcoin ....................... OFF\n fuzz binary ......................... OFF\n\nCross compiling ....................... TRUE, for Darwin, aarch64\nC++ compiler .......................... Clang 19.1.7, /opt/homebrew/opt/llvm/bin/clang++\nCMAKE_BUILD_TYPE ...................... RelWithDebInfo\nPreprocessor defined macros ........... OBJC_OLD_DISPATCH_PROTOTYPES=0\nC++ compiler flags .................... -pipe -std=c++20 -mmacos-version-min=13.0 -arch arm64 -O2 -O2 -g -std=c++20 -fPIC -fdebug-prefix-map=/Users/pseudoramdom/Developer/Projects/bitcoin/src=. -fmacro-prefix-map=/Users/pseudoramdom/Developer/Projects/bitcoin/src=. -Wall -Wextra -Wgnu -Wformat -Wformat-security -Wvla -Wshadow-field -Wthread-safety -Wloop-analysis -Wredundant-decls -Wunused-member-function -Wdate-time -Wconditional-uninitialized -Woverloaded-virtual -Wsuggest-override -Wimplicit-fallthrough -Wunreachable-code -Wdocumentation -Wself-assign -Wundef -Wno-unused-parameter -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -Wstack-protector -fstack-protector-all -mbranch-protection=bti\nLinker flags .......................... -pipe -std=c++20 -mmacos-version-min=13.0 -arch arm64 -O2 -O2 -g -L/opt/homebrew/opt/llvm/lib -Wl,-dead_strip -Wl,-dead_strip_dylibs -Wl,-headerpad_max_install_names -fstack-protector-all -Wl,-fixup_chains -fPIE -Xlinker -pie\n\nNOTE: The summary above may not exactly match the final applied build flags\n if any additional CMAKE_* or environment variables have been modified.\n To see the exact flags applied, build with the --verbose option.\n\nAttempt to harden executables ......... ON\nTreat compiler warnings as errors ..... OFF\nUse ccache for compiling .............. OFF\n\n-- Configuring done (9.5s)\n-- Generating done (0.2s)\n-- Build files have been written to: /Users/pseudoramdom/Developer/Projects/bitcoin/multiprocbuild\n```\n\nSample build errors\n\n```\nIn file included from /Users/pseudoramdom/Developer/Projects/bitcoin/src/test/ipc_test_types.h:8:\n/Users/pseudoramdom/Developer/Projects/bitcoin/src/ipc/capnp/common-types.h:218:25: error: no member named 'ReadDestValue' in namespace 'mp'\n 218 | mp::ReadDestValue(error));\n | ~~~~^\n\nIn file included from /Users/pseudoramdom/Developer/Projects/bitcoin/multiprocbuild/src/ipc/capnp/common.capnp.proxy-types.h:7:\n/Users/pseudoramdom/Developer/Projects/bitcoin/src/ipc/capnp/common-types.h:218:25: error: no member named 'ReadDestValue' in namespace 'mp'\n 218 | mp::ReadDestValue(error));\n | ~~~~^\n\n/Users/pseudoramdom/Developer/Projects/bitcoin/src/ipc/capnp/chain.cpp:131:9: error: no member named 'BuildOne' in namespace 'mp'\n 131 | mp::BuildOne<0>(mp::TypeList(), invoke_context, builder, block);\n | ~~~~^\n```\n\nP.S. let me know if this isn't the right place to discuss this." }, { "t": "2025-02-10T19:53:47Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#issuecomment-2649015969\n\n[quoted text omitted]\nHi @pseudoramdom, definitely it should be easiest to just check out this branch and use it as is. The errors that you are seeing with the branch rebased happen due to https://github.com/chaincodelabs/libmultiprocess/pull/135, and require some code changes here to be compatible. I should be able to update this branch in the next day or two in case you do need other changes from master.\n\n[quoted text omitted]\nThese are two different alternatives described in https://github.com/bitcoin/bitcoin/blob/master/doc/multiprocess.md#installation.\n\nThe first one described there is to use just the use [depends system](https://github.com/bitcoin/bitcoin/tree/master/depends) (the depends system is a mini-package manager used to download dependencies and build releases) with option `MULTIPROCESS=1`\n\nThe second one described there is to install capnproto and libmultiprocess manually.\n\nA third approach implemented in #31741 should make all of this a lot easier because libmultiprocess sources will be included as a subtree and won't have to be downloaded separately. But #31741 won't be compatible with this PR until this PR is rebased.\n\n[quoted text omitted]\nAnywhere is fine with me, and feel free to open new issues in https://github.com/chaincodelabs/libmultiprocess/issues/new if you have any questions or feedback. Thanks for trying this." }, { "t": "2025-02-11T03:42:17Z", "kind": "force_push", "who": "ryanofsky", "commit": "4fa7f72cb9d8f0290f56293989ec6ea950162c5b" }, { "t": "2025-02-11T03:44:39Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "Rebased 64b833854a34d87cde4e0ca4173d75012c401a7a -> 4fa7f72cb9d8f0290f56293989ec6ea950162c5b ([`pr/ipc-chain.12`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.12) -> [`pr/ipc-chain.13`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.13), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.12-rebase..pr/ipc-chain.13)) due to various conflicts.\n\n@pseudoramdom, with this update, errors you posted should be resolved" }, { "t": "2025-02-11T19:43:44Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#issuecomment-2546088852\n\n[quoted text omitted]\nThis seems closely related to the _broken connection during node shutdown causing unclean shutdown_ issue reported earlier so added a note about this there: https://github.com/chaincodelabs/libmultiprocess/issues/123#issuecomment-2651851492" }, { "t": "2025-05-24T10:24:45Z", "kind": "review_comment", "who": "zaidmstrr", "assoc": "CONTRIBUTOR", "path": "src/ipc/capnp/chain.capnp", "commit": "b372063241fbd34d27d062f3e438a3e425a9dfc5", "in_reply_to": null, "text": "This new PR https://github.com/bitcoin/bitcoin/pull/32438/commits/fa62a013a558338dc6ee5fb4cfd6fc7c782c301b removes this `flush()` from the codebase. I think it should also be removed from `chain.capnp` otherwise it will give build errors." }, { "t": "2025-06-03T20:08:10Z", "kind": "force_push", "who": "ryanofsky", "commit": "f92422e308ec33e2b211b866e218efacc77a4f7f" }, { "t": "2025-06-03T20:09:08Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "Rebased 4fa7f72cb9d8f0290f56293989ec6ea950162c5b -> f92422e308ec33e2b211b866e218efacc77a4f7f ([`pr/ipc-chain.13`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.13) -> [`pr/ipc-chain.14`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.14), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.13-rebase..pr/ipc-chain.14)) due to silent conflicts with #32438 and #32641" }, { "t": "2025-07-21T12:03:37Z", "kind": "comment", "who": "zaidmstrr", "assoc": "CONTRIBUTOR", "text": "The method `rpcRunLater` was removed in [commit](https://github.com/bitcoin/bitcoin/commit/fcfd3db563e89fd79820a4cdfa102d624d801de1#diff-8e9fef4d0718d085f31da382899d97e3bbefc8d6a72ede95916a0e2fbd1a532f), thus there are some build errors." }, { "t": "2025-07-21T13:35:32Z", "kind": "review_comment", "who": "maflcko", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.cpp", "commit": "b372063241fbd34d27d062f3e438a3e425a9dfc5", "in_reply_to": null, "text": "implementat -> implement [spelling error in comment \u201c\u2026able to implementat a ReadField\u2026\u201d]" }, { "t": "2025-07-24T16:18:03Z", "kind": "force_push", "who": "ryanofsky", "commit": "c0d9515a3aef468bf4c5949c419ab1c9bab0dfa3" }, { "t": "2025-07-24T16:19:51Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "Rebased f92422e308ec33e2b211b866e218efacc77a4f7f -> c0d9515a3aef468bf4c5949c419ab1c9bab0dfa3 ([`pr/ipc-chain.14`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.14) -> [`pr/ipc-chain.15`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.15), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.14-rebase..pr/ipc-chain.15)) to fix silent merge conflict with #32862 and spelling error. (Thanks zaidmstrr and maflcko for pointing these out!)" }, { "t": "2025-07-24T20:18:18Z", "kind": "comment", "who": "maflcko", "assoc": "MEMBER", "text": "For reference, the lint task still fails. Not sure if this is intentional or if you missed it." }, { "t": "2025-07-28T14:25:25Z", "kind": "force_push", "who": "ryanofsky", "commit": "b372063241fbd34d27d062f3e438a3e425a9dfc5" }, { "t": "2025-07-28T14:29:20Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#issuecomment-3114802810\n\n[quoted text omitted]\nThanks! The lint task was failing in https://cirrus-ci.com/task/5047676548415488 because the subtree was modified. The subtree was modified to work around a bug fixed in https://github.com/bitcoin-core/libmultiprocess/pull/181 which is part of https://github.com/bitcoin/bitcoin/pull/32345 but not currently part of master. Implemented a different workaround for now.\n\n---\n\nUpdated c0d9515a3aef468bf4c5949c419ab1c9bab0dfa3 -> b372063241fbd34d27d062f3e438a3e425a9dfc5 ([`pr/ipc-chain.15`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.15) -> [`pr/ipc-chain.16`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.16), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.15..pr/ipc-chain.16)) to fix failing lint task" }, { "t": "2025-09-24T12:43:03Z", "kind": "comment", "who": "sedited", "assoc": "MEMBER", "text": "I tried rebasing this PR, but I'm getting a bunch of compilation errors. Can you rebase it @ryanofsky?" }, { "t": "2025-09-24T13:55:39Z", "kind": "force_push", "who": "ryanofsky", "commit": "7ba7ec9d08927f244da8d5c1a7a1d7ced3239465" }, { "t": "2025-09-24T14:01:54Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "Rebased b372063241fbd34d27d062f3e438a3e425a9dfc5 -> 7ba7ec9d08927f244da8d5c1a7a1d7ced3239465 ([`pr/ipc-chain.16`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.16) -> [`pr/ipc-chain.17`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.17), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.16-rebase..pr/ipc-chain.17)) due to conflicts with #33169 and #32345" }, { "t": "2025-09-29T09:20:41Z", "kind": "comment", "who": "sedited", "assoc": "MEMBER", "text": "Thanks for the rebase :)\n\nI updated darosior's [core_bdk_wallet](https://github.com/darosior/core_bdk_wallet?tab=readme-ov-file#generating-rust-ipc-interface-from-capnp-definition) to use this newest version and I ran into a few crashes again. This is the one I managed to get a reproducible backtrace for:\n\nCrash backtrace + ipc debug logging\n\n```\n2025-09-29T11:18:20Z [ipc] {bitcoin-node-165737/b-capnp-loop-165742} IPC server post request #32 {bitcoin-node-165737/b-capnp-loop-166141 (from )}\n2025-09-29T11:18:20Z [ipc] {bitcoin-node-165737/b-capnp-loop-165742} IPC server send response #32 Chain.handleNotifications$Results (result = )\n2025-09-29T11:18:20Z [ipc] {bitcoin-node-165737/b-capnp-loop-165742} IPC server destroy N2mp11ProxyServerIN3ipc5capnp8messages7HandlerEEE\n2025-09-29T11:18:20Z [ipc] {bitcoin-node-165737/b-capnp-loop-165873} IPC client destroy N2mp11ProxyClientIN3ipc5capnp8messages18ChainNotificationsEEE\n2025-09-29T11:18:20Z [ipc] {bitcoin-node-165737/b-capnp-loop-165873} IPC client first request from current thread, constructing waiter\n2025-09-29T11:18:20Z [ipc] {bitcoin-node-165737/b-capnp-loop-165873} IPC client send ChainNotifications.destroy$Params (context = (thread = , callbackThread = ))\n2025-09-29T11:18:20Z [ipc] {bitcoin-node-165737/b-capnp-loop-165742} IPC server destroy N2mp11ProxyServerIN3ipc5capnp8messages5ChainEEE\n2025-09-29T11:18:20Z [ipc] IPC client method call interrupted by disconnect.\nterminate called after throwing an instance of 'ipc::Exception'\n what(): IPC client method call interrupted by disconnect.\n[Thread 0x7ffed37fe6c0 (LWP 166141) exited]\n2025-09-29T11:18:20Z [ipc] {bitcoin-node-165737/b-capnp-loop-165742} IPC server: socket disconnected.\n2025-09-29T11:18:20Z [ipc] {bitcoin-node-165737/b-capnp-loop-165742} IPC server destroy N2mp11ProxyServerIN3ipc5capnp8messages4InitEEE\n\nThread 45 \"b-capnp-loop\" received signal SIGABRT, Aborted.\n[Switching to Thread 0x7ffed2ffd6c0 (LWP 165873)]\n__pthread_kill_implementation (no_tid=0, signo=6, threadid=) at ./nptl/pthread_kill.c:44\nwarning: 44\t./nptl/pthread_kill.c: No such file or directory\n(gdb) bt\n#0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=) at ./nptl/pthread_kill.c:44\n#1 __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78\n#2 __GI___pthread_kill (threadid=, signo=signo@entry=6) at ./nptl/pthread_kill.c:89\n#3 0x00007ffff724527e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26\n#4 0x00007ffff72288ff in __GI_abort () at ./stdlib/abort.c:79\n#5 0x00007ffff76a5ff5 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6\n#6 0x00007ffff76bb0da in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6\n#7 0x00007ffff76a5a55 in std::terminate() () from /lib/x86_64-linux-gnu/libstdc++.so.6\n#8 0x000055555563c47f in __clang_call_terminate ()\n#9 0x0000555555b39999 in mp::ProxyClientBase::~ProxyClientBase (this=0x7ffed40cfe60)\n at ./ipc/libmultiprocess/include/mp/proxy-io.h:468\n#10 0x0000555555b36e9f in mp::ProxyClient::~ProxyClient (this=0x28769)\n at /home/drgrid/bitcoin/build_dev_mode_clang/src/ipc/capnp/chain.capnp.proxy-types.c++:12\n#11 0x000055555575637e in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x7ffed40049a0)\n at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/shared_ptr_base.h:346\n#12 std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=)\n at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/shared_ptr_base.h:1071\n#13 std::__shared_ptr::~__shared_ptr (this=)\n at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/shared_ptr_base.h:1524\n#14 node::(anonymous namespace)::NotificationsProxy::~NotificationsProxy (this=) at ./node/interfaces.cpp:456\n#15 0x0000555555755fbc in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x7ffed4000d80)\n at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/shared_ptr_base.h:346\n#16 std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=)\n at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/shared_ptr_base.h:1071\n#17 std::__shared_ptr::~__shared_ptr (this=)\n at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/shared_ptr_base.h:1524\n#18 std::__shared_ptr::reset (this=0x7ffed4005a50)\n at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/shared_ptr_base.h:1642\n#19 node::(anonymous namespace)::NotificationsHandlerImpl::disconnect (this=0x7ffed4005a40) at ./node/interfaces.cpp:496\n#20 0x0000555555755e47 in node::(anonymous namespace)::NotificationsHandlerImpl::~NotificationsHandlerImpl (this=0x7ffed4005a40) at ./node/interfaces.cpp:491\n#21 node::(anonymous namespace)::NotificationsHandlerImpl::~NotificationsHandlerImpl (this=0x28769) at ./node/interfaces.cpp:491\n#22 0x0000555555b49cb7 in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release (this=0x7ffed4004d00)\n at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/shared_ptr_base.h:346\n#23 std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=)\n at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/shared_ptr_base.h:1071\n#24 std::__shared_ptr::~__shared_ptr (this=)\n at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/shared_ptr_base.h:1524\n#25 std::__shared_ptr::reset (this=0x7fffe801c3e0)\n at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/shared_ptr_base.h:1642\n#26 mp::ProxyServerBase::~ProxyServerBase()::{lambda()#1}::operator()() (this=0x7fffe801c3e0)\n at ./ipc/libmultiprocess/include/mp/proxy-io.h:514\n#27 std::__invoke_impl::~ProxyServerBase()::{lambda()#1}&>(std::__invoke_other, mp::ProxyServerBase::~ProxyServerBase()::{lambda()#1}&) (__f=...) at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/invoke.h:61\n#28 std::__invoke_r::~ProxyServerBase()::{lambda()#1}&>(mp::ProxyServerBase::~ProxyServerBase()::{lambda()#1}&) (__fn=...) at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/invoke.h:111\n#29 std::_Function_handler::~ProxyServerBase()::{lambda()#1}>::_M_invoke(std::_Any_data const&) (\n __functor=...) at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/std_function.h:290\n#30 0x0000555555f41979 in std::function::operator()() const (this=0x7ffed2ffca70) at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/std_function.h:591\n#31 mp::Unlock const&>(mp::Lock&, std::function const&) (lock=..., callback=...) at ./ipc/libmultiprocess/include/mp/util.h:209\n#32 0x0000555555f3f56f in mp::EventLoop::startAsyncThread()::$_0::operator()() const (this=) at ./ipc/libmultiprocess/src/mp/proxy.cpp:298\n#33 std::__invoke_impl(std::__invoke_other, mp::EventLoop::startAsyncThread()::$_0&&) (__f=...)\n at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/invoke.h:61\n#34 std::__invoke(mp::EventLoop::startAsyncThread()::$_0&&) (__fn=...)\n at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/invoke.h:96\n#35 std::thread::_Invoker >::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=)\n at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/std_thread.h:292\n#36 std::thread::_Invoker >::operator()() (this=)\n at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/std_thread.h:299\n#37 std::thread::_State_impl > >::_M_run() (this=)\n at /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/std_thread.h:244\n#38 0x00007ffff76ecdb4 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6\n#39 0x00007ffff729caa4 in start_thread (arg=) at ./nptl/pthread_create.c:447\n#40 0x00007ffff7329c6c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78\n```" }, { "t": "2025-09-29T11:09:10Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "[quoted text omitted]\n\nUnfortunately, I don't think this is a meaningful backtrace, since it is just showing the trace of a thread at the time it receives a SIGPIPE signal (`Thread 3 \"b-capnp-loop\" received signal SIGPIPE, Broken pipe.`), which happens fairly normally during disconnections. It's usually best to suppress these signals in GDB with `gdb -ex \"handle SIGPIPE nostop noprint pass\" ...`" }, { "t": "2025-09-29T11:20:34Z", "kind": "comment", "who": "sedited", "assoc": "MEMBER", "text": "Err, right. Updated the description with your suggested trace filtering." }, { "t": "2025-09-29T14:17:18Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "[quoted text omitted]\n\nThanks created https://github.com/bitcoin-core/libmultiprocess/issues/219 to track this (feel free to create new issues directly in the future). Thanks for updating the rust client, too!" }, { "t": "2025-09-30T13:58:07Z", "kind": "force_push", "who": "ryanofsky", "commit": "7a526a161fdb31a04b0afaaa112a137b9a595977" }, { "t": "2025-09-30T13:58:46Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "Updated 7ba7ec9d08927f244da8d5c1a7a1d7ced3239465 -> 7a526a161fdb31a04b0afaaa112a137b9a595977 ([`pr/ipc-chain.17`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.17) -> [`pr/ipc-chain.18`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.18), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.17..pr/ipc-chain.18)) to fix clang-tidy errors https://github.com/bitcoin/bitcoin/actions/runs/17978986033/job/51139663003?pr=29409\n\nUpdated 7a526a161fdb31a04b0afaaa112a137b9a595977 -> 2ae18d058562dd494f88328c6907c31c5d68b04e ([`pr/ipc-chain.18`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.18) -> [`pr/ipc-chain.19`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.19), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.18..pr/ipc-chain.19)) to fix silent conflict with #32660\n\nRebased 2ae18d058562dd494f88328c6907c31c5d68b04e -> 2763976d96663fcf013832cfbf771fd4050924ee ([`pr/ipc-chain.19`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.19) -> [`pr/ipc-chain.20`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.20), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.19-rebase..pr/ipc-chain.20))\n\nRebased 2763976d96663fcf013832cfbf771fd4050924ee -> d9efd1e49d1df154970b6a60229eedde3ba7cffe ([`pr/ipc-chain.20`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.20) -> [`pr/ipc-chain.21`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.21), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.20-rebase..pr/ipc-chain.21)) due to silent conflicts with #33567 and #33218" }, { "t": "2025-09-30T17:09:25Z", "kind": "review_comment", "who": "l0rinc", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "Could we add a simple explanation comment for these salts?" }, { "t": "2025-09-30T17:26:41Z", "kind": "review_comment", "who": "l0rinc", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "I wonder how schema evolution is handled by Cap'n Proto - what happens if a field is deprecated and removed or new values are inserted, do I have to check all existing values to make sure I can find a new valid id?\n\nhttps://capnproto.org/language.html#evolving-your-protocol claims:\n* New fields, enumerants, and methods may be added to structs, enums, and interfaces, respectively, as long as each new member\u2019s number is larger than all previous members. Similarly, new fields may be added to existing groups and unions.\n* New parameters may be added to a method. The new parameters must be added to the end of the parameter list and must have default values.\n* Members can be re-arranged in the source code, so long as their numbers stay the same.\n\nSo I guess if you change any value and deprecate the old one you will have to add the new version with max + 1 - wanted to suggest that we could add 10 opportunities between values like:\n```\n destroy @10 ...\n getHeight @20...\n```\nso that when we change `destroy` to return a bool or add a new method, we can do it as:\n```\n construct @0 ...\n destroy @10 ... # deprecated\n destruct @11 ...\n getHeight @20...\n```\nbut it appears that's not possible." }, { "t": "2025-10-21T17:25:07Z", "kind": "force_push", "who": "ryanofsky", "commit": "2ae18d058562dd494f88328c6907c31c5d68b04e" }, { "t": "2025-10-22T09:28:49Z", "kind": "force_push", "who": "ryanofsky", "commit": "2763976d96663fcf013832cfbf771fd4050924ee" }, { "t": "2025-11-20T18:51:11Z", "kind": "force_push", "who": "ryanofsky", "commit": "d9efd1e49d1df154970b6a60229eedde3ba7cffe" }, { "t": "2025-11-22T16:52:56Z", "kind": "review_comment", "who": "l0rinc", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "d9efd1e49d1df154970b6a60229eedde3ba7cffe", "in_reply_to": null, "text": "super-nit: I assume the copyright headers are similar to other code in the repo:\n```suggestion\n# Copyright (c) 2024-present The Bitcoin Core developers\n# Distributed under the MIT software license, see the accompanying\n# file COPYING or https://opensource.org/license/mit.\n```" }, { "t": "2025-11-25T12:01:01Z", "kind": "review_comment", "who": "l0rinc", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "d9efd1e49d1df154970b6a60229eedde3ba7cffe", "in_reply_to": null, "text": "May be deliberate, but the parameters in\nhttps://github.com/bitcoin/bitcoin/blob/5fe753b56f450b054c42227c5df8346c72447490/src/interfaces/chain.h#L267\nare 32 bit" }, { "t": "2025-11-25T12:02:35Z", "kind": "review_comment", "who": "l0rinc", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "Original has enums for `reason`\nhttps://github.com/bitcoin/bitcoin/blob/5fe753b56f450b054c42227c5df8346c72447490/src/interfaces/chain.h#L323\n\nshould we make the param `UInt32` like we did one line below for `ChainstateRole`\n```suggestion\n transactionRemovedFromMempool @2 (context :Proxy.Context, tx :Data, reason :UInt32) -> ();\n```\n\nOr vice versa, since `Int32` seems more common (though `UInt32` may make more sense).\n\nBut looking at https://github.com/bitcoin/bitcoin/pull/29409#discussion_r1838364191, you mentioned:\n[quoted text omitted]\n\nwhich was merged since - shouldn't it be a compile error now?" }, { "t": "2025-11-25T12:10:59Z", "kind": "review_comment", "who": "l0rinc", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "d9efd1e49d1df154970b6a60229eedde3ba7cffe", "in_reply_to": null, "text": "The original param name is `delta_seconds` (where it doesn't make sense, since it's typed), but here it would, since it's not obvious what `Int64` should contain otherwise (could be epoch millis as well as far as I can tell).\n\nhttps://github.com/bitcoin/bitcoin/blob/5fe753b56f450b054c42227c5df8346c72447490/src/interfaces/chain.h#L426" }, { "t": "2025-11-25T12:18:29Z", "kind": "review_comment", "who": "l0rinc", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "If this corresponds to\nhttps://github.com/bitcoin/bitcoin/blob/5fe753b56f450b054c42227c5df8346c72447490/src/rpc/server.h#L50\nwe might want to ment why this one doesn't have a corresponding proxy:\n```suggestion\n# transport-only struct corresponding to `std::pair` in `CRPCCommand` constructor\nstruct RPCArg {\n```" }, { "t": "2025-11-25T12:19:29Z", "kind": "review_comment", "who": "l0rinc", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "d9efd1e49d1df154970b6a60229eedde3ba7cffe", "in_reply_to": null, "text": "same, should likely be\n\n```suggestion\n mode @3 :Int32;\n```" }, { "t": "2025-11-25T12:20:34Z", "kind": "review_comment", "who": "l0rinc", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "Is this an accurate mapping of\nhttps://github.com/bitcoin/bitcoin/blob/5fe753b56f450b054c42227c5df8346c72447490/src/rpc/request.h#L55\n?" }, { "t": "2025-11-25T12:21:32Z", "kind": "review_comment", "who": "l0rinc", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "d9efd1e49d1df154970b6a60229eedde3ba7cffe", "in_reply_to": null, "text": "Is this still used after https://github.com/bitcoin/bitcoin/pull/29409#issuecomment-3096459508?" }, { "t": "2025-11-25T12:23:41Z", "kind": "review_comment", "who": "l0rinc", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "d9efd1e49d1df154970b6a60229eedde3ba7cffe", "in_reply_to": null, "text": "in `FoundBlockParam` this is a bool\nhttps://github.com/bitcoin/bitcoin/blob/d9efd1e49d1df154970b6a60229eedde3ba7cffe/src/ipc/capnp/chain.capnp#L161\nalso in\nhttps://github.com/bitcoin/bitcoin/blob/5fe753b56f450b054c42227c5df8346c72447490/src/interfaces/chain.h#L72" }, { "t": "2025-11-25T12:26:38Z", "kind": "review_comment", "who": "l0rinc", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "b7b6d6c316221f86914316e82e593fc35df1c92d", "in_reply_to": null, "text": "`best_height` seems to be missing:\nhttps://github.com/bitcoin/bitcoin/blob/1a7fb5eeeef3575c1e7c27915c9b98695191299d/src/policy/fees/block_policy_estimator.h#L98\nintroduced in\nhttps://github.com/bitcoin/bitcoin/commit/1a7fb5eeeef3575c1e7c27915c9b98695191299d#diff-722dfe5b8bcfb83b1d2f2c9b10800a873325eac8dfc343239f6c851220508c4eR98" }, { "t": "2025-11-25T13:04:58Z", "kind": "review_comment", "who": "l0rinc", "assoc": "MEMBER", "path": "src/interfaces/chain.h", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "Do we have to wait for `SettingsValue` to be exposed for the other consts to be removed as well?\nLooks a bit weird that this isn't consted anymore, while other similar ones still are:\nhttps://github.com/bitcoin/bitcoin/blob/5336bcd5784925cd722cff4b9c28e58c64c0b708/src/interfaces/node.h#L111-L116" }, { "t": "2025-11-25T13:07:19Z", "kind": "review_comment", "who": "l0rinc", "assoc": "MEMBER", "path": "src/rpc/request.h", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "can't we auto-detect that via reflection maybe?" }, { "t": "2025-11-25T13:26:51Z", "kind": "review_comment", "who": "l0rinc", "assoc": "MEMBER", "path": "src/ipc/capnp/common-types.h", "commit": "d9efd1e49d1df154970b6a60229eedde3ba7cffe", "in_reply_to": null, "text": "while `ToArray` seems to be used mostly for `uint256`, there are lots of `DataStream` calls to it which is not `base_blob`\n```suggestion\n//! Convert contiguous byte data (e.g. base_blob, DataStream) to kj::ArrayPtr.\n```" }, { "t": "2025-11-25T13:33:00Z", "kind": "review_comment", "who": "l0rinc", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.cpp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "is this still accurate?" }, { "t": "2025-11-25T13:43:02Z", "kind": "review", "who": "l0rinc", "assoc": "MEMBER", "state": "CHANGES_REQUESTED", "commit": "d9efd1e49d1df154970b6a60229eedde3ba7cffe", "text": "Rebased locally and did a first pass through the changes.\nIt seems to me the `capnp` wrapper needs some updates (missing field, 32/64 bit params, param rename, bool vs uint64, enums as unsigned, optional mapping, unused declarations, comments, etc).\n\nUnrelated nit: while checking the code I noticed that `RemoveCvRef` and `std::remove_cv_t 89cf624fe811d90d43f22d4519d859716d3ea958 ([`pr/ipc-chain.21`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.21) -> [`pr/ipc-chain.22`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.22), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.21-rebase..pr/ipc-chain.22)) fixing conflict with #33774 and making suggested updates\n\nRebased 89cf624fe811d90d43f22d4519d859716d3ea958 -> b2cbdd3c3297c5981895c7546fbfcbf1ea14fd02 ([`pr/ipc-chain.22`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.22) -> [`pr/ipc-chain.23`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.23), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.22-rebase..pr/ipc-chain.23))" }, { "t": "2025-12-16T02:09:40Z", "kind": "force_push", "who": "ryanofsky", "commit": "b2cbdd3c3297c5981895c7546fbfcbf1ea14fd02" }, { "t": "2026-01-06T20:58:39Z", "kind": "force_push", "who": "ryanofsky", "commit": "b7b6d6c316221f86914316e82e593fc35df1c92d" }, { "t": "2026-01-06T20:59:51Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "Rebased b2cbdd3c3297c5981895c7546fbfcbf1ea14fd02 -> b7b6d6c316221f86914316e82e593fc35df1c92d ([`pr/ipc-chain.23`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.23) -> [`pr/ipc-chain.24`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.24), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.23-rebase..pr/ipc-chain.24)) due to silent conflict with #30214\n\nRebased b7b6d6c316221f86914316e82e593fc35df1c92d -> 46bc59f581bd90f3b0f73be86a913afadc022bb0 ([`pr/ipc-chain.24`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.24) -> [`pr/ipc-chain.25`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.25), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.24-rebase..pr/ipc-chain.25)) due to conflict with #34568 and moving struct definitions from chain > common due to node interface now using them with bitcoin-core/gui#807\n\nUpdated 46bc59f581bd90f3b0f73be86a913afadc022bb0 -> 5c2b520f6b7a2e14048df093c834410077c250bb ([`pr/ipc-chain.25`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.25) -> [`pr/ipc-chain.26`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.26), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.25..pr/ipc-chain.26)) to fix missing include https://github.com/bitcoin/bitcoin/actions/runs/22499750543/job/65183484335?pr=29409\n\nRebased 5c2b520f6b7a2e14048df093c834410077c250bb -> e66150d2e4833ad2d6cf4955b3c793449c326494 ([`pr/ipc-chain.26`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.26) -> [`pr/ipc-chain.27`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.27), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.26-rebase..pr/ipc-chain.27)) including https://github.com/bitcoin-core/libmultiprocess/pull/247 to fix sanitizer CI failure (https://github.com/bitcoin/bitcoin/actions/runs/22501264518/job/65188721708?pr=29409#step:11:2216) caused by https://github.com/bitcoin/bitcoin/pull/34660 and LLVM bug\n\nUpdated e66150d2e4833ad2d6cf4955b3c793449c326494 -> 22f2c9a0d8817276c5738271b6389f47a9023809 ([`pr/ipc-chain.27`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.27) -> [`pr/ipc-chain.28`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.28), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.27..pr/ipc-chain.28)) cherry-picking fix from #34422 to fix macos CI error https://github.com/bitcoin/bitcoin/actions/runs/22555221663/job/65331380982?pr=29409\n\nRebased 22f2c9a0d8817276c5738271b6389f47a9023809 -> 6e3ecc8f05b8ae7fc405fea353652c120a210fbe ([`pr/ipc-chain.28`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.28) -> [`pr/ipc-chain.29`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.29), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.28-rebase..pr/ipc-chain.29)) due to conflicts\n\nRebased 6e3ecc8f05b8ae7fc405fea353652c120a210fbe -> 6833d5f2b49fed8182160c5996ae94d7dfb476a1 ([`pr/ipc-chain.29`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.29) -> [`pr/ipc-chain.30`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.30), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.29-rebase..pr/ipc-chain.30)) to fix tidy error https://github.com/bitcoin/bitcoin/actions/runs/23811319241/job/69398846880\n\nRebased 6833d5f2b49fed8182160c5996ae94d7dfb476a1 -> 9aee0eac079b93534e89e0c4b69767f36416fd71 ([`pr/ipc-chain.30`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.30) -> [`pr/ipc-chain.31`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.31), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.30-rebase..pr/ipc-chain.31)) due to conflicts with #35661 and #34020\n\nUpdated 9aee0eac079b93534e89e0c4b69767f36416fd71 -> 2eb914c6341591661b1632901c3e7b3991214d7a ([`pr/ipc-chain.31`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.31) -> [`pr/ipc-chain.32`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.32), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.31..pr/ipc-chain.32)) to fix CI: missing includes for Coin and CBlockLocator in chain-types.h https://github.com/bitcoin/bitcoin/actions/runs/29296250380/job/86970302189\n\nRebased 2eb914c6341591661b1632901c3e7b3991214d7a -> e914744ebacf73a5d1ab93e190ac40ccc470dd0c ([`pr/ipc-chain.32`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.32) -> [`pr/ipc-chain.33`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.33), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.32-rebase..pr/ipc-chain.33)) due to silent conflict with #34075\n\nRebased e914744ebacf73a5d1ab93e190ac40ccc470dd0c -> c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330 ([`pr/ipc-chain.33`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.33) -> [`pr/ipc-chain.34`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.34), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.33-rebase..pr/ipc-chain.34)) due to conflicts with #36176" }, { "t": "2026-02-27T19:00:09Z", "kind": "force_push", "who": "ryanofsky", "commit": "46bc59f581bd90f3b0f73be86a913afadc022bb0" }, { "t": "2026-02-27T19:46:12Z", "kind": "force_push", "who": "ryanofsky", "commit": "5c2b520f6b7a2e14048df093c834410077c250bb" }, { "t": "2026-03-01T23:18:02Z", "kind": "force_push", "who": "ryanofsky", "commit": "e66150d2e4833ad2d6cf4955b3c793449c326494" }, { "t": "2026-03-02T00:57:59Z", "kind": "force_push", "who": "ryanofsky", "commit": "22f2c9a0d8817276c5738271b6389f47a9023809" }, { "t": "2026-03-04T17:34:32Z", "kind": "comment", "who": "sedited", "assoc": "MEMBER", "text": "I'm curious to check if this https://github.com/bitcoin/bitcoin/pull/29409#issuecomment-3345899017 is now fixed once this is rebased." }, { "t": "2026-03-31T17:42:26Z", "kind": "force_push", "who": "ryanofsky", "commit": "6e3ecc8f05b8ae7fc405fea353652c120a210fbe" }, { "t": "2026-03-31T18:51:17Z", "kind": "force_push", "who": "ryanofsky", "commit": "6833d5f2b49fed8182160c5996ae94d7dfb476a1" }, { "t": "2026-04-01T10:23:57Z", "kind": "comment", "who": "Sjors", "assoc": "MEMBER", "text": "I think we need to consider if shipping capnp files for this (complete) interface is the right move. But in order to not distract from the code review here, I opened a separate issue - that turned into a bit of an essay: #34981" }, { "t": "2026-04-20T13:32:09Z", "kind": "comment", "who": "sedited", "assoc": "MEMBER", "text": "Updated darosior's core_bdk_wallet again, and bitcoin-node still crashes on disconnect:\n\nClick for backtrace\n\n```\n2026-04-20T13:27:37Z [ipc] {bitcoin-node-589794/b-capnp-loop-589798} IPC server destroy N2mp11ProxyServerIN3ipc5capnp8messages5ChainEEE\n[Thread 0x7fff54ff96c0 (LWP 590165) exited]\n\nThread 3 \"b-capnp-loop\" received signal SIGPIPE, Broken pipe.\n[Switching to Thread 0x7ffff61fe6c0 (LWP 589798)]\n0x00007ffff73298cb in __GI___writev (iovcnt=2, iov=0x7ffff61fc130, fd=26) at ../sysdeps/unix/sysv/linux/writev.c:26\nwarning: 26\t../sysdeps/unix/sysv/linux/writev.c: No such file or directory\n(gdb) bt\n#0 0x00007ffff73298cb in __GI___writev (iovcnt=2, iov=0x7ffff61fc130, fd=26) at ../sysdeps/unix/sysv/linux/writev.c:26\n#1 __GI___writev (fd=26, iov=0x7ffff61fc130, iovcnt=2) at ../sysdeps/unix/sysv/linux/writev.c:24\n#2 0x00007ffff7c8b987 in ?? () from /lib/x86_64-linux-gnu/libkj-async-1.0.1.so\n#3 0x00007ffff7c8c394 in ?? () from /lib/x86_64-linux-gnu/libkj-async-1.0.1.so\n#4 0x00007ffff7da696f in capnp::writeMessages(kj::AsyncOutputStream&, kj::ArrayPtr const> >) ()\n from /lib/x86_64-linux-gnu/libcapnp-rpc-1.0.1.so\n#5 0x00007ffff7da6e1c in capnp::BufferedMessageStream::writeMessages(kj::ArrayPtr const> >) ()\n from /lib/x86_64-linux-gnu/libcapnp-rpc-1.0.1.so\n#6 0x00007ffff7da4865 in capnp::MessageStream::writeMessages(kj::ArrayPtr) () from /lib/x86_64-linux-gnu/libcapnp-rpc-1.0.1.so\n#7 0x00007ffff7df9419 in capnp::TwoPartyVatNetwork::OutgoingMessageImpl::send()::{lambda()#1}::operator()() const::{lambda()#1}::operator()() const ()\n from /lib/x86_64-linux-gnu/libcapnp-rpc-1.0.1.so\n#8 0x00007ffff7e03e4a in ?? () from /lib/x86_64-linux-gnu/libcapnp-rpc-1.0.1.so\n#9 0x00007ffff7c4161d in kj::_::TransformPromiseNodeBase::get(kj::_::ExceptionOrValue&) () from /lib/x86_64-linux-gnu/libkj-async-1.0.1.so\n#10 0x00007ffff7c4245d in kj::_::ChainPromiseNode::fire() () from /lib/x86_64-linux-gnu/libkj-async-1.0.1.so\n#11 0x00007ffff7c38509 in kj::EventLoop::turn() () from /lib/x86_64-linux-gnu/libkj-async-1.0.1.so\n#12 0x00007ffff7c3e6c9 in kj::_::waitImpl(kj::Own&&, kj::_::ExceptionOrValue&, kj::WaitScope&, kj::SourceLocation) ()\n from /lib/x86_64-linux-gnu/libkj-async-1.0.1.so\n#13 0x00005555561d6220 in kj::Promise::wait (this=, waitScope=..., location=...) at /usr/include/kj/async-inl.h:1357\n#14 0x00005555561d2bd2 in mp::EventLoop::loop (this=0x555556b9e378) at /home/drgrid/bitcoin/src/ipc/libmultiprocess/src/mp/proxy.cpp:244\n#15 0x0000555555ae97b4 in ipc::capnp::(anonymous namespace)::CapnpProtocol::startLoop(char const*)::{lambda()#1}::operator()() const (this=0x555556b9fff8)\n at /home/drgrid/bitcoin/src/ipc/capnp/protocol.cpp:136\n#16 std::__invoke_impl(std::__invoke_other, ipc::capnp::(anonymous namespace)::CapnpProtocol::startLoop(char const*)::{lambda()#1}&&) (__f=...) at /usr/lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/invoke.h:61\n#17 std::__invoke(ipc::capnp::(anonymous namespace)::CapnpProtocol::startLoop(char const*)::{lambda()#1}&&) (__fn=...) at /usr/lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/invoke.h:96\n#18 std::thread::_Invoker >::_M_invoke<0ul>(std::_Index_tuple<0ul>) (\n this=0x555556b9fff8) at /usr/lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/std_thread.h:292\n#19 std::thread::_Invoker >::operator()() (this=0x555556b9fff8)\n at /usr/lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/std_thread.h:299\n#20 std::thread::_State_impl > >::_M_run() (this=0x555556b9fff0)\n at /usr/lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/std_thread.h:244\n#21 0x00007ffff76ecdb4 in ?? () from /lib/x86_64-linux-gnu/libstdc++.so.6\n#22 0x00007ffff729caa4 in start_thread (arg=) at ./nptl/pthread_create.c:447\n#23 0x00007ffff7329c6c in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78\n(gdb)\n```" }, { "t": "2026-04-21T15:38:20Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "[quoted text omitted]\n\nThanks, this is expected and https://github.com/bitcoin-core/libmultiprocess/issues/219 was created earlier to track this. Rust wallet is not disconnecting cleanly and some destructors need to be marked noexcept to prevent this" }, { "t": "2026-04-27T18:23:23Z", "kind": "review_comment", "who": "xyzconstant", "assoc": "CONTRIBUTOR", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "Out of scope for this PR, just raising this out of curiosity:\n\nI'm working on [an IPC extractor for peer-observer](https://github.com/peer-observer/peer-observer/pull/379), a non-wallet client that consumes `bitcoin-node`'s interfaces for monitoring. While extending it to cover the Chain interface exposed in this PR, I started to think whether such a tool could fit the `ChainClient` contract. The [doc-comment on ChainClient](https://github.com/bitcoin/bitcoin/blob/ad3f73862bdbee0aac106fa9e08c4181ce78ba47/src/interfaces/chain.h#L395-L396) specifically states this:\n\n[quoted text omitted]\nThree of those methods feel pretty wallet-shaped: `registerRpcs()`, `verify()` and `load()`. A non-wallet implementer wouldn't necessarily expose RPCs or have saved state to load/verify.\n\nWould it be worth reducing `ChainClient` to just lifecycle + mock-time hooks and moving the rest to `WalletLoader`? Genuinely curious whether there's prior context I'm missing." }, { "t": "2026-05-07T16:12:18Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": 3149370792, "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#discussion_r3149370792\n\n[quoted text omitted]\nIt's a good question. The doc comment is too ambiguous and should be improved. `ChainClient` declares methods that `bitcoin-node` calls and wallets and indexes can implement. It's used in #10102 to let `bitcoin-node` start a `bitcoin-wallet` process and control it. In the future the node could also start other processes (indexes, etc) and use this interface to control them. `ChainClient` probably isn't as likely to be useful for `Chain` users connecting via IPC as opposed to `Chain` users being spawned by the node." }, { "t": "2026-05-07T18:04:43Z", "kind": "review_comment", "who": "xyzconstant", "assoc": "CONTRIBUTOR", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": 3149370792, "text": "I get it now, thanks you!" }, { "t": "2026-05-12T19:56:10Z", "kind": "comment", "who": "Sjors", "assoc": "MEMBER", "text": "Here's the (partially implemented) Rust bindings: https://github.com/2140-dev/bitcoin-capnp-types/pull/22\n\nAnd https://github.com/Sjors/electrs/pull/1 is a proof-of-concept / demo that modifies [Electrs](https://github.com/romanz/electrs) to use IPC instead of RPC and p2p for a bunch of things, notably:\n- fetching historical blocks (previously used local p2p `getblock`)\n- transaction broadcast (previously used `send_raw_transaction` RPC)\n- tip updates (previously used inv)\n- header sync (previously used p2p, though it now gets the whole block via the chain interface, so that's not very efficient)\n- mempool sync (previously used `getrawmempool`)" }, { "t": "2026-05-20T10:51:17Z", "kind": "review_comment", "who": "willcl-ark", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "In 1c9dcf2f397fa0b58cad936bde2feaaefa532745\n\n`broadcastmethod` is switched on (e.g. [here](https://github.com/bitcoin/bitcoin/blob/master/src/node/transaction.cpp#L86)) with no default case, as is our convention. but we don't check incoming value is mapped to the enum safely." }, { "t": "2026-05-20T10:54:01Z", "kind": "review_comment", "who": "willcl-ark", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "In 1c9dcf2f397fa0b58cad936bde2feaaefa532745\n\neven though these are positional, I think we can rename `descendants` -> `cluster_count` post-cluster mempool (and as this is public facing)." }, { "t": "2026-05-20T10:57:41Z", "kind": "review_comment", "who": "willcl-ark", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": 3273293545, "text": "In 1c9dcf2f397fa0b58cad936bde2feaaefa532745\n\nAlso what happens here is `tx` is a null pointer (allowed by capnp spec AFAIU)? I think we will immediately try to deference it in `BroadcastTransaction` and segfault." }, { "t": "2026-05-20T10:58:22Z", "kind": "review_comment", "who": "willcl-ark", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "In 1c9dcf2f397fa0b58cad936bde2feaaefa532745\n\nI wonder if this `tx` isn't the same as [`1c9dcf2` (this PR)](https://github.com/bitcoin/bitcoin/pull/29409/changes/1c9dcf2f397fa0b58cad936bde2feaaefa532745#r3273331093) ?\n\n`CTxMemPool::ChangeSet::TxHandle CTxMemPool::ChangeSet::StageAddition` is going to try and dereference." }, { "t": "2026-05-20T11:12:16Z", "kind": "review_comment", "who": "willcl-ark", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.cpp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": null, "text": "In 1c9dcf2f397fa0b58cad936bde2feaaefa532745\n\nThis assert is dead code only because `ChainClient` is not exposed by this PR.\n\nThe comment says it is overridden by `WalletLoader::start`, but would this not still abort if ever called?\n\nWhy not omit start from the exposed base interface or make this throw a protocol error instead of asserting." }, { "t": "2026-05-20T11:19:54Z", "kind": "review", "who": "willcl-ark", "assoc": "MEMBER", "state": "COMMENTED", "commit": "6833d5f2b49fed8182160c5996ae94d7dfb476a1", "text": "Concept ACK.\n\nExposing `interfaces::Chain` over IPC seems very useful, especially for downstream users. I have been using a version of this branch myself on a node \"dashboard\" as some dog-fooding at: https://tracing.fish.foo\n\nLong term, I think IPC should become the preferred integration boundary for programmatic interaction with Bitcoin Core. I'd like to see us move more users away from linking into node internals, and eventually maybe even from RPC/REST/ZMQ! when IPC can provide a cleaner interface.\n\nThe overall approach of reusing the existing interfaces layer makes sense to me. I will continue to test and review a little more. Left a few nits inline." }, { "t": "2026-05-20T12:36:47Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": 3273293545, "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#discussion_r3273293545\n\n[quoted text omitted]\nIIUC, the concern in both of these cases is that non-C++ clients calling this interface (like rust or python clients) could call this method but leave the `tx` argument unset or leave the `broadcastMethod` argument unset, and then the [implementation](https://github.com/bitcoin/bitcoin/blob/a7df1bd7ca2f8a8515625813c394682394a2990a/src/node/interfaces.cpp#L363-L371) of this method could crash or fail if it is not checking for invalid values.\n\nThis is a legitimate concern, and it's not specific to this method or to these parameters. In C++, the compiler enforces at each call site that explicit values need to be passed for all parameters which don't have defaults. But in capnproto, all parameters are optional because fields without explicit defaults have implicit defaults of 0 or null.\n\nThe `Chain` interface was designed to be called by C++ clients, and with C++ clients this issue does not occur because clients don't need to interact with cap'nproto directly. They can call C++ methods with all normal language restrictions enforced, and the calls are forwarded over capnproto.\n\nBut if non-c++ other clients are used, they either need to be careful when they omit parameters, or the interface needs to be changed to allow parameters to be safely omitted. One way to do this is to assign default values in interfaces like c6638fa7c5e97f9fd7a5ea8feb29f8caeac788bd. Another way is to make method implementations handle invalid values better, for example by throwing exceptions instead of asserting." }, { "t": "2026-05-20T12:44:46Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": 3273310067, "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#discussion_r3273310067\n\n[quoted text omitted]\nGood catch. It looks like the parameter was renamed in commit 957ae232414b38adcf9358e198fded42f7c1feea and this PR was not updated. Currently there is checking to make sure capnproto parameter types and c++ types are compatible (compilation will fail otherwise) but there it isn't checked that parameters have the same names so sometimes names can get out of sync." }, { "t": "2026-05-20T13:10:08Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.capnp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": 3273334775, "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#discussion_r3273334775\n\n[quoted text omitted]\nYes this is the same issue. [checkChainLimits](https://github.com/bitcoin/bitcoin/blob/21edcc47e23909a8fa75dba52edfa8c7d6ad76af/src/node/interfaces.cpp#L720) calls [CheckPolicyLimits](https://github.com/bitcoin/bitcoin/blob/21edcc47e23909a8fa75dba52edfa8c7d6ad76af/src/txmempool.cpp#L800) which calls [StageAddition](https://github.com/bitcoin/bitcoin/blob/21edcc47e23909a8fa75dba52edfa8c7d6ad76af/src/txmempool.cpp#L1005) which does not check whether `tx` is null before dereferencing.\n\nAnd In this case, the issue applies to C++ clients as well as rust and python clients because C++ clients can also call checkChainLimits with a null pointer.\n\nDepending on what the goal is, there are various ways this could be addressed. One way would be to change [checkChainLimits](https://github.com/bitcoin/bitcoin/blob/21edcc47e23909a8fa75dba52edfa8c7d6ad76af/src/node/interfaces.cpp#L720) to throw an exception if a null pointer is passed.\n\nIn general it's not a realistic goal for this PR to ensure that it's safe to call all Chain methods with all possible arguments and ensure that the node will not crash, but it should be good to do where feasible." }, { "t": "2026-05-20T14:18:41Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/ipc/capnp/chain.cpp", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "in_reply_to": 3273420157, "text": "re: https://github.com/bitcoin/bitcoin/pull/29409#discussion_r3273420157\n\n[quoted text omitted]\nChainClient is actually exposed by this PR. But depending on what we want the goal of this PR it doesn't need to be. I tried to describe purpose of ChainClient better in a recent comment https://github.com/bitcoin/bitcoin/pull/29409#discussion_r3202947930, but basically it is not something you would implement if you are an external process connecting to the node, it is only something you would implement if you are implementing a process you would want to be started by the node. In #10102, `bitcoin-node` spawns a `bitcoin-wallet` process, and `bitcoin-wallet` implements the `ChainClient` interfaces, so the node can manage it and forward RPCs and shut it down.\n\nOriginal goal of this PR was to add `chain.capnp` to the codebase so #10102 is easier to review. But if the goal of this PR is now really to expose the Chain interface over IPC, the ChainClient capnproto definition can be dropped from this.\n\n[quoted text omitted]\nI don't think there is a realistic way this could ever be called. This is here as workaround for the fact the libmultiprocess (and capnproto) don't have separate options for generating client and server classes. So if you declare any interface, client and server classes will be produced and they need to compile. Libmultiprocess can't generate [`ChainClient::start`](https://github.com/ryanofsky/bitcoin/blob/aab1519e15218fb3eec4bffdb951adbd3b04fd4b/src/interfaces/chain.h#L413) server method that compiles because it takes a `CScheduler&` argument and there isn't a way to share schedulers across processes. In #10102, the WalletLoader implementation of [start](https://github.com/ryanofsky/bitcoin/blob/aab1519e15218fb3eec4bffdb951adbd3b04fd4b/src/ipc/capnp/wallet.cpp#L83-L91) just creates a separate scheduler for the wallet process to use.\n\nMore ideally, there might be a way to mark `ChainClient` as an abstract class that is allowed to be called but never implemented directly as a server object, only inherited from and implement that way. Capnproto doesn't provide this but libmultiprocess could define it's own `$Abstract` annotation that would do this.\n\n[quoted text omitted]\nThis could throw an exception instead of assert. It shouldn't matter very much because I don't think there's a way this could be accidentally called.\n\nAnother way to get rid of this might be drop the CScheduler parameter and just have the wallet and node use different schedulers instead of the same one." }, { "t": "2026-05-20T14:20:54Z", "kind": "review", "who": "ryanofsky", "assoc": "MEMBER", "state": "COMMENTED", "commit": "6833d5f2b49fed8182160c5996ae94d7dfb476a1", "text": "I spent way too long looking into the ChainClient::start thing, but thanks for the questions and putting the interface to work!" }, { "t": "2026-07-14T00:33:36Z", "kind": "force_push", "who": "ryanofsky", "commit": "9aee0eac079b93534e89e0c4b69767f36416fd71" }, { "t": "2026-07-14T12:14:21Z", "kind": "force_push", "who": "ryanofsky", "commit": "2eb914c6341591661b1632901c3e7b3991214d7a" }, { "t": "2026-08-24T17:06:22Z", "kind": "force_push", "who": "ryanofsky", "commit": "e914744ebacf73a5d1ab93e190ac40ccc470dd0c" }, { "t": "2026-09-08T18:25:57Z", "kind": "force_push", "who": "ryanofsky", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330" }, { "t": "2026-09-09T16:20:47Z", "kind": "review", "who": "zaidmstrr", "assoc": "CONTRIBUTOR", "state": "COMMENTED", "commit": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "text": "While working with the Chain Interface and calling the method `getBlockHash`, I found out that when we pass the height, which is greater than the current tip, then the node crashes and exits with the error:\n\n```\n\n2026-09-09T08:20:04Z [ipc] {bitcoin-node-273772/b-capnp-loop-273774} IPC server recv request #10 Chain.getBlockHash$Params\n\n2026-09-09T08:20:04Z [ipc] {bitcoin-node-273772/b-capnp-loop-273774} IPC server post request #10 {bitcoin-node-273772/capnp-worker-274464 (from )}\n\n2026-09-09T08:20:04Z [ipc] {bitcoin-node-273772/capnp-worker-274464 (from )} IPC server executing request #10\n\n2026-09-09T08:20:04Z [ipc] {bitcoin-node-273772/b-capnp-loop-273774} Creating mp::ProxyClientBase 0x73f66c01cc68\n\n../../src/node/interfaces.cpp:572 virtual uint256 node::{anonymous}::ChainImpl::getBlockHash(int): Assertion `chainman().ActiveChain()[height]' failed.\n\nAborted (core dumped)\n\n```\n\nI think instead of crashing the node, we should return an error instead here. Maybe this is because we are directly calling the method without any proper checks like we do in RPC when we call some method." } ], "labels_log": [ { "t": "2024-02-08T15:41:21Z", "action": "labeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2024-02-08T23:41:55Z", "action": "unlabeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2024-02-28T17:36:43Z", "action": "labeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2024-05-15T21:05:31Z", "action": "labeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2024-06-11T01:57:25Z", "action": "unlabeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2024-06-12T01:55:29Z", "action": "unlabeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2024-07-26T17:17:31Z", "action": "labeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2024-08-06T16:52:32Z", "action": "unlabeled", "label": "CI failed", "who": "ryanofsky" }, { "t": "2024-08-16T10:13:35Z", "action": "labeled", "label": "Needs CMake port", "who": "hebasto" }, { "t": "2024-09-02T22:45:24Z", "action": "labeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2024-09-03T06:15:33Z", "action": "unlabeled", "label": "Needs CMake port", "who": "maflcko" }, { "t": "2024-09-19T12:24:12Z", "action": "unlabeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2024-09-25T22:29:59Z", "action": "labeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2024-09-26T15:16:55Z", "action": "unlabeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2025-01-29T13:29:49Z", "action": "labeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2025-02-12T08:00:55Z", "action": "unlabeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2025-02-12T08:00:58Z", "action": "labeled", "label": "interfaces", "who": "DrahtBot" }, { "t": "2025-06-03T22:19:39Z", "action": "labeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2025-07-28T18:00:33Z", "action": "unlabeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2025-11-20T20:45:44Z", "action": "labeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2025-11-24T10:55:11Z", "action": "unlabeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2025-12-04T15:16:01Z", "action": "labeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2025-12-12T13:17:52Z", "action": "unlabeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2025-12-12T14:53:54Z", "action": "labeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2025-12-12T20:35:10Z", "action": "unlabeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2026-02-20T11:24:40Z", "action": "labeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2026-02-27T19:13:39Z", "action": "unlabeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2026-02-27T19:46:53Z", "action": "labeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2026-03-02T02:19:00Z", "action": "unlabeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2026-03-03T19:02:04Z", "action": "labeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2026-03-31T17:47:06Z", "action": "unlabeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2026-03-31T18:27:28Z", "action": "labeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2026-03-31T19:37:49Z", "action": "unlabeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2026-07-07T12:40:20Z", "action": "labeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2026-07-14T00:48:53Z", "action": "unlabeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2026-07-14T01:49:38Z", "action": "labeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2026-07-14T13:14:51Z", "action": "unlabeled", "label": "CI failed", "who": "DrahtBot" }, { "t": "2026-08-26T16:12:30Z", "action": "labeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2026-09-08T20:15:34Z", "action": "unlabeled", "label": "Needs rebase", "who": "DrahtBot" } ], "state_log": [ { "t": "2024-02-08T14:04:44Z", "kind": "ready_for_review", "who": "ryanofsky" }, { "t": "2024-04-17T17:34:24Z", "kind": "convert_to_draft", "who": "DrahtBot" }, { "t": "2024-06-11T01:55:50Z", "kind": "ready_for_review", "who": "ryanofsky" }, { "t": "2024-07-26T16:35:11Z", "kind": "convert_to_draft", "who": "ryanofsky" }, { "t": "2024-09-26T14:02:36Z", "kind": "ready_for_review", "who": "ryanofsky" } ], "text_chars": 92493, "text_tokens_estimate": 23123, "changed_paths": [ "CMakeLists.txt", "src/interfaces/chain.h", "src/ipc/CMakeLists.txt", "src/ipc/capnp/chain-types.h", "src/ipc/capnp/chain.capnp", "src/ipc/capnp/chain.cpp", "src/ipc/capnp/common-types.h", "src/ipc/capnp/common.capnp", "src/ipc/capnp/handler-types.h", "src/ipc/capnp/handler.capnp", "src/ipc/capnp/init-types.h", "src/ipc/capnp/init.capnp", "src/ipc/libmultiprocess/.clang-tidy", "src/ipc/libmultiprocess/.github/workflows/bitcoin-core-ci.yml", "src/ipc/libmultiprocess/.github/workflows/ci.yml", "src/ipc/libmultiprocess/CMakeLists.txt", "src/ipc/libmultiprocess/ci/README.md", "src/ipc/libmultiprocess/ci/configs/default.bash", "src/ipc/libmultiprocess/ci/configs/freebsd.bash", "src/ipc/libmultiprocess/ci/configs/llvm.bash", "src/ipc/libmultiprocess/ci/configs/macos.bash", "src/ipc/libmultiprocess/ci/configs/netbsd.bash", "src/ipc/libmultiprocess/ci/configs/newdeps.bash", "src/ipc/libmultiprocess/ci/configs/olddeps.bash", "src/ipc/libmultiprocess/ci/configs/openbsd.bash", "src/ipc/libmultiprocess/ci/configs/sanitize.bash", "src/ipc/libmultiprocess/ci/scripts/ci.sh", "src/ipc/libmultiprocess/cmake/TargetCapnpSources.cmake", "src/ipc/libmultiprocess/cmake/compat_config.cmake", "src/ipc/libmultiprocess/cmake/pthread_checks.cmake", "src/ipc/libmultiprocess/doc/design.md", "src/ipc/libmultiprocess/doc/install.md", "src/ipc/libmultiprocess/doc/usage.md", "src/ipc/libmultiprocess/doc/versions.md", "src/ipc/libmultiprocess/example/calculator.cpp", "src/ipc/libmultiprocess/example/example.cpp", "src/ipc/libmultiprocess/example/printer.cpp", "src/ipc/libmultiprocess/include/mp/config.h.in", "src/ipc/libmultiprocess/include/mp/proxy-io.h", "src/ipc/libmultiprocess/include/mp/proxy-types.h", "src/ipc/libmultiprocess/include/mp/proxy.h", "src/ipc/libmultiprocess/include/mp/type-char.h", "src/ipc/libmultiprocess/include/mp/type-chrono.h", "src/ipc/libmultiprocess/include/mp/type-context.h", "src/ipc/libmultiprocess/include/mp/type-data.h", "src/ipc/libmultiprocess/include/mp/type-function.h", "src/ipc/libmultiprocess/include/mp/type-interface.h", "src/ipc/libmultiprocess/include/mp/type-map.h", "src/ipc/libmultiprocess/include/mp/type-number.h", "src/ipc/libmultiprocess/include/mp/type-string.h", "src/ipc/libmultiprocess/include/mp/type-struct.h", "src/ipc/libmultiprocess/include/mp/type-threadmap.h", "src/ipc/libmultiprocess/include/mp/util.h", "src/ipc/libmultiprocess/include/mp/version.h", "src/ipc/libmultiprocess/shell.nix", "src/ipc/libmultiprocess/src/mp/gen.cpp", "src/ipc/libmultiprocess/src/mp/proxy.cpp", "src/ipc/libmultiprocess/src/mp/util.cpp", "src/ipc/libmultiprocess/test/CMakeLists.txt", "src/ipc/libmultiprocess/test/mp/test/common.h", "src/ipc/libmultiprocess/test/mp/test/connect_tests.cpp", "src/ipc/libmultiprocess/test/mp/test/foo-types.h", "src/ipc/libmultiprocess/test/mp/test/foo.capnp", "src/ipc/libmultiprocess/test/mp/test/foo.h", "src/ipc/libmultiprocess/test/mp/test/listen_tests.cpp", "src/ipc/libmultiprocess/test/mp/test/spawn_tests.cpp", "src/ipc/libmultiprocess/test/mp/test/test.cpp", "src/ipc/libmultiprocess/test/mp/test/unixlistener.h", "src/node/interfaces.cpp", "src/policy/fees/block_policy_estimator.h", "src/rpc/request.h" ], "files": [ { "path": "CMakeLists.txt", "add": 14, "del": 0 }, { "path": "src/interfaces/chain.h", "add": 5, "del": 4 }, { "path": "src/ipc/CMakeLists.txt", "add": 5, "del": 0 }, { "path": "src/ipc/capnp/chain-types.h", "add": 107, "del": 0 }, { "path": "src/ipc/capnp/chain.capnp", "add": 189, "del": 0 }, { "path": "src/ipc/capnp/chain.cpp", "add": 208, "del": 0 }, { "path": "src/ipc/capnp/common-types.h", "add": 168, "del": 2 }, { "path": "src/ipc/capnp/common.capnp", "add": 58, "del": 0 }, { "path": "src/ipc/capnp/handler-types.h", "add": 10, "del": 0 }, { "path": "src/ipc/capnp/handler.capnp", "add": 17, "del": 0 }, { "path": "src/ipc/capnp/init-types.h", "add": 1, "del": 0 }, { "path": "src/ipc/capnp/init.capnp", "add": 3, "del": 0 }, { "path": "src/ipc/libmultiprocess/.clang-tidy", "add": 1, "del": 0 }, { "path": "src/ipc/libmultiprocess/.github/workflows/bitcoin-core-ci.yml", "add": 3, "del": 0 }, { "path": "src/ipc/libmultiprocess/.github/workflows/ci.yml", "add": 15, "del": 9 }, { "path": "src/ipc/libmultiprocess/CMakeLists.txt", "add": 17, "del": 7 }, { "path": "src/ipc/libmultiprocess/ci/README.md", "add": 1, "del": 0 }, { "path": "src/ipc/libmultiprocess/ci/configs/default.bash", "add": 1, "del": 1 }, { "path": "src/ipc/libmultiprocess/ci/configs/freebsd.bash", "add": 1, "del": 1 }, { "path": "src/ipc/libmultiprocess/ci/configs/llvm.bash", "add": 1, "del": 1 }, { "path": "src/ipc/libmultiprocess/ci/configs/macos.bash", "add": 1, "del": 1 }, { "path": "src/ipc/libmultiprocess/ci/configs/netbsd.bash", "add": 1, "del": 7 }, { "path": "src/ipc/libmultiprocess/ci/configs/newdeps.bash", "add": 6, "del": 0 }, { "path": "src/ipc/libmultiprocess/ci/configs/olddeps.bash", "add": 4, "del": 1 }, { "path": "src/ipc/libmultiprocess/ci/configs/openbsd.bash", "add": 1, "del": 1 }, { "path": "src/ipc/libmultiprocess/ci/configs/sanitize.bash", "add": 2, "del": 2 }, { "path": "src/ipc/libmultiprocess/ci/scripts/ci.sh", "add": 18, "del": 0 }, { "path": "src/ipc/libmultiprocess/cmake/TargetCapnpSources.cmake", "add": 1, "del": 1 }, { "path": "src/ipc/libmultiprocess/cmake/compat_config.cmake", "add": 0, "del": 42 }, { "path": "src/ipc/libmultiprocess/cmake/pthread_checks.cmake", "add": 8, "del": 0 }, { "path": "src/ipc/libmultiprocess/doc/design.md", "add": 2, "del": 2 }, { "path": "src/ipc/libmultiprocess/doc/install.md", "add": 1, "del": 1 }, { "path": "src/ipc/libmultiprocess/doc/usage.md", "add": 6, "del": 0 }, { "path": "src/ipc/libmultiprocess/doc/versions.md", "add": 8, "del": 2 }, { "path": "src/ipc/libmultiprocess/example/calculator.cpp", "add": 4, "del": 9 }, { "path": "src/ipc/libmultiprocess/example/example.cpp", "add": 7, "del": 5 }, { "path": "src/ipc/libmultiprocess/example/printer.cpp", "add": 4, "del": 9 }, { "path": "src/ipc/libmultiprocess/include/mp/config.h.in", "add": 1, "del": 0 }, { "path": "src/ipc/libmultiprocess/include/mp/proxy-io.h", "add": 74, "del": 28 }, { "path": "src/ipc/libmultiprocess/include/mp/proxy-types.h", "add": 31, "del": 12 }, { "path": "src/ipc/libmultiprocess/include/mp/proxy.h", "add": 8, "del": 6 }, { "path": "src/ipc/libmultiprocess/include/mp/type-char.h", "add": 9, "del": 3 }, { "path": "src/ipc/libmultiprocess/include/mp/type-chrono.h", "add": 25, "del": 2 }, { "path": "src/ipc/libmultiprocess/include/mp/type-context.h", "add": 15, "del": 3 }, { "path": "src/ipc/libmultiprocess/include/mp/type-data.h", "add": 2, "del": 3 }, { "path": "src/ipc/libmultiprocess/include/mp/type-function.h", "add": 1, "del": 1 }, { "path": "src/ipc/libmultiprocess/include/mp/type-interface.h", "add": 10, "del": 10 }, { "path": "src/ipc/libmultiprocess/include/mp/type-map.h", "add": 2, "del": 0 }, { "path": "src/ipc/libmultiprocess/include/mp/type-number.h", "add": 24, "del": 15 }, { "path": "src/ipc/libmultiprocess/include/mp/type-string.h", "add": 3, "del": 1 }, { "path": "src/ipc/libmultiprocess/include/mp/type-struct.h", "add": 12, "del": 12 }, { "path": "src/ipc/libmultiprocess/include/mp/type-threadmap.h", "add": 4, "del": 4 }, { "path": "src/ipc/libmultiprocess/include/mp/util.h", "add": 63, "del": 15 }, { "path": "src/ipc/libmultiprocess/include/mp/version.h", "add": 1, "del": 1 }, { "path": "src/ipc/libmultiprocess/shell.nix", "add": 12, "del": 6 }, { "path": "src/ipc/libmultiprocess/src/mp/gen.cpp", "add": 39, "del": 41 }, { "path": "src/ipc/libmultiprocess/src/mp/proxy.cpp", "add": 94, "del": 35 }, { "path": "src/ipc/libmultiprocess/src/mp/util.cpp", "add": 216, "del": 31 }, { "path": "src/ipc/libmultiprocess/test/CMakeLists.txt", "add": 1, "del": 0 }, { "path": "src/ipc/libmultiprocess/test/mp/test/common.h", "add": 27, "del": 0 }, { "path": "src/ipc/libmultiprocess/test/mp/test/connect_tests.cpp", "add": 212, "del": 0 }, { "path": "src/ipc/libmultiprocess/test/mp/test/foo-types.h", "add": 6, "del": 0 }, { "path": "src/ipc/libmultiprocess/test/mp/test/foo.capnp", "add": 12, "del": 0 }, { "path": "src/ipc/libmultiprocess/test/mp/test/foo.h", "add": 31, "del": 1 }, { "path": "src/ipc/libmultiprocess/test/mp/test/listen_tests.cpp", "add": 47, "del": 77 }, { "path": "src/ipc/libmultiprocess/test/mp/test/spawn_tests.cpp", "add": 28, "del": 5 }, { "path": "src/ipc/libmultiprocess/test/mp/test/test.cpp", "add": 190, "del": 6 }, { "path": "src/ipc/libmultiprocess/test/mp/test/unixlistener.h", "add": 84, "del": 0 }, { "path": "src/node/interfaces.cpp", "add": 3, "del": 3 }, { "path": "src/policy/fees/block_policy_estimator.h", "add": 2, "del": 0 }, { "path": "src/rpc/request.h", "add": 2, "del": 0 } ], "test_lines": 0, "git": { "head": "c2dfc0c57f3a9d54aca0783cd9fc236c4b84c330", "head_matches_backup": true, "base": "33a363ea250839ca31ea043b7500789d2e5d844b", "commits": [ { "sha": "4c842beaae", "subject": "Squashed 'src/ipc/libmultiprocess/' changes from e8de5c7b68e..4d454a81da6", "files": 56, "add": 1398, "del": 420 }, { "sha": "567c2e020f", "subject": "Merge commit '4c842beaae2e97d7934800c8433da9632b21c0ff' into pr/subtree-14", "files": 56, "add": 1398, "del": 420 }, { "sha": "d9cfcf89bb", "subject": "build: suppress -Wc++23-lambda-attributes in warn_interface", "files": 1, "add": 14, "del": 0 }, { "sha": "ae6b583256", "subject": "Add capnp serialization code for bitcoin types", "files": 2, "add": 157, "del": 2 }, { "sha": "4466e5ce9b", "subject": "Add capnp wrapper for Handler interface", "files": 3, "add": 28, "del": 0 }, { "sha": "7b997424a9", "subject": "Add capnp wrapper for Chain interface", "files": 10, "add": 587, "del": 7 }, { "sha": "c2dfc0c57f", "subject": "multiprocess: Expose Chain interface", "files": 3, "add": 6, "del": 0 } ], "patch_truncated": true }, "input_hash": "cae1301e2496eff1", "extracted_at": "2026-09-17T16:15:31+00:00" }