Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Limit number of pending un-funded channel requests #1889

Closed
TheBlueMatt opened this issue Nov 30, 2022 · 4 comments · Fixed by #1988
Closed

Limit number of pending un-funded channel requests #1889

TheBlueMatt opened this issue Nov 30, 2022 · 4 comments · Fixed by #1988
Milestone
0.0.114

Comments

@TheBlueMatt
Copy link
Collaborator

We need to limit the number of pending channel requests we have or we can OOM. We should probably just set some static limit of unfunded channels and close the oldest one when we get a request for a new one. Sadly I think this will likely allow for an attacker to prevent us from accepting new channels, but maybe that's okay.
@TheBlueMatt TheBlueMatt modified the milestones: 0.0.113, 0.0.114 Nov 30, 2022
@ariard
Copy link

ariard commented Dec 1, 2022

See also the comments in dual-funding: lightning/bolts#851 (comment) We could prevent an attacker to censor our new channel acceptance by restraining new inbound connections. I don't think we have any default robust strategy yet, even you can a custom one before call to new_inbound_connection.

@TheBlueMatt TheBlueMatt mentioned this issue Jan 9, 2023
Merged
@TheBlueMatt
Copy link
Collaborator Author

Note we also need to limit the total number of (inbound) peers, as there is (at least some) per-peer overhead.

@ariard
Copy link

ariard commented Jan 17, 2023

Yes -- Limiting the total number of inbound peers would be helpful both for dual-funding overflow and known per-peer overhead.

@TheBlueMatt
Copy link
Collaborator Author

CC #1987 which would let us substantially raise the limits here.

TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Jan 26, 2023
@TheBlueMatt
Limit the number of pending un-funded inbound channel
8f3fe98 
Because we store some (not large, but not zero) state per-peer,
it's useful to limit the number of peers we have connected, at
least with some buffer.

Much more importantly, each channel has a relatively large cost,
especially around the `ChannelMonitor`s we have to build for each.

Thus, here, we limit the number of channels per-peer which aren't
(yet) on-chain, as well as limit the number of (inbound) peers
which don't have a (funded-on-chain) channel.

Fixes lightningdevkit#1889
@TheBlueMatt TheBlueMatt mentioned this issue Jan 26, 2023
Merged
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Jan 26, 2023
@TheBlueMatt
Limit the number of pending un-funded inbound channel
363d848 
Because we store some (not large, but not zero) state per-peer,
it's useful to limit the number of peers we have connected, at
least with some buffer.

Much more importantly, each channel has a relatively large cost,
especially around the `ChannelMonitor`s we have to build for each.

Thus, here, we limit the number of channels per-peer which aren't
(yet) on-chain, as well as limit the number of (inbound) peers
which don't have a (funded-on-chain) channel.

Fixes lightningdevkit#1889
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Jan 27, 2023
@TheBlueMatt
Limit the number of pending un-funded inbound channel
0906649 
Because we store some (not large, but not zero) state per-peer,
it's useful to limit the number of peers we have connected, at
least with some buffer.

Much more importantly, each channel has a relatively large cost,
especially around the `ChannelMonitor`s we have to build for each.

Thus, here, we limit the number of channels per-peer which aren't
(yet) on-chain, as well as limit the number of (inbound) peers
which don't have a (funded-on-chain) channel.

Fixes lightningdevkit#1889
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Jan 31, 2023
@TheBlueMatt
Limit the number of pending un-funded inbound channel
ad13643 
Because we store some (not large, but not zero) state per-peer,
it's useful to limit the number of peers we have connected, at
least with some buffer.

Much more importantly, each channel has a relatively large cost,
especially around the `ChannelMonitor`s we have to build for each.

Thus, here, we limit the number of channels per-peer which aren't
(yet) on-chain, as well as limit the number of (inbound) peers
which don't have a (funded-on-chain) channel.

Fixes lightningdevkit#1889
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 1, 2023
@TheBlueMatt
Limit the number of pending un-funded inbound channel
d13e42a 
Because we store some (not large, but not zero) state per-peer,
it's useful to limit the number of peers we have connected, at
least with some buffer.

Much more importantly, each channel has a relatively large cost,
especially around the `ChannelMonitor`s we have to build for each.

Thus, here, we limit the number of channels per-peer which aren't
(yet) on-chain, as well as limit the number of (inbound) peers
which don't have a (funded-on-chain) channel.

Fixes lightningdevkit#1889
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 1, 2023
@TheBlueMatt
Limit the number of pending un-funded inbound channel
a972510 
Because we store some (not large, but not zero) state per-peer,
it's useful to limit the number of peers we have connected, at
least with some buffer.

