Add support of ldk-node by randomlogin · Pull Request #307 · bitcoin-dev-project/sim-ln

randomlogin · 2026-04-08T13:13:25Z

This PR adds support of ldk-node to sim-ln.

Closes: #26

As ldk-node is not a daemon, before we start we parse the simulation config file and extract all ldk-nodes, build them and start. For that an additional chain source (bitcoind/esplora/electrum) is needed to start.

Before this PR can be merged, an update of used lighting libraries should be merged, as the current ldk-node has newer versions.

carlaKC · 2026-04-08T15:30:53Z

Before this PR can be merged, an update of used lighting libraries should be merged, as the current ldk-node has newer versions.

Feel free to bump this in a preparatory commit in this PR!

randomlogin · 2026-04-22T13:44:15Z

Initially I was trying to wire up ldk-node, which is not a daemon and I thought sim-ln could orchestrate ldk-node building, initialization. However it turned out that we want already running and funded nodes with opened channels, so this wasn't an option.

Added support of https://github.com/lightningdevkit/ldk-server, which is a reference daemon implementation with external API, it uses ldk-node internally.

Please note, that ldk-server has not yet been released, therefore a git reference and a revision is used in Cargo.toml

The configuration for ldk-server looks in the following way:

{
  "address": <ip:port or domain:port>,
  "api_key": <hex_encoded_api_key>,
  "cert": <path_to_tls_cert>,
  "network": <bitcoin|testnet|signet|regtest>
}

Please note that currently it's not possible to guess the network via RPC calls, that's why we need to provide it in the config. This might change in future.

carlaKC · 2026-04-22T14:21:58Z

Added support of https://github.com/lightningdevkit/ldk-server, which is a reference daemon implementation with external API, it uses ldk-node internally.
Please note, that ldk-server has not yet been released, therefore a git reference and a revision is used in Cargo.toml

Happy to go with server, I believe a release is coming soon ™️ !

carlaKC · 2026-04-27T13:39:14Z

Promise to get to review this week - sorry I've been a bit slow but it's on my list!

chuksys

Thanks for working on this! I've done a quick initial code/design review. It looks good so far, but I still need to run some local tests. I'll do that ASAP and get back to you with final feedback.

chuksys · 2026-05-12T18:05:06Z

Just tested this using the following config:

{
    "nodes": [
      {
        "id": "alice",
        "address": "172.23.48.1:10002",
        "macaroon": "/mnt/c/Users/User/.polar/networks/1/volumes/lnd/alice/data/chain/bitcoin/regtest/admin.macaroon",
        "cert": "/mnt/c/Users/User/.polar/networks/1/volumes/lnd/alice/tls.cert"
      },
      {
        "id": "carol",
        "address": "172.23.48.1:10003",
        "macaroon": "/mnt/c/Users/User/.polar/networks/1/volumes/lnd/carol/data/chain/bitcoin/regtest/admin.macaroon",
        "cert": "/mnt/c/Users/User/.polar/networks/1/volumes/lnd/carol/tls.cert"      
      },
      {
        "address": "https://localhost:3536",
        "api_key": "b91adc35b0d407dab92f5b821d51e343a19497cadd0b7fd518b846c156db6df3",
        "cert": "/tmp/ldk-server/tls.crt"
      }
    ],
    "activity": [
      {
        "source": "alice",
        "destination": "carol",
        "interval_secs": 1,
        "amount_msat": 2000
      },
      {
        "source": "alice",
        "destination": "02df5ad45ae0bfc2b9fef546640ea89cd482274e92b7bb38e1d394822c8368d173",
        "interval_secs": 5,
        "amount_msat": 5000
      }
    ]
}

These are the logs:

chuksys

If CI is happy, this LGTM.

randomlogin · 2026-05-26T10:55:08Z

Should I ping someone, for example @carlaKC, to merge?

chuksys · 2026-05-27T01:35:09Z

Should I ping someone, for example @carlaKC, to merge?

Since this is a major feature, @carlaKC will need to do a final review before merging. Please give her a bit of time to take a thorough look at it!

carlaKC

So sorry that this took so long!

carlaKC · 2026-06-23T14:01:20Z

