Default to anchors and remove automatic channel acceptance #4354

elnosh · 2026-01-27T19:36:13Z

Changes negotiate_anchors_zero_fee_htlc_tx default to true and removes the manually_accept_inbound_channels config option.

Edit: Left the tests with default to non-anchor

ldk-reviews-bot · 2026-01-27T19:36:16Z

👋 I see @jkczyz was un-assigned.
If you'd like another reviewer assignment, please click here.

TheBlueMatt · 2026-01-27T20:30:57Z

Changing the negotiate_anchors_zero_fee_htlc_tx default to true in the tests causes +100 test failures

Hmm, can you ask claude to change those to use the test_default_config() thing? Our test config default has diverged somewhat from our actual default config for reasons like this but that's okay...

Removes the `manually_accept_inbound_channels` config option. In upcoming commit we will default to anchor channels which requires users checking if they have enough onchain funds to cover fees in case of a force close. Hence, we move to always require users to manually accept inbound channels.

codecov · 2026-01-28T22:14:35Z

Codecov Report

❌ Patch coverage is 81.39535% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.09%. Comparing base (7fe3268) to head (b1ee9e3).

Files with missing lines	Patch %	Lines
lightning/src/ln/channelmanager.rs	70.45%	12 Missing and 1 partial ⚠️
lightning/src/ln/functional_test_utils.rs	90.62%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff            @@
##           main    #4354       +/-   ##
=========================================
+ Coverage      0   86.09%   +86.09%     
=========================================
  Files         0      156      +156     
  Lines         0   102450   +102450     
  Branches      0   102450   +102450     
=========================================
+ Hits          0    88202    +88202     
- Misses        0    11754    +11754     
- Partials      0     2494     +2494

Flag	Coverage Δ
tests	`86.09% <81.39%> (?)`

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

ldk-reviews-bot · 2026-01-31T00:00:24Z

🔔 1st Reminder

Hey @jkczyz @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-02-02T00:00:54Z

🔔 1st Reminder

Hey @jkczyz @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2026-02-02T00:01:02Z

🔔 2nd Reminder

Hey @jkczyz @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

wpaulino · 2026-02-02T17:50:41Z

lightning/src/events/mod.rs

+		/// The `user_channel_id` value passed in for outbound channels, or for inbound
+		/// channels.


Let's keep this doc consistent with the other events, e.g., SpliceFailed

wpaulino · 2026-02-02T17:55:02Z

lightning/src/ln/reorg_tests.rs

+			features: nodes[0].node.init_features(), networks: None, remote_network_address: None
+		}, true).unwrap();
 	}
+	let _ = nodes[1].node.get_and_clear_pending_msg_events();


We should check what events we're expecting

wpaulino · 2026-02-02T17:58:22Z

lightning/src/util/config.rs

+	/// Note that all inbound channel requests will be surfaced via [`Event::OpenChannelRequest`]
+	/// and you must manually accept them with [`ChannelManager::accept_inbound_channel`]. This
+	/// is done to give you the chance to check whether your reserve of onchain funds is enough


Suggested change

/// Note that all inbound channel requests will be surfaced via [`Event::OpenChannelRequest`]

/// and you must manually accept them with [`ChannelManager::accept_inbound_channel`]. This

/// is done to give you the chance to check whether your reserve of onchain funds is enough

/// Upon receiving an `[Event::OpenChannelRequest]` for a channel of this type, you must check whether your reserve of onchain funds is enough

wpaulino · 2026-02-02T17:58:48Z

lightning/src/util/config.rs

-	/// [`ChannelManager::accept_inbound_channel`]. This is done to give you the chance to check
-	/// whether your reserve of onchain funds is enough to cover the fees for all existing and new
-	/// channels featuring anchor outputs in the event of a force close.
+	/// Note that all inbound channel requests will be surfaced via [`Event::OpenChannelRequest`]


Same suggestion here as above

wpaulino · 2026-02-02T18:00:10Z

lightning/src/ln/functional_test_utils.rs

+	let events = node_b.node.get_and_clear_pending_events();
+	assert_eq!(events.len(), 1);
+	match &events[0] {
+		Event::OpenChannelRequest { temporary_channel_id, counterparty_node_id, .. } => node_b
+			.node
+			.accept_inbound_channel(temporary_channel_id, counterparty_node_id, 42, None)
+			.unwrap(),
+		_ => panic!("Unexpected event"),
+	};


Use the new helper added here? Several other cases throughout the diff

added use of helper here and below. There were some other places that it is manually checking for an err so I left those.

