-
Notifications
You must be signed in to change notification settings - Fork 404
Separate ChannelDetails' outbound capacity from the next HTLC max #1435
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.
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
Separate ChannelDetails' outbound capacity from the next HTLC max #1435
Conversation
a1db341
to
fae8b63
Compare
Codecov Report
@@ Coverage Diff @@
## main #1435 +/- ##
==========================================
+ Coverage 90.88% 91.00% +0.11%
==========================================
Files 75 75
Lines 41474 42633 +1159
Branches 41474 42633 +1159
==========================================
+ Hits 37695 38797 +1102
- Misses 3779 3836 +57
Continue to review full report at Codecov.
|
fae8b63
to
1218a85
Compare
lightning/src/ln/channelmanager.rs
Outdated
/// to use a limit as close as possible to the HTLC limit we can currently send. | ||
/// | ||
/// See also [`ChannelDetails::balance_msat`] and [`ChannelDetails::outbound_capacity_msat`]. | ||
pub outbound_htlc_limit_msat: u64, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think outbound_per_htlc_limit_msat
would be clearer, kinda reads as the limit for all htlcs otherwise
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, per_htlc
reads like a static limit on any HTLC, though, which this is not - its the limit for the next HTLC. Maybe I should add the word "next" again?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True. I'd prefer re-adding next
lightning/src/ln/channel.rs
Outdated
let outbound_capacity_msat = cmp::max(self.value_to_self_msat as i64 | ||
- outbound_stats.pending_htlcs_value_msat as i64 | ||
- self.counterparty_selected_channel_reserve_satoshis.unwrap_or(0) as i64 * 1000, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this ever want to incorporate commit_tx_fee_msat
(and/or the fee spike buffer)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it totally should! I have a WIP commit to do that but haven't had a chance to work on the tests.
1218a85
to
ace4693
Compare
ace4693
to
24150ee
Compare
24150ee
to
2a13cbd
Compare
Rebased and squashed with only conflicts fixed. |
CI sad, will re-ack after that and another reviewer |
2a13cbd
to
95b2048
Compare
`ChannelDetails::outbound_capacity_msat` describes the total amount available for sending across several HTLCs, basically just our balance minus the reserve value maintained by our counterparty. However, when routing we use it to guess the maximum amount we can send in a single additional HTLC, which it is not. There are numerous reasons why our balance may not match the amount we can send in a single HTLC, whether the HTLC in-flight limit, the channe's HTLC maximum, or our feerate buffer. This commit splits the `outbound_capacity_msat` field into two - `outbound_capacity_msat` and `outbound_htlc_limit_msat`, setting us up for correctly handling our next-HTLC-limit in the future. This also addresses the first of the reasons why the values may not match - the max-in-flight limit. The inaccuracy is ultimately tracked as lightningdevkit#1126.
95b2048
to
68ee7ef
Compare
lightning/src/ln/channel.rs
Outdated
/// Doesn't bother handling the | ||
/// if-we-removed-it-already-but-haven't-fully-resolved-they-can-still-send-an-inbound-HTLC | ||
/// corner case properly. | ||
/// The channel reserve is subtracted from each balance. | ||
/// See also [`Channel::get_balance_msat`] | ||
pub fn get_inbound_outbound_available_balance_msat(&self) -> (u64, u64) { | ||
pub fn get_inbound_outbound_available_balance_msat(&self) -> (u64, u64, u64) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is getting a bit unwieldy. Tuples are great, but I think we may wanna introduce a custom response struct here with field labels.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea! Went ahead and moved get_balance_msat
into the same function while we're at it (and left it as a separate commit for that reason).
01f5c46
to
ed06722
Compare
CI benchmark sad |
lightning/src/ln/channel.rs
Outdated
@@ -62,6 +62,17 @@ pub struct ChannelValueStat { | |||
pub counterparty_dust_limit_msat: u64, | |||
} | |||
|
|||
pub struct AvailableBalance { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe AvailableBalances or AvailableBalanceBreakdown or something, because otherwise the naming is confusing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, its not a breakdown, though, is it? They're separate "available balances" not really a breakdown of a "total available balance"
lightning/src/ln/channel.rs
Outdated
/// The channel reserve is subtracted from each balance. | ||
/// See also [`Channel::get_balance_msat`] | ||
pub fn get_inbound_outbound_available_balance_msat(&self) -> (u64, u64) { | ||
pub fn get_available_balance_msat(&self) -> AvailableBalance { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same as above here
68a08f7
to
ad683d8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re-ACKing
ad683d8
to
a375f64
Compare
Squashed the fixup commit without changes. |
Some simple code motion to clean up how channel balances get fetched.
61629bc
a375f64
to
61629bc
Compare
Lol, sorry, the old function docs were stale/wrong, I fixed them now....had to change the docs on the capacity fields:
|
ChannelDetails::outbound_capacity_msat
describes the total amountavailable for sending across several HTLCs, basically just our
balance minus the reserve value maintained by our counterparty.
However, when routing we use it to guess the maximum amount we can
send in a single additional HTLC, which it is not.
There are numerous reasons why our balance may not match the amount
we can send in a single HTLC, whether the HTLC in-flight limit, the
channe's HTLC maximum, or our feerate buffer.
This commit splits the
outbound_capacity_msat
field into two -outbound_capacity_msat
andoutbound_htlc_limit_msat
, setting usup for correctly handling our next-HTLC-limit in the future.
This also addresses the first of the reasons why the values may
not match - the max-in-flight limit. The inaccuracy is ultimately
tracked as #1126.
This is pulled out of #1434 and is really just enough of #1126 fixed so that we can do MPP tests more easily - because we default to a max in-flight limit of 10% of the channel size we need to consider the in-flight limit when routing so that we can really simply just ask the router to give us a route of, eg, 15 sats over two 100 sats channels and get back a valid route (currently it'll give us a route over one channel which will fail).
Also threw in a bonus cause we all like bonuses.