Remove panic when inbound peer sends OpenChannelRequest with no type specified and node is manually accepting requests #2804
Comments
domZippilli
added a commit
to domZippilli/rust-lightning
that referenced
this issue
Dec 23, 2023
Peers may send messages requesting to open a channel without specifying the channel type. This gets inferred by LDK when the channel actually opens, but can be passed to the event handler as an Option so the node may factor the lack of specificity in to the channel opening decision. This should fix lightningdevkit#2804.
domZippilli
added a commit
to cequals/rust-lightning
that referenced
this issue
Dec 23, 2023
Peers may send messages requesting to open a channel without specifying the channel type. This gets inferred by LDK when the channel actually opens, but can be passed to the event handler as an Option so the node may factor the lack of specificity in to the channel opening decision. This should fix lightningdevkit#2804.
TheBlueMatt
added a commit
to TheBlueMatt/rust-lightning
that referenced
this issue
Dec 24, 2023
If we receive an `OpenChannel` message without a `channel_type` with `manually_accept_inbound_channels` set, we will `unwrap()` `None`. This is uncommon these days as most nodes support `channel_type`, but sadly is rather trivial for a peer to hit for those with manual channel acceptance enabled. Reported in and fixes lightningdevkit#2804. Luckily, the updated `full_stack_target` has no issue reaching this issue quickly.
TheBlueMatt
added a commit
to TheBlueMatt/rust-lightning
that referenced
this issue
Dec 25, 2023
If we receive an `OpenChannel` message without a `channel_type` with `manually_accept_inbound_channels` set, we will `unwrap()` `None`. This is uncommon these days as most nodes support `channel_type`, but sadly is rather trivial for a peer to hit for those with manual channel acceptance enabled. Reported in and fixes lightningdevkit#2804. Luckily, the updated `full_stack_target` has no issue reaching this issue quickly.
TheBlueMatt
added a commit
to TheBlueMatt/rust-lightning
that referenced
this issue
Dec 26, 2023
If we receive an `OpenChannel` message without a `channel_type` with `manually_accept_inbound_channels` set, we will `unwrap()` `None`. This is uncommon these days as most nodes support `channel_type`, but sadly is rather trivial for a peer to hit for those with manual channel acceptance enabled. Reported in and fixes lightningdevkit#2804. Luckily, the updated `full_stack_target` has no issue reaching this issue quickly.
TheBlueMatt
added a commit
to TheBlueMatt/rust-lightning
that referenced
this issue
Dec 26, 2023
If we receive an `OpenChannel` message without a `channel_type` with `manually_accept_inbound_channels` set, we will `unwrap()` `None`. This is uncommon these days as most nodes support `channel_type`, but sadly is rather trivial for a peer to hit for those with manual channel acceptance enabled. Reported in and fixes lightningdevkit#2804. Luckily, the updated `full_stack_target` has no issue reaching this issue quickly.
TheBlueMatt
added a commit
to TheBlueMatt/rust-lightning
that referenced
this issue
Dec 29, 2023
If we receive an `OpenChannel` message without a `channel_type` with `manually_accept_inbound_channels` set, we will `unwrap()` `None`. This is uncommon these days as most nodes support `channel_type`, but sadly is rather trivial for a peer to hit for those with manual channel acceptance enabled. Reported in and fixes lightningdevkit#2804. Luckily, the updated `full_stack_target` has no issue reaching this issue quickly.
TheBlueMatt
added a commit
to TheBlueMatt/rust-lightning
that referenced
this issue
Dec 29, 2023
If we receive an `OpenChannel` message without a `channel_type` with `manually_accept_inbound_channels` set, we will `unwrap()` `None`. This is uncommon these days as most nodes support `channel_type`, but sadly is rather trivial for a peer to hit for those with manual channel acceptance enabled. Reported in and fixes lightningdevkit#2804. Luckily, the updated `full_stack_target` has no issue reaching this issue quickly.
This was referenced Dec 29, 2023
TheBlueMatt
added a commit
to TheBlueMatt/rust-lightning
that referenced
this issue
Jan 6, 2024
If we receive an `OpenChannel` message without a `channel_type` with `manually_accept_inbound_channels` set, we will `unwrap()` `None`. This is uncommon these days as most nodes support `channel_type`, but sadly is rather trivial for a peer to hit for those with manual channel acceptance enabled. Reported in and fixes lightningdevkit#2804. Luckily, the updated `full_stack_target` has no issue reaching this issue quickly.
TheBlueMatt
added a commit
to TheBlueMatt/rust-lightning
that referenced
this issue
Jan 8, 2024
If we receive an `OpenChannel` message without a `channel_type` with `manually_accept_inbound_channels` set, we will `unwrap()` `None`. This is uncommon these days as most nodes support `channel_type`, but sadly is rather trivial for a peer to hit for those with manual channel acceptance enabled. Reported in and fixes lightningdevkit#2804. Luckily, the updated `full_stack_target` has no issue reaching this issue quickly.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This bit right here causes a panic if a correctly-formed message is sent to an LDK node that is manually accepting channel open requests:
https://github.com/lightningdevkit/rust-lightning/blob/15b7f667b05b09a25af8ab2791ea4f0752fcc2ab/lightning/src/ln/channelmanager.rs#L6184C2-L6184C2
The text was updated successfully, but these errors were encountered: