Add `disable_lightning_connections` config flag by tankyleo · Pull Request #1064 · lightningdevkit/ldk-node

tankyleo · 2026-08-20T13:43:27Z

    Add `disable_lightning_connections` config flag

    This flag may be useful to launch a node with a stale database with the
    goal of recovering funds from the `to_remote` outputs on the confirmed
    commitment of the node's channel peers.

    In this mode, it is very important for no connections to be made,
    outbound or inbound, manual or automatic. Otherwise, the node may
    accept a connection from a channel peer, receive an `error` message from
    the peer, and broadcast a stale commitment.

    Hence, we enforce that the listening addresses field is empty if
    `disable_lightning_connections` field is true.

ldk-reviews-bot · 2026-08-20T13:43:30Z

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

tankyleo · 2026-08-20T13:45:19Z

Curious your thoughts Elias, I understand this may be a hacky use case. See this issue for context: lightningdevkit/ldk-server#257

tankyleo · 2026-08-20T13:50:11Z

If the node reconnects to the peer with a stale database, we get a panic, which I think is the correct course of action here; that's been the core motivation for this offline flag.

tnull · 2026-08-20T14:06:35Z

Curious your thoughts Elias, I understand this may be a hacky use case. See this issue for context: lightningdevkit/ldk-server#257

Hmm, I honestly would prefer to directly go for the full recovery mode we planned for a bit. Do you think this is time critical, or can we add it for v0.9?

tankyleo · 2026-08-20T14:12:40Z

Curious your thoughts Elias, I understand this may be a hacky use case. See this issue for context: lightningdevkit/ldk-server#257

Hmm, I honestly would prefer to directly go for the full recovery mode we planned for a bit. Do you think this is time critical, or can we add it for v0.9?

Yes let's go for the full recovery mode (do you have an issue describing this?)

I think this can wait for 0.9, feel free to close this PR and we can re-open a separate proper recovery PR.

tnull · 2026-08-20T15:57:07Z

Curious your thoughts Elias, I understand this may be a hacky use case. See this issue for context: lightningdevkit/ldk-server#257

Hmm, I honestly would prefer to directly go for the full recovery mode we planned for a bit. Do you think this is time critical, or can we add it for v0.9?

Yes let's go for the full recovery mode (do you have an issue describing this?)

I think this can wait for 0.9, feel free to close this PR and we can re-open a separate proper recovery PR.

No issue so far, but what we discussed was to have a special mode on builder or a separate utility that you'd give all the information you have (seed, list of known prior peers, etc) and it would try to claw all funds back that are possible, i.e., do force-close recovery but also retrieve possible_v2_counterparty_closed_balance_spks, and also do iterative full scans for the onchain wallet etc pp.

Actually, let me see if i can do a quick draft.

tnull · 2026-09-18T11:45:18Z

Superseded by the recovery mode added in #1106

@tankyleo Does that address what you had in mind?

tnull · 2026-10-05T12:02:41Z

 /// |----------------------------------------|--------------------------------------|
 /// | `storage_dir_path`                     | /tmp/ldk_node/                       |
 /// | `network`                              | Bitcoin                              |
+/// |`disable_outbound_lightning_connections`| false                                |


nit: This has missing whitespace (before, after).

I renamed the field to disable_lightning_connections see the rationale in the commit message below.

tnull · 2026-10-05T12:04:54Z

 	async fn do_connect_peer_internal(
 		&self, node_id: PublicKey, addr: SocketAddress,
 	) -> Result<(), Error> {
+		if self.disable_outbound_lightning_connections {


Should we add a test for this, i.e., one that sets up some nodes and then restarts with the flag enabled, ensuring that they they don't reconnect?

tnull · 2026-10-05T12:05:50Z

 	/// If `persist` is set to `true`, we'll remember the peer and reconnect to it on restart.
+	/// Outbound connection attempts fail with [`Error::ConnectionFailed`] if
+	/// [`Config::disable_outbound_lightning_connections`] is set.
 	pub fn connect(


Hmm, wouldn't we still want to allow manual overrides? I.e. allow the user to selectively connect peers, e.g., to trigger the channel-reestablish recovery flow?

the node that reconnects to peers to trigger the force-closes must not have the stale database, it must be launched from the seed alone. That node will be launched with outbound connections enabled.

If the node with the stale database tries to reconnect with the peers, the channel-reestablish flow causes the node to panic in rust-lightning. That is why we would like to add this disable_outbound_lightning_connections flag here, and also disable manual overrides.

See the full procedure I have in mind here: lightningdevkit/ldk-server#257 (comment)

Actually I went further and now enforce that inbound connections are disabled as well, see the rationale in the commit message below.

tnull · 2026-10-05T12:07:16Z

+	/// Inbound connections are controlled separately by
+	/// [`Config::listening_addresses`]; set it to `None` to prevent inbound connections as well.
+	/// Other networking, including chain synchronization, is unaffected.
+	pub disable_outbound_lightning_connections: bool,


Hmm, maybe this would be better on the builder, rather than a Config field?

Hmm I went back and forth on that one, I don't have a strong opinion, I went with what is consistent with the rest of the existing networking config options: a field on Config, and methods on the builder to modify this field before building the node.

This flag may be useful to launch a node with a stale database with the goal of recovering funds from the `to_remote` outputs on the confirmed commitment of the node's channel peers. In this mode, it is very important for no connections to be made, outbound or inbound, manual or automatic. Otherwise, the node may accept a connection from a channel peer, receive an `error` message from the peer, and broadcast a stale commitment. Hence, we enforce that the listening addresses field is empty if `disable_lightning_connections` field is true.

tankyleo · 2026-10-23T00:45:13Z

Sorry tnull for the delay here I completely missed your responses. I've addressed your comments, and also now require listening addresses to be empty if disable_lightning_connections is set, see the rationale in the new commit.

It is rebased against the latest main.

tankyleo requested a review from tnull August 20, 2026 13:43

tnull removed their request for review September 18, 2026 11:49

tankyleo force-pushed the 2026-08-disable-peer-networking branch from 18dff83 to adff576 Compare October 3, 2026 00:04

tankyleo changed the title ~~Add disable_peer_networking flag~~ Add disable_outbound_lightning_connections flag Oct 3, 2026

tankyleo requested a review from tnull October 3, 2026 00:21

tnull reviewed Oct 5, 2026

View reviewed changes

tankyleo force-pushed the 2026-08-disable-peer-networking branch from adff576 to fca1cd8 Compare October 23, 2026 00:28

tankyleo changed the title ~~Add disable_outbound_lightning_connections flag~~ Add disable_lightning_connections config flag Oct 23, 2026

tankyleo force-pushed the 2026-08-disable-peer-networking branch from fca1cd8 to d4982c0 Compare October 23, 2026 00:40

tankyleo requested a review from tnull October 23, 2026 00:45

Conversation

tankyleo commented Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tankyleo commented Aug 20, 2026

Uh oh!

tankyleo commented Aug 20, 2026

Uh oh!

tnull commented Aug 20, 2026

Uh oh!

tankyleo commented Aug 20, 2026

Uh oh!

tnull commented Aug 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tnull commented Sep 18, 2026

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!

tankyleo Oct 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

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!

tankyleo commented Oct 23, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

tankyleo commented Aug 20, 2026 •

edited

Loading

ldk-reviews-bot commented Aug 20, 2026 •

edited

Loading

tnull commented Aug 20, 2026 •

edited

Loading

tankyleo Oct 22, 2026 •

edited

Loading