+        Ok(NodeInfo {
+            pubkey: *node_id,
+            alias,
+            features: NodeFeatures::empty(),


Do we need to set keysend here?

I think that running this with random activity would fail - did you test this out?

I think this should follow the same pattern as the LND and CLN implementations: query the backend for the requested node and populate NodeInfo.features from the returned feature set.

Returning NodeFeatures::empty() here means sim-ln will treat the node as not supporting keysend, even if it does. Now that ldk-server exposes feature bits through GetNodeInfo, we should use that API and construct NodeInfo from the actual returned features instead of manual default feature support.

Unfortunately ldk-server does not show feature bits for other nodes, it only shows them for itself. In fact there are two methods get-node-info about itself and graph-get-node which returns information about other nodes, its example response is the following:

{ "node": { "channels": [ 3173352185970884608, 3173346688412745728, 3173354384994140160, 3336995800067670017 ], "announcement_info": { "last_update": 1782471184, "alias": "lnd-signet-node", "rgb": "ff0000", "addresses": [] } } }

I've tested random activity. it works fine. Also when we call get_node_info it checks whether we ask about this node, or another one. For this node we provide correct NodeInfo that was populated in new().

Unfortunately ldk-server does not show feature bits for other nodes, it only shows them for itself.

This is surprising. I've open a PR lightningdevkit/ldk-server#237 to address this. If merged, we should get access to feature bits from other nodes like shown below.

{ "node": { "channels": [ 468391953498113 ], "announcement_info": { "last_update": 1782481522, "alias": "ldk_server_2", "rgb": "000000", "addresses": [ "54.3.7.81:9745" ], "features": { "0": { "name": "DataLossProtect", "is_required": true }, ... } } } }

Not putting keysend in other nodes features will mean that the simulation will fail if we are sending payments to a node that we don't have control over.

Eg for network A - B:

nodes: [A] activity: [A -> B]

This is kinda niche-ey, but it is something people wanted to regularly shoot payments out to strangeres on signet, so I'd like to preserve it. Happy to hard-code if they're not surfaced by LDK-server, but if it's newly added let's use their API.

I've tested random activity. it works fine.

(my bad, thought this hit is this case)

Fixed. Previously I tested random activity with all owned nodes, so I think your original comment is valid.

enigbe · 2026-06-26T11:53:02Z

+        // ldk-server doesn't expose feature bits, but it always supports keysend
+        // via `spontaneous_send`, so advertise it so sim-ln's keysend checks pass.
+        let mut features = NodeFeatures::empty();
+        features.set_keysend_optional();


Feature bit exposure is now supported by ldk-server following lightningdevkit/ldk-server#231, so we should be able to query the node’s actual features instead of creating an empty feature set and manually setting keysend.

Manually setting it assumes the node advertises keysend support. That matches default LDK behavior today, but it can be wrong for a fork that changes feature support/requirements, in which case sim-ln would incorrectly treat the node as keysend-capable.

Fixed, now we return real feature list.

enigbe · 2026-06-26T12:08:11Z

+        Ok(NodeInfo {
+            pubkey: *node_id,
+            alias,
+            features: NodeFeatures::empty(),


I think this should follow the same pattern as the LND and CLN implementations: query the backend for the requested node and populate NodeInfo.features from the returned feature set.

Returning NodeFeatures::empty() here means sim-ln will treat the node as not supporting keysend, even if it does. Now that ldk-server exposes feature bits through GetNodeInfo, we should use that API and construct NodeInfo from the actual returned features instead of manual default feature support.

carlaKC

Typically would want to fixup and squash things like clippy fixes and node feature setting, but I left this hanging unacceptably long so happy to go in as-is. Will merge once CI is clean - thanks for the patience here and the cool new feature!

randomlogin · 2026-06-26T19:30:58Z

I'll squash commits.

carlaKC · 2026-06-26T19:31:33Z

I'll squash commits.

Ready and waiting with the merge button 🫡

Add `LdkServerNode` as a new `LightningNode` implementation ldk-server-client over gRPC-over-HTTPS. Supports keysend via `spontaneous_send`, payment tracking via polling `get_payment_details`, graph queries, and channel capacity reporting. Wire up `NodeConnection::LdkServer` in sim-cli parsing so ldk-server nodes can be specified in sim.json alongside LND, CLN, and Eclair nodes.

randomlogin force-pushed the add-ldk-support branch 2 times, most recently from 83e2d28 to 526eb15 Compare April 22, 2026 13:29

randomlogin marked this pull request as ready for review April 22, 2026 13:44

randomlogin mentioned this pull request May 5, 2026

Support LDK server (daemon node) enigbe/sim-ln#1

Draft

2 tasks

chuksys reviewed May 11, 2026

View reviewed changes

randomlogin requested a review from chuksys May 11, 2026 12:48

chuksys suggested changes May 11, 2026

View reviewed changes

Comment thread simln-lib/src/ldk_server.rs Outdated

randomlogin force-pushed the add-ldk-support branch from 8337320 to 0c69012 Compare May 11, 2026 22:54

randomlogin requested a review from chuksys May 11, 2026 22:55

chuksys reviewed May 12, 2026

View reviewed changes

Comment thread sim-cli/src/parsing.rs Outdated

Comment thread sim-cli/src/parsing.rs Outdated

randomlogin force-pushed the add-ldk-support branch from 0c69012 to 590d5ae Compare May 12, 2026 18:19

randomlogin requested a review from chuksys May 12, 2026 18:20

chuksys approved these changes May 16, 2026

View reviewed changes

enigbe mentioned this pull request Jun 12, 2026

Expose node features in GetNodeInfoResponse lightningdevkit/ldk-server#231

Merged

carlaKC reviewed Jun 23, 2026

View reviewed changes

enigbe suggested changes Jun 26, 2026

View reviewed changes

randomlogin requested review from carlaKC and enigbe June 26, 2026 13:09

enigbe mentioned this pull request Jun 26, 2026

Add features to graph node announcement lightningdevkit/ldk-server#237

Open

carlaKC approved these changes Jun 26, 2026

View reviewed changes

carlaKC mentioned this pull request Jun 26, 2026

Followup: Lookup real features for LDK-server #310

Open

randomlogin force-pushed the add-ldk-support branch from 8db2568 to 69afaab Compare June 26, 2026 19:36

carlaKC approved these changes Jun 26, 2026

View reviewed changes

carlaKC merged commit 7a93f77 into bitcoin-dev-project:main Jun 26, 2026
2 checks passed

Uh oh!

Conversation

randomlogin commented Apr 8, 2026

Uh oh!

carlaKC commented Apr 8, 2026

Uh oh!

randomlogin commented Apr 22, 2026

Uh oh!

carlaKC commented Apr 22, 2026

Uh oh!

carlaKC commented Apr 27, 2026

Uh oh!

chuksys left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

chuksys commented May 12, 2026

Uh oh!

Uh oh!

Uh oh!

chuksys left a comment

Choose a reason for hiding this comment

Uh oh!

randomlogin commented May 26, 2026

Uh oh!

chuksys commented May 27, 2026

Uh oh!

carlaKC left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

carlaKC left a comment

Choose a reason for hiding this comment

Uh oh!

randomlogin commented Jun 26, 2026

Uh oh!

carlaKC commented Jun 26, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants