Make channel_type required by elnosh · Pull Request #3896 · lightningdevkit/rust-lightning

elnosh · 2025-06-27T20:14:14Z

Changes:

Sets the option_channel_type feature as required.
Fails the channel if channel_type is not included during channel negotiation.

ldk-reviews-bot · 2025-06-27T20:14:17Z

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

ldk-reviews-bot · 2025-06-30T00:00:44Z

🔔 1st Reminder

Hey @joostjager! 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.

joostjager · 2025-06-30T11:21:06Z

 	ext_from_hex("030020", &mut test);
 	// init message (type 16) with static_remotekey required, no channel_type/anchors/taproot, and other bits optional and mac
-	ext_from_hex("0010 00021aaa 0008aaa208aa2a0a9aaa 03000000000000000000000000000000", &mut test);
+	ext_from_hex("0010 00021aaa 0008aaa218aa2a0a9aaa 03000000000000000000000000000000", &mut test);


I assume these changes are correct, because test_no_existing_test_breakage still passes.

Thanks in large part to chatgpt:

The change is in the feature bits field: aaa208aa2a0a9aaa → aaa218aa2a0a9aaa

Each two chars are the hex representation of a byte of feature info

Each byte contains 8 bits used to mark our features

This is just a vector, and the LSB is zero, next most significant is
one etc.

aa = bits 56-63 a2 = bits 48-55 18 = bits 40-47 aa = bits 32-39 2a = bits 24-31 0a = bits 16-23 9a = bits 8-15 aa = bits 0-7

Bits 40-47 changed from 08 to 18: 00001000 → 00011000, turning on required bit 44

I think that we can change the hex to 10 (00010000) so that we're only setting the required feature and not the optional one anymore? Admittedly have not read the full fuzz test though, so may be wrong here.

Update: testing suggested diff here - if this passes I think we should only set required, as that's what we're doing irl.

Update: fuzz tests pass with just the required bit, so IMO we should change them!

Nice @carlaKC taking the extra step with this analysis. Makes sense to match IRL behavior, even though we can of course still receive an init message that contains both optional and required bits.

I do see in the diff that previously the features
aaa208aa2a0a9aaa and
aaa20aaa2a0a9aaa were used, which are now both mapped to the suggested one. Chatgpt says the diff is in data_loss_protect.

Probably alright, but posting this anyway here.

ldk-reviews-bot · 2025-06-30T11:37:16Z

👋 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.

carlaKC

few minor comments, looking good!

carlaKC · 2025-07-01T20:02:42Z

 	ext_from_hex("030020", &mut test);
 	// init message (type 16) with static_remotekey required, no channel_type/anchors/taproot, and other bits optional and mac
-	ext_from_hex("0010 00021aaa 0008aaa208aa2a0a9aaa 03000000000000000000000000000000", &mut test);
+	ext_from_hex("0010 00021aaa 0008aaa218aa2a0a9aaa 03000000000000000000000000000000", &mut test);


Thanks in large part to chatgpt:

The change is in the feature bits field: aaa208aa2a0a9aaa → aaa218aa2a0a9aaa

Each two chars are the hex representation of a byte of feature info

Each byte contains 8 bits used to mark our features

This is just a vector, and the LSB is zero, next most significant is
one etc.

aa = bits 56-63 a2 = bits 48-55 18 = bits 40-47 aa = bits 32-39 2a = bits 24-31 0a = bits 16-23 9a = bits 8-15 aa = bits 0-7

Bits 40-47 changed from 08 to 18: 00001000 → 00011000, turning on required bit 44

I think that we can change the hex to 10 (00010000) so that we're only setting the required feature and not the optional one anymore? Admittedly have not read the full fuzz test though, so may be wrong here.

Update: testing suggested diff here - if this passes I think we should only set required, as that's what we're doing irl.

Update: fuzz tests pass with just the required bit, so IMO we should change them!

carlaKC · 2025-07-01T20:05:12Z

 	ext_from_hex("030120", &mut test);
 	// init message (type 16) with static_remotekey required, no channel_type/anchors/taproot, and other bits optional and mac
-	ext_from_hex("0010 00021aaa 0008aaa208aa2a0a9aaa 01000000000000000000000000000000", &mut test);
+	ext_from_hex("0010 00021aaa 0008aaa218aa2a0a9aaa 01000000000000000000000000000000", &mut test);


nitnit: comments here say that init has no channel_type?
(pre-existingly wrong, but let's update here)

elnosh · 2025-07-02T00:39:41Z

pushed changes addressing comments diff

carlaKC · 2025-07-02T14:05:09Z

pushed changes addressing comments diff

Diff lgtm, only remaining items for me:

Update: Setting only the required feature bit in the fuzz test passes, so we can change it
While we're here, I think we should add coverage for rejecting channels when chan_type doesn't match in open_channel and accept_channel

Outdated: ~~1) I suspect we should only set the required feature bit for the fuzz test (rn setting required and optional) - let's see if it passes~~

ldk-reviews-bot · 2025-07-05T15:23:22Z

🔔 1st Reminder

Hey @carlaKC! 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-07-07T15:24:09Z

🔔 2nd Reminder

Hey @carlaKC! 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.

carlaKC

lgtm, ready for a squash 👍

carlaKC · 2025-07-07T16:53:02Z

+}
+
+#[test]
+fn test_rejects_if_channel_type_differ() {


nice, thx for adding 👍

carlaKC · 2025-07-07T17:05:45Z

+
+	open_channel_msg.common_fields.channel_type =
+		Some(channel_a.funding.get_channel_type().clone());
+	let mut channel_b = InboundV1Channel::<&TestKeysInterface>::new(


non-blocking/for a follow up: these tests could benefit from being DRY-ed up a bit

Agree that it would have been nice to do it with a parameterized test, to easily go through the variants.

carlaKC · 2025-07-07T17:10:42Z

Re-ran the fuzz failure to see if that would help (no space on device is usually a GH issue), but no avail. Also on master so don't think it's blocking here.

joostjager

LGTM. I think we can wait for the fuzz to pass as this PR isn't very conflict sensitive?

carlaKC · 2025-07-10T13:12:17Z

Fuzzer fix is in, rebase should get us green ✅

Set the option_channel_type feature as required and fail the channel if channel_type is not included during channel negotiation in open_channel or accept_channel.

TheBlueMatt · 2025-07-16T19:00:57Z

-	/// feature bits with our counterparty's feature bits from the [`Init`] message.
+	/// The channel type that this channel will represent. As defined in the latest
+	/// specification, this field is required. However, it is an `Option` for legacy reasons.
 	pub channel_type: Option<ChannelTypeFeatures>,


Since we're assuming everyone sets this now, I don't really see a reason why we need to keep this an Option.

ldk-reviews-bot requested a review from joostjager June 27, 2025 20:24

joostjager reviewed Jun 30, 2025

View reviewed changes

carlaKC self-requested a review June 30, 2025 18:08

carlaKC reviewed Jul 1, 2025

View reviewed changes

elnosh force-pushed the channel-type-required branch from 8f9289d to b525e38 Compare July 3, 2025 02:34

carlaKC self-requested a review July 3, 2025 15:22

carlaKC approved these changes Jul 7, 2025

View reviewed changes

carlaKC requested a review from joostjager July 7, 2025 17:10

elnosh force-pushed the channel-type-required branch from b525e38 to 7313d10 Compare July 8, 2025 03:03

joostjager approved these changes Jul 8, 2025

View reviewed changes

Make channel_type required

e31df56

Set the option_channel_type feature as required and fail the channel if channel_type is not included during channel negotiation in open_channel or accept_channel.

elnosh force-pushed the channel-type-required branch from 7313d10 to e31df56 Compare July 10, 2025 13:37

carlaKC approved these changes Jul 10, 2025

View reviewed changes

TheBlueMatt approved these changes Jul 16, 2025

View reviewed changes

TheBlueMatt merged commit cfa782d into lightningdevkit:main Jul 16, 2025
28 checks passed

elnosh deleted the channel-type-required branch December 4, 2025 16:14

Conversation

elnosh commented Jun 27, 2025

Uh oh!

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

Uh oh!

Uh oh!

ldk-reviews-bot commented Jun 30, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

carlaKC Jul 1, 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!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ldk-reviews-bot commented Jun 30, 2025

Uh oh!

carlaKC left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

carlaKC Jul 1, 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!

elnosh commented Jul 2, 2025

Uh oh!

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

Uh oh!

Uh oh!

ldk-reviews-bot commented Jul 5, 2025

Uh oh!

ldk-reviews-bot commented Jul 7, 2025

Uh oh!

carlaKC 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!

carlaKC commented Jul 7, 2025

Uh oh!

joostjager left a comment

Choose a reason for hiding this comment

Uh oh!

carlaKC commented Jul 10, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

ldk-reviews-bot commented Jun 27, 2025 •

edited

Loading

carlaKC Jul 1, 2025 •

edited

Loading

carlaKC Jul 1, 2025 •

edited

Loading

carlaKC commented Jul 2, 2025 •

edited

Loading