Channel Establishment for V3 Channels #3792

carlaKC · 2025-05-22T15:43:09Z

This PR updates the channel establishment flow to allow and validate V3 channels (behind test flag).

Useful for the commits that follow where we add more downgrade tests.

ldk-reviews-bot · 2025-05-22T15:43:13Z

👋 Thanks for assigning @tankyleo 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.

TheBlueMatt

Cool, basically all LGTM.

TheBlueMatt · 2025-05-22T18:02:13Z

lightning/src/ln/channelmanager.rs

@@ -16153,22 +16154,28 @@ mod tests {
 	}

 	#[test]
-	fn test_anchors_zero_fee_htlc_tx_fallback() {
+	fn test_anchors_zero_fee_htlc_tx_downgrade() {


Congrats, you touched it, now you get to move it out of channelmanager into some other test-specific file that isn't 15000 lines of code 😂

Done this in a follow up in #3797 so that move + format can be reviewed separately.

TheBlueMatt · 2025-05-22T18:04:58Z

lightning/src/util/config.rs

+	/// back to a `anchors_zero_fee_htlc` (if [`Self::negotiate_anchors_zero_fee_htlc_tx`]
+	/// is set) or `static_remote_key` channel.
+	///
+	/// *Implies [`Self::negotiate_anchors_zero_fee_htlc_tx`].*


These are in conflict - one says we'll fall back if its set, the other says that its implied (ie always set) if we set this flag.

ldk-reviews-bot · 2025-05-22T18:13:18Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

ldk-reviews-bot · 2025-05-22T18:13:31Z

✅ Added second reviewer: @valentinewallace

wpaulino

LGTM after Matt's comments are addressed

carlaKC · 2025-05-23T18:36:06Z

Removed conflicting docs statement + opened followup for test separation (felt wrong to do move+format in the same PR, happy to include if we want it in here).

ldk-reviews-bot · 2025-05-26T00:00:59Z

🔔 1st Reminder

Hey @TheBlueMatt @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 · 2025-05-26T00:01:04Z

🔔 1st Reminder

Hey @TheBlueMatt @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.

tankyleo

Sorry for the delay, here's a first pass :)

tankyleo · 2025-05-27T17:56:17Z

lightning/src/ln/channel.rs

 		// `provided_channel_type_features`. The channel type must always support
-		// `static_remote_key`.
-		if !channel_type.requires_static_remote_key() {
+		// `static_remote_key`, except for `option_zero_fee_commitments` which
+		// assumes this feature.


feel free to dismiss: would reword the "except" here to something like this: "The channel type must always support static_remote_key, either implicitly via option_zero_fee_commitments or explicitly.

tankyleo · 2025-05-27T18:13:44Z

lightning/src/ln/channelmanager.rs

+	#[cfg(test)]
+	{
+		if config.channel_handshake_config.negotiate_anchor_zero_fee_commitments {
+			features.set_anchor_zero_fee_commitments_optional();
+		}
+	}


Nit I believe we can remove one level of indentation:

#[cfg(test)] if config.channel_handshake_config.negotiate_anchor_zero_fee_commitments { features.set_anchor_zero_fee_commitments_optional(); }

tankyleo · 2025-05-27T19:53:26Z

lightning/src/ln/channel.rs

+		let (commitment_feerate, anchor_outputs_value_msat) =
+			if channel_type.supports_anchor_zero_fee_commitments() {
+				(0, 0)
+			} else if channel_type.supports_anchors_zero_fee_htlc_tx() {
+				let feerate = fee_estimator
+					.bounded_sat_per_1000_weight(ConfirmationTarget::AnchorChannelFee);
+				(feerate, ANCHOR_OUTPUT_VALUE_SATOSHI * 2 * 1000)
+			} else {
+				let feerate = fee_estimator
+					.bounded_sat_per_1000_weight(ConfirmationTarget::NonAnchorChannelFee);
+				(feerate, 0)
+			};


I'm happy to rebase TxBuilder on top of this :) The goal with the TxBuilder PR will be to remove ANCHOR_OUTPUT_VALUE_SATOSHI and chan_utils::commit_tx_fee_sat from channel.

If we do this here, shouldn't we do something similar in new_for_inbound ?

The goal with the TxBuilder PR will be to remove ANCHOR_OUTPUT_VALUE_SATOSHI and chan_utils::commit_tx_fee_sat from channel.

Didn't realize the two would be overlapping so soon - thanks that would be great 🙏

If we do this here, shouldn't we do something similar in new_for_inbound ?

"do this here" meaning account for the anchor in our balance?

Since we don't need to set feerate for inbound, we've just got a check to set anchor balance when using legacy anchors - we don't need to add anything here because our anchor amount is also zero for zero_fee_commitments.

Can drop a comment there noting that the new anchor type also has zero anchors?

Ah yes ! All good, feel free to add a comment; it was sloppy on my side, staring a the code again made it click :)

I know we asserted that open_channel_fields.commitment_feerate_sat_per_1000_weight was 0 for zero-fee commitments further above via check_remote_fee , but wondering if we should add a quick debug assert right before the "can't even pay for initial commitment transaction fee of x sats" in new_for_inbound_channel ? Something like this?

+ // Sanity check that `commitment_tx_fee` is 0 for zero fee commitments + debug_assert!(!channel_type.supports_anchor_zero_fee_commitments() || commitment_tx_fee == 0) if (funders_amount_msat / 1000).saturating_sub(anchor_outputs_value) < commitment_tx_fee {

debug_assert!(!channel_type.supports_anchor_zero_fee_commitments() || commitment_tx_fee == 0)

I don't think that this adds much, given the checks that we have in check_remote_fee?

We've already errored out if supports_anchor_zero_fee_commitments isn't zero fee

All other channel types are checked against bounded_sat_per_1000_weight (which can't be smaller than FEERATE_FLOOR_SATS_PER_KW=253), which implicitly checks that they're non-zero

I agree it doesn't add anything beyond check_remote_fee, I was thinking just in case someone in the future interferes with the ordering of these checks somehow. The check_remote_fee check is "pretty far above" this point, so someone could easily miss that they depend on each other ?

I let you make the call here thank you for your answers :)

ldk-reviews-bot · 2025-05-28T00:01:29Z

🔔 2nd Reminder

Hey @TheBlueMatt @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 · 2025-05-28T00:01:39Z

🔔 2nd Reminder

Hey @TheBlueMatt @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.

tankyleo

Another pass :)

tankyleo · 2025-05-27T23:36:08Z

lightning/src/ln/channel.rs

-		if !channel_type.requires_static_remote_key() {
+		// `static_remote_key`, except for `option_zero_fee_commitments` which
+		// assumes this feature.
+		if !channel_type.requires_static_remote_key() && !channel_type.requires_anchor_zero_fee_commitments(){


nit: missing space before {

tankyleo · 2025-05-28T00:20:42Z

lightning/src/ln/channelmanager.rs

+		// remote node supports the feature but does not accept it.
+		let mut zero_fee_config = test_default_channel_config();
+		zero_fee_config.channel_handshake_config.negotiate_anchor_zero_fee_commitments = true;
+		zero_fee_config.channel_handshake_config.negotiate_anchors_zero_fee_htlc_tx = true;


Should we also test the case where negotiate_zero_fee_commitments = true; negotiate_zero_fee_htlc_tx = false ? And if so, assert that we downgrade from zero fee commitments directly to static remote key, skipping zero fee htlcs ?

tankyleo · 2025-05-28T01:57:38Z

lightning/src/ln/channel.rs

-		let mut expected_channel_type = ChannelTypeFeatures::empty();
-		expected_channel_type.set_static_remote_key_required();
-		expected_channel_type.set_anchors_zero_fee_htlc_tx_required();
+		assert!(channel_a.funding.get_channel_type() != &expected_channel_type);


I would replace this assert with:
assert!(channel_a.funding.get_channel_type() == &ChannelTypeFeatures::only_static_remote_key());

My thinking is if the sender node signals both zero_fee_htlc and zero_fee_commitments, but the receiver node does not support either of them, we should only accept ChannelTypeFeatures::only_static_remote_key() here. Right now we would also accept ChannelTypeFeatures::anchors_zero_htlc_fee_and_dependencies() here, which would be incorrect.

tankyleo · 2025-05-28T02:40:49Z

lightning/src/ln/channel.rs

+		if channel_type.supports_anchor_zero_fee_commitments() {
+			channel_type.clear_anchor_zero_fee_commitments();
+			channel_type.set_anchors_zero_fee_htlc_tx_required();
+			channel_type.set_static_remote_key_required();
+
+			self.feerate_per_kw = fee_estimator.bounded_sat_per_1000_weight(ConfirmationTarget::AnchorChannelFee);
+			assert!(!channel_type.supports_anchor_zero_fee_commitments());
+			assert!(channel_type.supports_anchors_zero_fee_htlc_tx());
+			assert!(channel_type.supports_static_remote_key());


Should we make sure here that ChannelHandshakeConfig.negotiate_zero_fee_htlc_tx == true before doing this downgrade ?

Oh yeah, good catch! I think that this is actually an issue on both ends?

We have to check that we want to negotiate this type

We need to check that the remote actually supports anchors_zero_fee_htlc_tx_required

Previously this wasn't an issue because the static_remote is a dependency of anchors_zero_fee_htlc_tx - if they support anchors_zero_fee_htlc_tx we know that we can drop down to static_remote.

But now if they've set anchor_zero_fee_commitments we can't just assume that they support anchors_zero_fee_htlc_tx without going back to look at InitFeatures?

I think that this is actually an issue on both ends?

Yes !

But now if they've set anchor_zero_fee_commitments we can't just assume that they support anchors_zero_fee_htlc_tx without going back to look at InitFeatures?

Could we assume they have set it, and if not, we get another error back, and we come back here to downgrade to static remote key ?

Could we assume they have set it, and if not, we get another error back, and we come back here to downgrade to static remote key ?

I don't love spending a round trip on a channel type that we know is going to fail. Looking at re-using the code in get_initial_channel_type for downgrades to DRY this up a bit. Downside is that we need to thread remote features through, but I think it's a nicer approach - WDYT?

Yes I don't like that roundtrip either :)

tankyleo · 2025-05-28T02:44:55Z

lightning/src/util/config.rs

+	/// [`ChannelManager::accept_inbound_channel`]: crate::ln::channelmanager::ChannelManager::accept_inbound_channel
+	/// [`DecodeError::InvalidValue`]: crate::ln::msgs::DecodeError::InvalidValue
+	#[cfg(test)]
+	pub negotiate_anchor_zero_fee_commitments: bool,


I assume overall that someone could, strangely, set negotiate_anchor_zero_fee_commitments = true and negotiate_anchors_zero_fee_htlc_tx = false

Yeah indeed. Other options would be:

Have one negotiate_anchors config option that tries zero fee and then regular anchors

Have this option imply negotiate_anchors_zero_fee_htlc_tx even if it isn't set

I don't have strong preference for either, IMO (1) makes testing a bit of a nightmare and (2) is more confusing to an end user. Assuming that we'll eventually turn these both on by default, I think I still like this approach most?

Yes I like this approach too ! I noted this because it opens up this strange case where someone sets negotiate_anchor_zero_fee_commitments = true and negotiate_anchors_zero_fee_htlc_tx = false, and we would have to potentially handle a downgrade from zero fee commitments directly to static remote key, skipping zero fee htlcs. I wasn't sure how much support / testing we wanted to provide on such a downgrade.

tankyleo · 2025-05-28T02:52:27Z

lightning/src/ln/channel.rs

+		let mut config = UserConfig::default();
+		config.channel_handshake_config.negotiate_anchor_zero_fee_commitments = true;


In addition, should we also test the case where negotiate_anchor_zero_fee_commitments and negotiate_anchors_zero_fee_htlc_tx are both true ?

tankyleo · 2025-05-28T03:13:09Z

lightning/src/ln/channelmanager.rs

@@ -16123,6 +16123,13 @@ mod tests {
 		assert_eq!(accept_message.channel_reserve_satoshis, 2_000);
 	}

+	#[test]
+	fn test_inbound_zero_fee_commitments_acceptance() {


nit: we have test_inbound_anchors_manual_acceptance above, so should this be test_inbound_zero_fee_commitments_manual_acceptance ? For consistency ?

tankyleo · 2025-05-28T03:15:51Z

lightning/src/ln/channelmanager.rs

+	fn test_inbound_zero_fee_commitments_acceptance() {
+		let mut zero_fee_cfg = test_default_channel_config();
+		zero_fee_cfg.channel_handshake_config.negotiate_anchor_zero_fee_commitments = true;
+		do_test_manual_inbound_accept_with_override(zero_fee_cfg, None);


Should we also test zero_fee_cfg with overrides ?

Doesn't really offer us much more coverage since config override is independent of the channel type?

Ah yes I see it now thank you.

IIUC then this test right here double checks that if mannual_accept_cfg.manually_accept_inbound_channels = false, and channel_handshake_config.negotiate_anchor_zero_fee_commitments = true, that the receiver node complains with "No channels with anchor outputs accepted.". Also checks that when both of these settings are true, we do accept the channel.

Rather than duplicating our channel type preference ordering in downgrade logic, make a modified version of the remote peer's supported features and remove our current channel type from it to get the next preferred channel type.

To allow testing along the way in this PR, turn on negotiation of zero fee channels. Co-authored-by: Matt Corallo <[email protected]>

Sender: MUST set `feerate_per_kw` to zero Receiver: MUST fail the channel if `feerate_per_kw` != 0 Co-authored-by: Matt Corallo <[email protected]>

Like anchor channels, these channels require that the user reserves a UTXO to bump the channel. If we automatically accept this channel type and the user does not have such reserve available, they are at risk of losing funds because they cannot fee bump the channel.

carlaKC · 2025-05-29T15:53:46Z

Major change in push is using get_initial_channel_type in channel type downgrades to DRY up the code a bit.
Otherwise addressed nits + added some tests in fixups (full diff).

ln/refactor: add helper test function for channel type downgrade

a3a4af9

Useful for the commits that follow where we add more downgrade tests.

carlaKC requested a review from TheBlueMatt May 22, 2025 15:43

carlaKC mentioned this pull request May 22, 2025

Zero Fee Commitments #3789

Open

36 tasks

TheBlueMatt reviewed May 22, 2025

View reviewed changes

ldk-reviews-bot requested a review from valentinewallace May 22, 2025 18:13

wpaulino requested review from wpaulino and removed request for valentinewallace May 22, 2025 18:17

wpaulino reviewed May 23, 2025

View reviewed changes

carlaKC force-pushed the 3789-channelestablishment branch from 3a36506 to b9ec89c Compare May 23, 2025 18:30

carlaKC mentioned this pull request May 23, 2025

rustfmt: move channel acceptance tests into own file and format #3797

Open

carlaKC requested review from wpaulino and TheBlueMatt May 23, 2025 20:54

tankyleo reviewed May 27, 2025

View reviewed changes

tankyleo reviewed May 28, 2025

View reviewed changes

carlaKC and others added 8 commits May 28, 2025 09:16

f Add ability to assert on downgraded type in test helper

93dbf0a

f Allow test helper to use separate config for channel opener/recipient

93df503

f Allow channel downgrade tests to cover several iterations

7077f5c

ln+util: add test option to enable negotiation of zero fee channels

701ec7e

To allow testing along the way in this PR, turn on negotiation of zero fee channels. Co-authored-by: Matt Corallo <[email protected]>

f Update wording in static remote key assumed comment + style fixup

d94374e

f Remove unnecessary indentation for cfg[test]

1caef53

f Add test coverage for skipping anchors when not negotiated

2b9c5ec

carlaKC and others added 9 commits May 29, 2025 10:42

f Add assertion that we can't downgrade to anchor_zero_fee_commitments

9c63391

ln/refactor: add helper function for channel type tests

250f310

f Stricter assertion on default channel type in test

3cf7ac7

ln: do not set or accept non-zero feerates in open_channel for v3

a85cb35

Sender: MUST set `feerate_per_kw` to zero Receiver: MUST fail the channel if `feerate_per_kw` != 0 Co-authored-by: Matt Corallo <[email protected]>

f Add coverage for both anchor types supported, zero fee commits chosen

816f170

ln/refactor: add helper function for manual acceptance tests

f1cae54

f Standardize naming of manual acceptance test for zero fee comms

a9c6e9a

ln: set max_htlcs based on the channel type

892d87a

carlaKC force-pushed the 3789-channelestablishment branch from b9ec89c to 892d87a Compare May 29, 2025 15:50

carlaKC requested a review from tankyleo May 29, 2025 15:53

		let mut config = UserConfig::default();
		config.channel_handshake_config.negotiate_anchor_zero_fee_commitments = true;

Channel Establishment for V3 Channels #3792

Are you sure you want to change the base?

Channel Establishment for V3 Channels #3792

Conversation

carlaKC commented May 22, 2025

Uh oh!

ldk-reviews-bot commented May 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TheBlueMatt left a comment

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!

ldk-reviews-bot commented May 22, 2025

Uh oh!

ldk-reviews-bot commented May 22, 2025

Uh oh!

wpaulino left a comment

Choose a reason for hiding this comment

Uh oh!

carlaKC commented May 23, 2025

Uh oh!

ldk-reviews-bot commented May 26, 2025

Uh oh!

ldk-reviews-bot commented May 26, 2025

Uh oh!

tankyleo left a comment

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!

tankyleo May 28, 2025 • 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!

ldk-reviews-bot commented May 28, 2025

Uh oh!

ldk-reviews-bot commented May 28, 2025

Uh oh!

tankyleo left a comment

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!

carlaKC May 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

ldk-reviews-bot commented May 22, 2025 •

edited

Loading

tankyleo May 28, 2025 •

edited

Loading

carlaKC May 28, 2025 •

edited

Loading

tankyleo May 28, 2025 •

edited

Loading