Much more importantly, each channel has a relatively large cost,
especially around the `ChannelMonitor`s we have to build for each.

Thus, here, we limit the number of channels per-peer which aren't
(yet) on-chain, as well as limit the number of (inbound) peers
which don't have a (funded-on-chain) channel.

Fixes lightningdevkit#1889
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 6, 2023
@TheBlueMatt
Limit the number of pending un-funded inbound channel
de34e4b 
Because we store some (not large, but not zero) state per-peer,
it's useful to limit the number of peers we have connected, at
least with some buffer.

Much more importantly, each channel has a relatively large cost,
especially around the `ChannelMonitor`s we have to build for each.

Thus, here, we limit the number of channels per-peer which aren't
(yet) on-chain, as well as limit the number of (inbound) peers
which don't have a (funded-on-chain) channel.

Fixes lightningdevkit#1889
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 8, 2023
@TheBlueMatt
Limit the number of pending un-funded inbound channel
746d5f2 
Because we store some (not large, but not zero) state per-peer,
it's useful to limit the number of peers we have connected, at
least with some buffer.

Much more importantly, each channel has a relatively large cost,
especially around the `ChannelMonitor`s we have to build for each.

Thus, here, we limit the number of channels per-peer which aren't
(yet) on-chain, as well as limit the number of (inbound) peers
which don't have a (funded-on-chain) channel.

Fixes lightningdevkit#1889
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 14, 2023
@TheBlueMatt
Limit the number of pending un-funded inbound channel
3833d70 
Because we store some (not large, but not zero) state per-peer,
it's useful to limit the number of peers we have connected, at
least with some buffer.

Much more importantly, each channel has a relatively large cost,
especially around the `ChannelMonitor`s we have to build for each.

Thus, here, we limit the number of channels per-peer which aren't
(yet) on-chain, as well as limit the number of (inbound) peers
which don't have a (funded-on-chain) channel.

Fixes lightningdevkit#1889
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 14, 2023
@TheBlueMatt
Limit the number of pending un-funded inbound channel
3622d55 
Because we store some (not large, but not zero) state per-peer,
it's useful to limit the number of peers we have connected, at
least with some buffer.

Much more importantly, each channel has a relatively large cost,
especially around the `ChannelMonitor`s we have to build for each.

Thus, here, we limit the number of channels per-peer which aren't
(yet) on-chain, as well as limit the number of (inbound) peers
which don't have a (funded-on-chain) channel.

Fixes lightningdevkit#1889
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 21, 2023
@TheBlueMatt
Limit the number of pending un-funded inbound channel
3f3daed 
Because we store some (not large, but not zero) state per-peer,
it's useful to limit the number of peers we have connected, at
least with some buffer.

Much more importantly, each channel has a relatively large cost,
especially around the `ChannelMonitor`s we have to build for each.

Thus, here, we limit the number of channels per-peer which aren't
(yet) on-chain, as well as limit the number of (inbound) peers
which don't have a (funded-on-chain) channel.

Fixes lightningdevkit#1889
TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this issue Feb 21, 2023
@TheBlueMatt
Limit the number of pending un-funded inbound channel
d5fb804 
Because we store some (not large, but not zero) state per-peer,
it's useful to limit the number of peers we have connected, at
least with some buffer.

Much more importantly, each channel has a relatively large cost,
especially around the `ChannelMonitor`s we have to build for each.

Thus, here, we limit the number of channels per-peer which aren't
(yet) on-chain, as well as limit the number of (inbound) peers
which don't have a (funded-on-chain) channel.

Fixes lightningdevkit#1889
optout21 pushed a commit to optout21/rust-lightning that referenced this issue Jul 24, 2023
@TheBlueMatt @optout21
Limit the number of pending un-funded inbound channel
acee2a7 
Because we store some (not large, but not zero) state per-peer,
it's useful to limit the number of peers we have connected, at
least with some buffer.

Much more importantly, each channel has a relatively large cost,
especially around the `ChannelMonitor`s we have to build for each.

Thus, here, we limit the number of channels per-peer which aren't
(yet) on-chain, as well as limit the number of (inbound) peers
which don't have a (funded-on-chain) channel.

Fixes lightningdevkit#1889
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
0.0.114
Development

Successfully merging a pull request may close this issue.

Limit the number of pending un-funded inbound channel TheBlueMatt/rust-lightning
2 participants
@TheBlueMatt @ariard