wpaulino · 2026-02-02T18:01:56Z

lightning/src/ln/channelmanager.rs

 			// If this peer already has some channels, a new channel won't increase our number of peers
 			// with unfunded channels, so as long as we aren't over the maximum number of unfunded
 			// channels per-peer we can accept channels from a peer with existing ones.
-			if is_only_peer_channel && peers_without_funded_channels >= MAX_UNFUNDED_CHANNEL_PEERS {


Why did this change?

I noticed while running this test: https://github.com/elnosh/rust-lightning/blob/813c0146b3149c85111139fa4649a808a32e7217/lightning/src/ln/channel_open_tests.rs#L92-L110 that it would fail to accept the inbound channel if the number of peers without funded channels was == MAX_UNFUNDED_CHANNEL_PEERS but IIUC it should fail to accept it if the # of channels > MAX_UNFUNDED_CHANNEL_PEERS

wpaulino · 2026-02-02T18:03:14Z

lightning/src/ln/channelmanager.rs

-		let channel_type = channel::channel_type_from_open_channel(
-			common_fields, &self.channel_type_features()
-		).map_err(|e| MsgHandleErrInternal::from_chan_no_close(e, common_fields.temporary_channel_id))?;
+		let channel_type =


Comment in line above can be updated

ended up removing it since it seems redundant now

wpaulino · 2026-02-02T18:07:03Z

pending_changelog/4337-manual-channel-accept-default-anchors.txt

+
+ * `ChannelHandshakeConfig::negotiate_anchors_zero_fee_htlc_tx`
+   now defaults to `true` (previously `false`). This means anchor output channels
+   will be negotiated by default for all new channels, requiring users to


Suggested change

will be negotiated by default for all new channels, requiring users to

will be negotiated by default for all new channels if the counterparty supports it, requiring users to

wpaulino · 2026-02-02T18:08:45Z

lightning/src/ln/functional_test_utils.rs

@@ -4555,6 +4555,7 @@ pub fn create_node_cfgs_with_node_id_message_router<'a>(

 pub fn test_default_channel_config() -> UserConfig {


Would be nice to have the default actually use anchors so each new test added uses it, and we rename this one to something like legacy_test_channel_config to not break all our existing tests

just to make sure I understood, you mean renaming the current test_default_channel_config to test_legacy_channel_config and rename test_default_anchors_channel_config to test_default_channel_config and then use test_legacy_channel_config in all the tests that would break if used anchors?

Set `negotiate_anchors_zero_fee_htlc_tx` default to true.

elnosh force-pushed the manual-channel-acceptance branch 2 times, most recently from ef441ac to b1ee9e3 Compare January 28, 2026 20:38

elnosh marked this pull request as ready for review January 28, 2026 20:38

ldk-reviews-bot requested a review from jkczyz January 28, 2026 20:39

jkczyz requested a review from wpaulino January 29, 2026 18:32

wpaulino reviewed Feb 2, 2026

View reviewed changes

elnosh added 5 commits February 2, 2026 19:49

f - use test util helper

b8d966e

f - update comments

e1f604d

f - fix close channel in reorg tests

d723489

Default to anchor channels

c7df0d5

Set `negotiate_anchors_zero_fee_htlc_tx` default to true.

f - fix changelog

96719d6

elnosh force-pushed the manual-channel-acceptance branch from b1ee9e3 to 96719d6 Compare February 3, 2026 00:52

jkczyz removed their request for review February 3, 2026 17:12

		/// The `user_channel_id` value passed in for outbound channels, or for inbound
		/// channels.

	will be negotiated by default for all new channels, requiring users to
	will be negotiated by default for all new channels if the counterparty supports it, requiring users to

		@@ -4555,6 +4555,7 @@ pub fn create_node_cfgs_with_node_id_message_router<'a>(

		pub fn test_default_channel_config() -> UserConfig {

Default to anchors and remove automatic channel acceptance #4354

Are you sure you want to change the base?

Default to anchors and remove automatic channel acceptance #4354

Conversation

elnosh commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

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

Uh oh!

Uh oh!

TheBlueMatt commented Jan 27, 2026

Uh oh!

codecov bot commented Jan 28, 2026

Codecov Report

Uh oh!

ldk-reviews-bot commented Jan 31, 2026

Uh oh!

ldk-reviews-bot commented Feb 2, 2026

Uh oh!

ldk-reviews-bot commented Feb 2, 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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

elnosh commented Jan 27, 2026 •

edited

Loading

ldk-reviews-bot commented Jan 27, 2026 •

edited

Loading