Skip to content

More flexible fee rate estimates - #2660

Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
benthecarman:flexible-fee-rate
Oct 20, 2023
Merged

More flexible fee rate estimates#2660
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
benthecarman:flexible-fee-rate

Conversation

@benthecarman

@benthecarmanbenthecarman commented Oct 12, 2023

Copy link
Copy Markdown
Contributor

Closes#2659

My attempt at making fee rate estimation more flexible. Names and docs need some work (happy for suggestions).

@TheBlueMatt

Copy link
Copy Markdown
Collaborator

My one real ask if about keeping Background, Normal, and HighPriority, the way they are used in compute_fee_from_spent_amounts doesn't really seem replaceable, maybe it is fine to keep them with this api.

compute_fee_from_spent_amounts is honestly pretty dumb. It just ladders down ConfirmationTarget, but it oculd, like, just use a lower feerate? Like subtract 1? Divide by two? I don't see why it does what it does, it should just use max(HtlcSweep, input_amounts / 2) or something like that.

@TheBlueMattTheBlueMatt added this to the 0.0.118 milestone Oct 13, 2023
@TheBlueMatt

Copy link
Copy Markdown
Collaborator

Tentatively setting 118, but if it doesnt make it it slips.

@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 2 times, most recently from 73686c6 to 3e39bccCompareOctober 14, 2023 00:39
@codecov-commenter

codecov-commenter commented Oct 14, 2023

Copy link
Copy Markdown

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (2c51080) 89.04% compared to head (9baac2f) 88.96%.
Report is 66 commits behind head on main.

❗ Current head 9baac2f differs from pull request most recent head dd15ab0. Consider uploading reports for the commit dd15ab0 to get more accurate results

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@ Coverage Diff @@## main #2660 +/- ##
==========================================
- Coverage 89.04% 88.96% -0.09% 
==========================================
Files 112 112 Lines 87229 87625 +396 Branches 87229 87625 +396 ==========================================
+ Hits 77674 77954 +280 - Misses 7319 7430 +111 - Partials 2236 2241 +5 
FilesCoverage Δ
lightning/src/chain/chaininterface.rs97.14% <100.00%> (ø)
lightning/src/chain/onchaintx.rs80.41% <100.00%> (-1.44%)⬇️
lightning/src/ln/channelmanager.rs81.32% <100.00%> (-0.31%)⬇️
lightning/src/ln/functional_tests.rs97.17% <100.00%> (-0.14%)⬇️
lightning/src/util/config.rs67.87% <ø> (ø)
lightning/src/util/test_utils.rs77.19% <100.00%> (+0.10%)⬆️
lightning/src/ln/channel.rs88.38% <91.66%> (+0.01%)⬆️
lightning/src/chain/package.rs87.65% <77.77%> (+1.00%)⬆️

... and 24 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@benthecarman
benthecarman marked this pull request as ready for review October 14, 2023 05:46
@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 2 times, most recently from 8257e6f to cbe6adfCompareOctober 14, 2023 23:13
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Responded to @TheBlueMatt's review

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all these docs need a good bit more verbiage to make them more friendly to folks newer to lightning, I suggested some alternative text for a few of them.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 3 times, most recently from 0f11c17 to 8e45e78CompareOctober 16, 2023 17:25
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Added some more color around why the min channel fees are important for preventing force closures too

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I think we're getting there. Next time you squash can you line-wrap the lines to 100 chars? Other than that, need another reviewer.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
let mut fee = updated_feerate * (predicted_weight as u64) / 1000;
let sweep_feerate = fee_estimator.bounded_sat_per_1000_weight(ConfirmationTarget::OnChainSweep);
let fee_rate = cmp::min(sweep_feerate, compute_feerate_sat_per_1000_weight(input_amounts / 2, predicted_weight as u64)) as u64;
let fee = fee_rate * (predicted_weight as u64) / 1000;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can use fee_for_weight here

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using that breaks a test, it has an extra -1 in it

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably because fee_for_weight will round up. That test isn't very accurate to begin with because it's estimating the witness weight, which can be off by a few units.

Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/ln/channel.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Responded to @wpaulino's review, good catches

Comment threadlightning/src/chain/package.rs

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, finally there from my end. Some remaining doc nits but I'm happy to land after this.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/chain/package.rs Outdated
@TheBlueMatt

Copy link
Copy Markdown
Collaborator

CI is mad cause there's a test that was checking an error message:

thread 'ln::functional_tests::accept_busted_but_better_fee' panicked at lightning/src/ln/functional_test_utils.rs:1491:17:
assertion `left == right` failed
left: ProcessingError { err: "Peer's feerate much too low. Actual: 1000. Our expected lower limit: 5000" }
right: ProcessingError { err: "Peer's feerate much too low. Actual: 1000. Our expected lower limit: 5000 (- 250)" }
stack backtrace:
0: rust_begin_unwind
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:595:5
1: core::panicking::panic_fmt
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:67:14
2: core::panicking::assert_failed_inner
3: core::panicking::assert_failed
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:229:5
4: lightning::ln::functional_test_utils::check_closed_event
at ./src/ln/functional_test_utils.rs:1491:5
5: lightning::ln::functional_tests::accept_busted_but_better_fee
at ./src/ln/functional_tests.rs:10016:4
6: lightning::ln::functional_tests::accept_busted_but_better_fee::{{closure}}
at ./src/ln/functional_tests.rs:9948:35
7: core::ops::function::FnOnce::call_once
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/ops/function.rs:250:5
8: core::ops::function::FnOnce::call_once
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
failures:
ln::functional_tests::accept_busted_but_better_fee

TheBlueMatt
TheBlueMatt previously approved these changes Oct 19, 2023

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to clean up the docs in a followup.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/ln/channel.rs
@TheBlueMatt
TheBlueMatt merged commit be8797e into lightningdevkit:mainOct 20, 2023
@benthecarman
benthecarman deleted the flexible-fee-rate branch October 20, 2023 17:48
PXplod pushed a commit to bitlightlabs/rust-lightning that referenced this pull request Sep 30, 2024
0.0.118 - Oct 23, 2023 - "Just the Twelve Sinks"
API Updates
===========
* BOLT12 sending and receiving is now supported as an alpha feature. You may
run into unexpected issues and will need to have a direct connection with
the offer's blinded path introduction points as messages are not yet routed.
We are seeking feedback from early testers (lightningdevkit#2578, lightningdevkit#2039).
* `ConfirmationTarget` has been rewritten to provide information about the
specific use LDK needs the feerate estimate for, rather than the generic
low-, medium-, and high-priority estimates. This allows LDK users to more
accurately target their feerate estimates (lightningdevkit#2660). For those wishing to
retain their existing behavior, see the table below for conversion.
* `ChainHash` is now used in place of `BlockHash` where it represents the
genesis block (lightningdevkit#2662).
* `lightning-invoice` payment utilities now take a `Deref` to
`AChannelManager` (lightningdevkit#2652).
* `peel_onion` is provided to statelessly decode an `OnionMessage` (lightningdevkit#2599).
* `ToSocketAddrs` + `Display` are now impl'd for `SocketAddress` (lightningdevkit#2636, lightningdevkit#2670)
* `Display` is now implemented for `OutPoint` (lightningdevkit#2649).
* `Features::from_be_bytes` is now provided (lightningdevkit#2640).
For those moving to the new `ConfirmationTarget`, the new variants in terms of
the old mempool/low/medium/high priorities are as follows:
* `OnChainSweep` = `HighPriority`
* `MaxAllowedNonAnchorChannelRemoteFee` = `max(25 * 250, HighPriority * 10)`
* `MinAllowedAnchorChannelRemoteFee` = `MempoolMinimum`
* `MinAllowedNonAnchorChannelRemoteFee` = `Background - 250`
* `AnchorChannelFee` = `Background`
* `NonAnchorChannelFee` = `Normal`
* `ChannelCloseMinimum` = `Background`
Bug Fixes
=========
* Calling `ChannelManager::close_channel[_with_feerate_and_script]` on a
channel which did not exist would immediately hang holding several key
`ChannelManager`-internal locks (lightningdevkit#2657).
* Channel information updates received from a failing HTLC are no longer
applied to our `NetworkGraph`. This prevents a node which we attempted to
route a payment through from being able to learn the sender of the payment.
In some rare cases, this may result in marginally reduced payment success
rates (lightningdevkit#2666).
* Anchor outputs are now properly considered when calculating the amount
available to send in HTLCs. This can prevent force-closes in anchor channels
when sending payments which overflow the available balance (lightningdevkit#2674).
* A peer that sends an `update_fulfill_htlc` message for a forwarded HTLC,
then reconnects prior to sending a `commitment_signed` (thus retransmitting
their `update_fulfill_htlc`) may result in the channel stalling and being
unable to make progress (lightningdevkit#2661).
* In exceedingly rare circumstances, messages intended to be sent to a peer
prior to reconnection can be sent after reconnection. This could result in
undefined channel state and force-closes (lightningdevkit#2663).
Backwards Compatibility
=======================
* Creating a blinded path to receive a payment then downgrading to LDK prior to
0.0.117 may result in failure to receive the payment (lightningdevkit#2413).
* Calling `ChannelManager::pay_for_offer` or
`ChannelManager::create_refund_builder` may prevent downgrading to LDK prior
to 0.0.118 until the payment times out and has been removed (lightningdevkit#2039).
Node Compatibility
==================
* LDK now sends a bogus `channel_reestablish` message to peers when they ask to
resume an unknown channel. This should cause LND nodes to force-close and
broadcast the latest channel state to the chain. In order to trigger this
when we wish to force-close a channel, LDK now disconnects immediately after
sending a channel-closing `error` message. This should result in cooperative
peers also working to confirm the latest commitment transaction when we wish
to force-close (lightningdevkit#2658).
Security
========
0.0.118 expands mitigations against transaction cycling attacks to non-anchor
channels, though note that no mitigations which exist today are considered robust
to prevent the class of attacks.
* In order to mitigate against transaction cycling attacks, non-anchor HTLC
transactions are now properly re-signed before broadcasting (lightningdevkit#2667).
In total, this release features 61 files changed, 3470 insertions, 1503
deletions in 85 commits from 12 authors, in alphabetical order:
* Antonio Yang
* Elias Rohrer
* Evan Feenstra
* Fedeparma74
* Gursharan Singh
* Jeffrey Czyz
* Matt Corallo
* Sergi Delgado Segura
* Vladimir Fomene
* Wilmer Paulino
* benthecarman
* slanesuke
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make Fee Estimator more flexible

4 participants

@benthecarman@TheBlueMatt@codecov-commenter@wpaulino
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
More flexible fee rate estimates by benthecarman · Pull Request #2660 · lightningdevkit/rust-lightning · GitHub
Skip to content

More flexible fee rate estimates - #2660

Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
benthecarman:flexible-fee-rate
Oct 20, 2023
Merged

More flexible fee rate estimates#2660
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
benthecarman:flexible-fee-rate

Conversation

@benthecarman

@benthecarmanbenthecarman commented Oct 12, 2023

Copy link
Copy Markdown
Contributor

Closes#2659

My attempt at making fee rate estimation more flexible. Names and docs need some work (happy for suggestions).

@TheBlueMatt

Copy link
Copy Markdown
Collaborator

My one real ask if about keeping Background, Normal, and HighPriority, the way they are used in compute_fee_from_spent_amounts doesn't really seem replaceable, maybe it is fine to keep them with this api.

compute_fee_from_spent_amounts is honestly pretty dumb. It just ladders down ConfirmationTarget, but it oculd, like, just use a lower feerate? Like subtract 1? Divide by two? I don't see why it does what it does, it should just use max(HtlcSweep, input_amounts / 2) or something like that.

@TheBlueMattTheBlueMatt added this to the 0.0.118 milestone Oct 13, 2023
@TheBlueMatt

Copy link
Copy Markdown
Collaborator

Tentatively setting 118, but if it doesnt make it it slips.

@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 2 times, most recently from 73686c6 to 3e39bccCompareOctober 14, 2023 00:39
@codecov-commenter

codecov-commenter commented Oct 14, 2023

Copy link
Copy Markdown

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (2c51080) 89.04% compared to head (9baac2f) 88.96%.
Report is 66 commits behind head on main.

❗ Current head 9baac2f differs from pull request most recent head dd15ab0. Consider uploading reports for the commit dd15ab0 to get more accurate results

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@ Coverage Diff @@## main #2660 +/- ##
==========================================
- Coverage 89.04% 88.96% -0.09% 
==========================================
Files 112 112 Lines 87229 87625 +396 Branches 87229 87625 +396 ==========================================
+ Hits 77674 77954 +280 - Misses 7319 7430 +111 - Partials 2236 2241 +5 
FilesCoverage Δ
lightning/src/chain/chaininterface.rs97.14% <100.00%> (ø)
lightning/src/chain/onchaintx.rs80.41% <100.00%> (-1.44%)⬇️
lightning/src/ln/channelmanager.rs81.32% <100.00%> (-0.31%)⬇️
lightning/src/ln/functional_tests.rs97.17% <100.00%> (-0.14%)⬇️
lightning/src/util/config.rs67.87% <ø> (ø)
lightning/src/util/test_utils.rs77.19% <100.00%> (+0.10%)⬆️
lightning/src/ln/channel.rs88.38% <91.66%> (+0.01%)⬆️
lightning/src/chain/package.rs87.65% <77.77%> (+1.00%)⬆️

... and 24 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@benthecarman
benthecarman marked this pull request as ready for review October 14, 2023 05:46
@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 2 times, most recently from 8257e6f to cbe6adfCompareOctober 14, 2023 23:13
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Responded to @TheBlueMatt's review

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all these docs need a good bit more verbiage to make them more friendly to folks newer to lightning, I suggested some alternative text for a few of them.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 3 times, most recently from 0f11c17 to 8e45e78CompareOctober 16, 2023 17:25
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Added some more color around why the min channel fees are important for preventing force closures too

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I think we're getting there. Next time you squash can you line-wrap the lines to 100 chars? Other than that, need another reviewer.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
let mut fee = updated_feerate * (predicted_weight as u64) / 1000;
let sweep_feerate = fee_estimator.bounded_sat_per_1000_weight(ConfirmationTarget::OnChainSweep);
let fee_rate = cmp::min(sweep_feerate, compute_feerate_sat_per_1000_weight(input_amounts / 2, predicted_weight as u64)) as u64;
let fee = fee_rate * (predicted_weight as u64) / 1000;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can use fee_for_weight here

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using that breaks a test, it has an extra -1 in it

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably because fee_for_weight will round up. That test isn't very accurate to begin with because it's estimating the witness weight, which can be off by a few units.

Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/ln/channel.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Responded to @wpaulino's review, good catches

Comment threadlightning/src/chain/package.rs

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, finally there from my end. Some remaining doc nits but I'm happy to land after this.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/chain/package.rs Outdated
@TheBlueMatt

Copy link
Copy Markdown
Collaborator

CI is mad cause there's a test that was checking an error message:

thread 'ln::functional_tests::accept_busted_but_better_fee' panicked at lightning/src/ln/functional_test_utils.rs:1491:17:
assertion `left == right` failed
left: ProcessingError { err: "Peer's feerate much too low. Actual: 1000. Our expected lower limit: 5000" }
right: ProcessingError { err: "Peer's feerate much too low. Actual: 1000. Our expected lower limit: 5000 (- 250)" }
stack backtrace:
0: rust_begin_unwind
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:595:5
1: core::panicking::panic_fmt
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:67:14
2: core::panicking::assert_failed_inner
3: core::panicking::assert_failed
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:229:5
4: lightning::ln::functional_test_utils::check_closed_event
at ./src/ln/functional_test_utils.rs:1491:5
5: lightning::ln::functional_tests::accept_busted_but_better_fee
at ./src/ln/functional_tests.rs:10016:4
6: lightning::ln::functional_tests::accept_busted_but_better_fee::{{closure}}
at ./src/ln/functional_tests.rs:9948:35
7: core::ops::function::FnOnce::call_once
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/ops/function.rs:250:5
8: core::ops::function::FnOnce::call_once
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
failures:
ln::functional_tests::accept_busted_but_better_fee

TheBlueMatt
TheBlueMatt previously approved these changes Oct 19, 2023

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to clean up the docs in a followup.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/ln/channel.rs
@TheBlueMatt
TheBlueMatt merged commit be8797e into lightningdevkit:mainOct 20, 2023
@benthecarman
benthecarman deleted the flexible-fee-rate branch October 20, 2023 17:48
PXplod pushed a commit to bitlightlabs/rust-lightning that referenced this pull request Sep 30, 2024
0.0.118 - Oct 23, 2023 - "Just the Twelve Sinks"
API Updates
===========
* BOLT12 sending and receiving is now supported as an alpha feature. You may
run into unexpected issues and will need to have a direct connection with
the offer's blinded path introduction points as messages are not yet routed.
We are seeking feedback from early testers (lightningdevkit#2578, lightningdevkit#2039).
* `ConfirmationTarget` has been rewritten to provide information about the
specific use LDK needs the feerate estimate for, rather than the generic
low-, medium-, and high-priority estimates. This allows LDK users to more
accurately target their feerate estimates (lightningdevkit#2660). For those wishing to
retain their existing behavior, see the table below for conversion.
* `ChainHash` is now used in place of `BlockHash` where it represents the
genesis block (lightningdevkit#2662).
* `lightning-invoice` payment utilities now take a `Deref` to
`AChannelManager` (lightningdevkit#2652).
* `peel_onion` is provided to statelessly decode an `OnionMessage` (lightningdevkit#2599).
* `ToSocketAddrs` + `Display` are now impl'd for `SocketAddress` (lightningdevkit#2636, lightningdevkit#2670)
* `Display` is now implemented for `OutPoint` (lightningdevkit#2649).
* `Features::from_be_bytes` is now provided (lightningdevkit#2640).
For those moving to the new `ConfirmationTarget`, the new variants in terms of
the old mempool/low/medium/high priorities are as follows:
* `OnChainSweep` = `HighPriority`
* `MaxAllowedNonAnchorChannelRemoteFee` = `max(25 * 250, HighPriority * 10)`
* `MinAllowedAnchorChannelRemoteFee` = `MempoolMinimum`
* `MinAllowedNonAnchorChannelRemoteFee` = `Background - 250`
* `AnchorChannelFee` = `Background`
* `NonAnchorChannelFee` = `Normal`
* `ChannelCloseMinimum` = `Background`
Bug Fixes
=========
* Calling `ChannelManager::close_channel[_with_feerate_and_script]` on a
channel which did not exist would immediately hang holding several key
`ChannelManager`-internal locks (lightningdevkit#2657).
* Channel information updates received from a failing HTLC are no longer
applied to our `NetworkGraph`. This prevents a node which we attempted to
route a payment through from being able to learn the sender of the payment.
In some rare cases, this may result in marginally reduced payment success
rates (lightningdevkit#2666).
* Anchor outputs are now properly considered when calculating the amount
available to send in HTLCs. This can prevent force-closes in anchor channels
when sending payments which overflow the available balance (lightningdevkit#2674).
* A peer that sends an `update_fulfill_htlc` message for a forwarded HTLC,
then reconnects prior to sending a `commitment_signed` (thus retransmitting
their `update_fulfill_htlc`) may result in the channel stalling and being
unable to make progress (lightningdevkit#2661).
* In exceedingly rare circumstances, messages intended to be sent to a peer
prior to reconnection can be sent after reconnection. This could result in
undefined channel state and force-closes (lightningdevkit#2663).
Backwards Compatibility
=======================
* Creating a blinded path to receive a payment then downgrading to LDK prior to
0.0.117 may result in failure to receive the payment (lightningdevkit#2413).
* Calling `ChannelManager::pay_for_offer` or
`ChannelManager::create_refund_builder` may prevent downgrading to LDK prior
to 0.0.118 until the payment times out and has been removed (lightningdevkit#2039).
Node Compatibility
==================
* LDK now sends a bogus `channel_reestablish` message to peers when they ask to
resume an unknown channel. This should cause LND nodes to force-close and
broadcast the latest channel state to the chain. In order to trigger this
when we wish to force-close a channel, LDK now disconnects immediately after
sending a channel-closing `error` message. This should result in cooperative
peers also working to confirm the latest commitment transaction when we wish
to force-close (lightningdevkit#2658).
Security
========
0.0.118 expands mitigations against transaction cycling attacks to non-anchor
channels, though note that no mitigations which exist today are considered robust
to prevent the class of attacks.
* In order to mitigate against transaction cycling attacks, non-anchor HTLC
transactions are now properly re-signed before broadcasting (lightningdevkit#2667).
In total, this release features 61 files changed, 3470 insertions, 1503
deletions in 85 commits from 12 authors, in alphabetical order:
* Antonio Yang
* Elias Rohrer
* Evan Feenstra
* Fedeparma74
* Gursharan Singh
* Jeffrey Czyz
* Matt Corallo
* Sergi Delgado Segura
* Vladimir Fomene
* Wilmer Paulino
* benthecarman
* slanesuke
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make Fee Estimator more flexible

4 participants

@benthecarman@TheBlueMatt@codecov-commenter@wpaulino
, 'i'); if (__m === '*' || __re.test(location.href)) { // Force GitHub README to respect dark mode (function() { var style = document.createElement('style'); style.textContent = ' .markdown-body { color-scheme: dark light; } .markdown-body pre { background: #161b22 !important; } .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; } .markdown-body table th, .markdown-body table td { border-color: #30363d !important; } .markdown-body img { background: #0d1117; } .markdown-body blockquote { border-left-color: #8b949e; } .markdown-body hr { border-color: #30363d; } '; document.head.appendChild(style); })(); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' More flexible fee rate estimates by benthecarman · Pull Request #2660 · lightningdevkit/rust-lightning · GitHub
Skip to content

More flexible fee rate estimates - #2660

Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
benthecarman:flexible-fee-rate
Oct 20, 2023
Merged

More flexible fee rate estimates#2660
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
benthecarman:flexible-fee-rate

Conversation

@benthecarman

@benthecarmanbenthecarman commented Oct 12, 2023

Copy link
Copy Markdown
Contributor

Closes#2659

My attempt at making fee rate estimation more flexible. Names and docs need some work (happy for suggestions).

@TheBlueMatt

Copy link
Copy Markdown
Collaborator

My one real ask if about keeping Background, Normal, and HighPriority, the way they are used in compute_fee_from_spent_amounts doesn't really seem replaceable, maybe it is fine to keep them with this api.

compute_fee_from_spent_amounts is honestly pretty dumb. It just ladders down ConfirmationTarget, but it oculd, like, just use a lower feerate? Like subtract 1? Divide by two? I don't see why it does what it does, it should just use max(HtlcSweep, input_amounts / 2) or something like that.

@TheBlueMattTheBlueMatt added this to the 0.0.118 milestone Oct 13, 2023
@TheBlueMatt

Copy link
Copy Markdown
Collaborator

Tentatively setting 118, but if it doesnt make it it slips.

@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 2 times, most recently from 73686c6 to 3e39bccCompareOctober 14, 2023 00:39
@codecov-commenter

codecov-commenter commented Oct 14, 2023

Copy link
Copy Markdown

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (2c51080) 89.04% compared to head (9baac2f) 88.96%.
Report is 66 commits behind head on main.

❗ Current head 9baac2f differs from pull request most recent head dd15ab0. Consider uploading reports for the commit dd15ab0 to get more accurate results

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@ Coverage Diff @@## main #2660 +/- ##
==========================================
- Coverage 89.04% 88.96% -0.09% 
==========================================
Files 112 112 Lines 87229 87625 +396 Branches 87229 87625 +396 ==========================================
+ Hits 77674 77954 +280 - Misses 7319 7430 +111 - Partials 2236 2241 +5 
FilesCoverage Δ
lightning/src/chain/chaininterface.rs97.14% <100.00%> (ø)
lightning/src/chain/onchaintx.rs80.41% <100.00%> (-1.44%)⬇️
lightning/src/ln/channelmanager.rs81.32% <100.00%> (-0.31%)⬇️
lightning/src/ln/functional_tests.rs97.17% <100.00%> (-0.14%)⬇️
lightning/src/util/config.rs67.87% <ø> (ø)
lightning/src/util/test_utils.rs77.19% <100.00%> (+0.10%)⬆️
lightning/src/ln/channel.rs88.38% <91.66%> (+0.01%)⬆️
lightning/src/chain/package.rs87.65% <77.77%> (+1.00%)⬆️

... and 24 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@benthecarman
benthecarman marked this pull request as ready for review October 14, 2023 05:46
@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 2 times, most recently from 8257e6f to cbe6adfCompareOctober 14, 2023 23:13
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Responded to @TheBlueMatt's review

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all these docs need a good bit more verbiage to make them more friendly to folks newer to lightning, I suggested some alternative text for a few of them.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 3 times, most recently from 0f11c17 to 8e45e78CompareOctober 16, 2023 17:25
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Added some more color around why the min channel fees are important for preventing force closures too

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I think we're getting there. Next time you squash can you line-wrap the lines to 100 chars? Other than that, need another reviewer.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
let mut fee = updated_feerate * (predicted_weight as u64) / 1000;
let sweep_feerate = fee_estimator.bounded_sat_per_1000_weight(ConfirmationTarget::OnChainSweep);
let fee_rate = cmp::min(sweep_feerate, compute_feerate_sat_per_1000_weight(input_amounts / 2, predicted_weight as u64)) as u64;
let fee = fee_rate * (predicted_weight as u64) / 1000;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can use fee_for_weight here

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using that breaks a test, it has an extra -1 in it

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably because fee_for_weight will round up. That test isn't very accurate to begin with because it's estimating the witness weight, which can be off by a few units.

Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/ln/channel.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Responded to @wpaulino's review, good catches

Comment threadlightning/src/chain/package.rs

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, finally there from my end. Some remaining doc nits but I'm happy to land after this.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/chain/package.rs Outdated
@TheBlueMatt

Copy link
Copy Markdown
Collaborator

CI is mad cause there's a test that was checking an error message:

thread 'ln::functional_tests::accept_busted_but_better_fee' panicked at lightning/src/ln/functional_test_utils.rs:1491:17:
assertion `left == right` failed
left: ProcessingError { err: "Peer's feerate much too low. Actual: 1000. Our expected lower limit: 5000" }
right: ProcessingError { err: "Peer's feerate much too low. Actual: 1000. Our expected lower limit: 5000 (- 250)" }
stack backtrace:
0: rust_begin_unwind
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:595:5
1: core::panicking::panic_fmt
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:67:14
2: core::panicking::assert_failed_inner
3: core::panicking::assert_failed
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:229:5
4: lightning::ln::functional_test_utils::check_closed_event
at ./src/ln/functional_test_utils.rs:1491:5
5: lightning::ln::functional_tests::accept_busted_but_better_fee
at ./src/ln/functional_tests.rs:10016:4
6: lightning::ln::functional_tests::accept_busted_but_better_fee::{{closure}}
at ./src/ln/functional_tests.rs:9948:35
7: core::ops::function::FnOnce::call_once
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/ops/function.rs:250:5
8: core::ops::function::FnOnce::call_once
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
failures:
ln::functional_tests::accept_busted_but_better_fee

TheBlueMatt
TheBlueMatt previously approved these changes Oct 19, 2023

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to clean up the docs in a followup.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/ln/channel.rs
@TheBlueMatt
TheBlueMatt merged commit be8797e into lightningdevkit:mainOct 20, 2023
@benthecarman
benthecarman deleted the flexible-fee-rate branch October 20, 2023 17:48
PXplod pushed a commit to bitlightlabs/rust-lightning that referenced this pull request Sep 30, 2024
0.0.118 - Oct 23, 2023 - "Just the Twelve Sinks"
API Updates
===========
* BOLT12 sending and receiving is now supported as an alpha feature. You may
run into unexpected issues and will need to have a direct connection with
the offer's blinded path introduction points as messages are not yet routed.
We are seeking feedback from early testers (lightningdevkit#2578, lightningdevkit#2039).
* `ConfirmationTarget` has been rewritten to provide information about the
specific use LDK needs the feerate estimate for, rather than the generic
low-, medium-, and high-priority estimates. This allows LDK users to more
accurately target their feerate estimates (lightningdevkit#2660). For those wishing to
retain their existing behavior, see the table below for conversion.
* `ChainHash` is now used in place of `BlockHash` where it represents the
genesis block (lightningdevkit#2662).
* `lightning-invoice` payment utilities now take a `Deref` to
`AChannelManager` (lightningdevkit#2652).
* `peel_onion` is provided to statelessly decode an `OnionMessage` (lightningdevkit#2599).
* `ToSocketAddrs` + `Display` are now impl'd for `SocketAddress` (lightningdevkit#2636, lightningdevkit#2670)
* `Display` is now implemented for `OutPoint` (lightningdevkit#2649).
* `Features::from_be_bytes` is now provided (lightningdevkit#2640).
For those moving to the new `ConfirmationTarget`, the new variants in terms of
the old mempool/low/medium/high priorities are as follows:
* `OnChainSweep` = `HighPriority`
* `MaxAllowedNonAnchorChannelRemoteFee` = `max(25 * 250, HighPriority * 10)`
* `MinAllowedAnchorChannelRemoteFee` = `MempoolMinimum`
* `MinAllowedNonAnchorChannelRemoteFee` = `Background - 250`
* `AnchorChannelFee` = `Background`
* `NonAnchorChannelFee` = `Normal`
* `ChannelCloseMinimum` = `Background`
Bug Fixes
=========
* Calling `ChannelManager::close_channel[_with_feerate_and_script]` on a
channel which did not exist would immediately hang holding several key
`ChannelManager`-internal locks (lightningdevkit#2657).
* Channel information updates received from a failing HTLC are no longer
applied to our `NetworkGraph`. This prevents a node which we attempted to
route a payment through from being able to learn the sender of the payment.
In some rare cases, this may result in marginally reduced payment success
rates (lightningdevkit#2666).
* Anchor outputs are now properly considered when calculating the amount
available to send in HTLCs. This can prevent force-closes in anchor channels
when sending payments which overflow the available balance (lightningdevkit#2674).
* A peer that sends an `update_fulfill_htlc` message for a forwarded HTLC,
then reconnects prior to sending a `commitment_signed` (thus retransmitting
their `update_fulfill_htlc`) may result in the channel stalling and being
unable to make progress (lightningdevkit#2661).
* In exceedingly rare circumstances, messages intended to be sent to a peer
prior to reconnection can be sent after reconnection. This could result in
undefined channel state and force-closes (lightningdevkit#2663).
Backwards Compatibility
=======================
* Creating a blinded path to receive a payment then downgrading to LDK prior to
0.0.117 may result in failure to receive the payment (lightningdevkit#2413).
* Calling `ChannelManager::pay_for_offer` or
`ChannelManager::create_refund_builder` may prevent downgrading to LDK prior
to 0.0.118 until the payment times out and has been removed (lightningdevkit#2039).
Node Compatibility
==================
* LDK now sends a bogus `channel_reestablish` message to peers when they ask to
resume an unknown channel. This should cause LND nodes to force-close and
broadcast the latest channel state to the chain. In order to trigger this
when we wish to force-close a channel, LDK now disconnects immediately after
sending a channel-closing `error` message. This should result in cooperative
peers also working to confirm the latest commitment transaction when we wish
to force-close (lightningdevkit#2658).
Security
========
0.0.118 expands mitigations against transaction cycling attacks to non-anchor
channels, though note that no mitigations which exist today are considered robust
to prevent the class of attacks.
* In order to mitigate against transaction cycling attacks, non-anchor HTLC
transactions are now properly re-signed before broadcasting (lightningdevkit#2667).
In total, this release features 61 files changed, 3470 insertions, 1503
deletions in 85 commits from 12 authors, in alphabetical order:
* Antonio Yang
* Elias Rohrer
* Evan Feenstra
* Fedeparma74
* Gursharan Singh
* Jeffrey Czyz
* Matt Corallo
* Sergi Delgado Segura
* Vladimir Fomene
* Wilmer Paulino
* benthecarman
* slanesuke
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make Fee Estimator more flexible

4 participants

@benthecarman@TheBlueMatt@codecov-commenter@wpaulino
, 'i'); if (__m === '*' || __re.test(location.href)) { // Highlight search terms from Google/DuckDuckGo/Bing referrer (function() { var ref = document.referrer; var terms = []; if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) { var url = new URL(ref); var q = url.searchParams.get('q') || url.searchParams.get('p'); if (q) { terms = q.split(/\s+/).filter(function(t) { return t.length > 2; }); } } if (terms.length === 0) return; var style = document.createElement('style'); style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }'; document.head.appendChild(style); function highlight(node) { if (node.nodeType === 3) { // text node var text = node.textContent; var found = false; terms.forEach(function(term) { var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' More flexible fee rate estimates by benthecarman · Pull Request #2660 · lightningdevkit/rust-lightning · GitHub
Skip to content

More flexible fee rate estimates - #2660

Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
benthecarman:flexible-fee-rate
Oct 20, 2023
Merged

More flexible fee rate estimates#2660
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
benthecarman:flexible-fee-rate

Conversation

@benthecarman

@benthecarmanbenthecarman commented Oct 12, 2023

Copy link
Copy Markdown
Contributor

Closes#2659

My attempt at making fee rate estimation more flexible. Names and docs need some work (happy for suggestions).

@TheBlueMatt

Copy link
Copy Markdown
Collaborator

My one real ask if about keeping Background, Normal, and HighPriority, the way they are used in compute_fee_from_spent_amounts doesn't really seem replaceable, maybe it is fine to keep them with this api.

compute_fee_from_spent_amounts is honestly pretty dumb. It just ladders down ConfirmationTarget, but it oculd, like, just use a lower feerate? Like subtract 1? Divide by two? I don't see why it does what it does, it should just use max(HtlcSweep, input_amounts / 2) or something like that.

@TheBlueMattTheBlueMatt added this to the 0.0.118 milestone Oct 13, 2023
@TheBlueMatt

Copy link
Copy Markdown
Collaborator

Tentatively setting 118, but if it doesnt make it it slips.

@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 2 times, most recently from 73686c6 to 3e39bccCompareOctober 14, 2023 00:39
@codecov-commenter

codecov-commenter commented Oct 14, 2023

Copy link
Copy Markdown

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (2c51080) 89.04% compared to head (9baac2f) 88.96%.
Report is 66 commits behind head on main.

❗ Current head 9baac2f differs from pull request most recent head dd15ab0. Consider uploading reports for the commit dd15ab0 to get more accurate results

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@ Coverage Diff @@## main #2660 +/- ##
==========================================
- Coverage 89.04% 88.96% -0.09% 
==========================================
Files 112 112 Lines 87229 87625 +396 Branches 87229 87625 +396 ==========================================
+ Hits 77674 77954 +280 - Misses 7319 7430 +111 - Partials 2236 2241 +5 
FilesCoverage Δ
lightning/src/chain/chaininterface.rs97.14% <100.00%> (ø)
lightning/src/chain/onchaintx.rs80.41% <100.00%> (-1.44%)⬇️
lightning/src/ln/channelmanager.rs81.32% <100.00%> (-0.31%)⬇️
lightning/src/ln/functional_tests.rs97.17% <100.00%> (-0.14%)⬇️
lightning/src/util/config.rs67.87% <ø> (ø)
lightning/src/util/test_utils.rs77.19% <100.00%> (+0.10%)⬆️
lightning/src/ln/channel.rs88.38% <91.66%> (+0.01%)⬆️
lightning/src/chain/package.rs87.65% <77.77%> (+1.00%)⬆️

... and 24 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@benthecarman
benthecarman marked this pull request as ready for review October 14, 2023 05:46
@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 2 times, most recently from 8257e6f to cbe6adfCompareOctober 14, 2023 23:13
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Responded to @TheBlueMatt's review

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all these docs need a good bit more verbiage to make them more friendly to folks newer to lightning, I suggested some alternative text for a few of them.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 3 times, most recently from 0f11c17 to 8e45e78CompareOctober 16, 2023 17:25
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Added some more color around why the min channel fees are important for preventing force closures too

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I think we're getting there. Next time you squash can you line-wrap the lines to 100 chars? Other than that, need another reviewer.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
let mut fee = updated_feerate * (predicted_weight as u64) / 1000;
let sweep_feerate = fee_estimator.bounded_sat_per_1000_weight(ConfirmationTarget::OnChainSweep);
let fee_rate = cmp::min(sweep_feerate, compute_feerate_sat_per_1000_weight(input_amounts / 2, predicted_weight as u64)) as u64;
let fee = fee_rate * (predicted_weight as u64) / 1000;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can use fee_for_weight here

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using that breaks a test, it has an extra -1 in it

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably because fee_for_weight will round up. That test isn't very accurate to begin with because it's estimating the witness weight, which can be off by a few units.

Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/ln/channel.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Responded to @wpaulino's review, good catches

Comment threadlightning/src/chain/package.rs

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, finally there from my end. Some remaining doc nits but I'm happy to land after this.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/chain/package.rs Outdated
@TheBlueMatt

Copy link
Copy Markdown
Collaborator

CI is mad cause there's a test that was checking an error message:

thread 'ln::functional_tests::accept_busted_but_better_fee' panicked at lightning/src/ln/functional_test_utils.rs:1491:17:
assertion `left == right` failed
left: ProcessingError { err: "Peer's feerate much too low. Actual: 1000. Our expected lower limit: 5000" }
right: ProcessingError { err: "Peer's feerate much too low. Actual: 1000. Our expected lower limit: 5000 (- 250)" }
stack backtrace:
0: rust_begin_unwind
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:595:5
1: core::panicking::panic_fmt
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:67:14
2: core::panicking::assert_failed_inner
3: core::panicking::assert_failed
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:229:5
4: lightning::ln::functional_test_utils::check_closed_event
at ./src/ln/functional_test_utils.rs:1491:5
5: lightning::ln::functional_tests::accept_busted_but_better_fee
at ./src/ln/functional_tests.rs:10016:4
6: lightning::ln::functional_tests::accept_busted_but_better_fee::{{closure}}
at ./src/ln/functional_tests.rs:9948:35
7: core::ops::function::FnOnce::call_once
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/ops/function.rs:250:5
8: core::ops::function::FnOnce::call_once
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
failures:
ln::functional_tests::accept_busted_but_better_fee

TheBlueMatt
TheBlueMatt previously approved these changes Oct 19, 2023

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to clean up the docs in a followup.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/ln/channel.rs
@TheBlueMatt
TheBlueMatt merged commit be8797e into lightningdevkit:mainOct 20, 2023
@benthecarman
benthecarman deleted the flexible-fee-rate branch October 20, 2023 17:48
PXplod pushed a commit to bitlightlabs/rust-lightning that referenced this pull request Sep 30, 2024
0.0.118 - Oct 23, 2023 - "Just the Twelve Sinks"
API Updates
===========
* BOLT12 sending and receiving is now supported as an alpha feature. You may
run into unexpected issues and will need to have a direct connection with
the offer's blinded path introduction points as messages are not yet routed.
We are seeking feedback from early testers (lightningdevkit#2578, lightningdevkit#2039).
* `ConfirmationTarget` has been rewritten to provide information about the
specific use LDK needs the feerate estimate for, rather than the generic
low-, medium-, and high-priority estimates. This allows LDK users to more
accurately target their feerate estimates (lightningdevkit#2660). For those wishing to
retain their existing behavior, see the table below for conversion.
* `ChainHash` is now used in place of `BlockHash` where it represents the
genesis block (lightningdevkit#2662).
* `lightning-invoice` payment utilities now take a `Deref` to
`AChannelManager` (lightningdevkit#2652).
* `peel_onion` is provided to statelessly decode an `OnionMessage` (lightningdevkit#2599).
* `ToSocketAddrs` + `Display` are now impl'd for `SocketAddress` (lightningdevkit#2636, lightningdevkit#2670)
* `Display` is now implemented for `OutPoint` (lightningdevkit#2649).
* `Features::from_be_bytes` is now provided (lightningdevkit#2640).
For those moving to the new `ConfirmationTarget`, the new variants in terms of
the old mempool/low/medium/high priorities are as follows:
* `OnChainSweep` = `HighPriority`
* `MaxAllowedNonAnchorChannelRemoteFee` = `max(25 * 250, HighPriority * 10)`
* `MinAllowedAnchorChannelRemoteFee` = `MempoolMinimum`
* `MinAllowedNonAnchorChannelRemoteFee` = `Background - 250`
* `AnchorChannelFee` = `Background`
* `NonAnchorChannelFee` = `Normal`
* `ChannelCloseMinimum` = `Background`
Bug Fixes
=========
* Calling `ChannelManager::close_channel[_with_feerate_and_script]` on a
channel which did not exist would immediately hang holding several key
`ChannelManager`-internal locks (lightningdevkit#2657).
* Channel information updates received from a failing HTLC are no longer
applied to our `NetworkGraph`. This prevents a node which we attempted to
route a payment through from being able to learn the sender of the payment.
In some rare cases, this may result in marginally reduced payment success
rates (lightningdevkit#2666).
* Anchor outputs are now properly considered when calculating the amount
available to send in HTLCs. This can prevent force-closes in anchor channels
when sending payments which overflow the available balance (lightningdevkit#2674).
* A peer that sends an `update_fulfill_htlc` message for a forwarded HTLC,
then reconnects prior to sending a `commitment_signed` (thus retransmitting
their `update_fulfill_htlc`) may result in the channel stalling and being
unable to make progress (lightningdevkit#2661).
* In exceedingly rare circumstances, messages intended to be sent to a peer
prior to reconnection can be sent after reconnection. This could result in
undefined channel state and force-closes (lightningdevkit#2663).
Backwards Compatibility
=======================
* Creating a blinded path to receive a payment then downgrading to LDK prior to
0.0.117 may result in failure to receive the payment (lightningdevkit#2413).
* Calling `ChannelManager::pay_for_offer` or
`ChannelManager::create_refund_builder` may prevent downgrading to LDK prior
to 0.0.118 until the payment times out and has been removed (lightningdevkit#2039).
Node Compatibility
==================
* LDK now sends a bogus `channel_reestablish` message to peers when they ask to
resume an unknown channel. This should cause LND nodes to force-close and
broadcast the latest channel state to the chain. In order to trigger this
when we wish to force-close a channel, LDK now disconnects immediately after
sending a channel-closing `error` message. This should result in cooperative
peers also working to confirm the latest commitment transaction when we wish
to force-close (lightningdevkit#2658).
Security
========
0.0.118 expands mitigations against transaction cycling attacks to non-anchor
channels, though note that no mitigations which exist today are considered robust
to prevent the class of attacks.
* In order to mitigate against transaction cycling attacks, non-anchor HTLC
transactions are now properly re-signed before broadcasting (lightningdevkit#2667).
In total, this release features 61 files changed, 3470 insertions, 1503
deletions in 85 commits from 12 authors, in alphabetical order:
* Antonio Yang
* Elias Rohrer
* Evan Feenstra
* Fedeparma74
* Gursharan Singh
* Jeffrey Czyz
* Matt Corallo
* Sergi Delgado Segura
* Vladimir Fomene
* Wilmer Paulino
* benthecarman
* slanesuke
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make Fee Estimator more flexible

4 participants

@benthecarman@TheBlueMatt@codecov-commenter@wpaulino
, 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ' More flexible fee rate estimates by benthecarman · Pull Request #2660 · lightningdevkit/rust-lightning · GitHub
Skip to content

More flexible fee rate estimates - #2660

Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
benthecarman:flexible-fee-rate
Oct 20, 2023
Merged

More flexible fee rate estimates#2660
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
benthecarman:flexible-fee-rate

Conversation

@benthecarman

@benthecarmanbenthecarman commented Oct 12, 2023

Copy link
Copy Markdown
Contributor

Closes#2659

My attempt at making fee rate estimation more flexible. Names and docs need some work (happy for suggestions).

@TheBlueMatt

Copy link
Copy Markdown
Collaborator

My one real ask if about keeping Background, Normal, and HighPriority, the way they are used in compute_fee_from_spent_amounts doesn't really seem replaceable, maybe it is fine to keep them with this api.

compute_fee_from_spent_amounts is honestly pretty dumb. It just ladders down ConfirmationTarget, but it oculd, like, just use a lower feerate? Like subtract 1? Divide by two? I don't see why it does what it does, it should just use max(HtlcSweep, input_amounts / 2) or something like that.

@TheBlueMattTheBlueMatt added this to the 0.0.118 milestone Oct 13, 2023
@TheBlueMatt

Copy link
Copy Markdown
Collaborator

Tentatively setting 118, but if it doesnt make it it slips.

@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 2 times, most recently from 73686c6 to 3e39bccCompareOctober 14, 2023 00:39
@codecov-commenter

codecov-commenter commented Oct 14, 2023

Copy link
Copy Markdown

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (2c51080) 89.04% compared to head (9baac2f) 88.96%.
Report is 66 commits behind head on main.

❗ Current head 9baac2f differs from pull request most recent head dd15ab0. Consider uploading reports for the commit dd15ab0 to get more accurate results

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@ Coverage Diff @@## main #2660 +/- ##
==========================================
- Coverage 89.04% 88.96% -0.09% 
==========================================
Files 112 112 Lines 87229 87625 +396 Branches 87229 87625 +396 ==========================================
+ Hits 77674 77954 +280 - Misses 7319 7430 +111 - Partials 2236 2241 +5 
FilesCoverage Δ
lightning/src/chain/chaininterface.rs97.14% <100.00%> (ø)
lightning/src/chain/onchaintx.rs80.41% <100.00%> (-1.44%)⬇️
lightning/src/ln/channelmanager.rs81.32% <100.00%> (-0.31%)⬇️
lightning/src/ln/functional_tests.rs97.17% <100.00%> (-0.14%)⬇️
lightning/src/util/config.rs67.87% <ø> (ø)
lightning/src/util/test_utils.rs77.19% <100.00%> (+0.10%)⬆️
lightning/src/ln/channel.rs88.38% <91.66%> (+0.01%)⬆️
lightning/src/chain/package.rs87.65% <77.77%> (+1.00%)⬆️

... and 24 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@benthecarman
benthecarman marked this pull request as ready for review October 14, 2023 05:46
@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 2 times, most recently from 8257e6f to cbe6adfCompareOctober 14, 2023 23:13
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Responded to @TheBlueMatt's review

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all these docs need a good bit more verbiage to make them more friendly to folks newer to lightning, I suggested some alternative text for a few of them.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 3 times, most recently from 0f11c17 to 8e45e78CompareOctober 16, 2023 17:25
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Added some more color around why the min channel fees are important for preventing force closures too

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I think we're getting there. Next time you squash can you line-wrap the lines to 100 chars? Other than that, need another reviewer.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
let mut fee = updated_feerate * (predicted_weight as u64) / 1000;
let sweep_feerate = fee_estimator.bounded_sat_per_1000_weight(ConfirmationTarget::OnChainSweep);
let fee_rate = cmp::min(sweep_feerate, compute_feerate_sat_per_1000_weight(input_amounts / 2, predicted_weight as u64)) as u64;
let fee = fee_rate * (predicted_weight as u64) / 1000;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can use fee_for_weight here

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using that breaks a test, it has an extra -1 in it

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably because fee_for_weight will round up. That test isn't very accurate to begin with because it's estimating the witness weight, which can be off by a few units.

Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/ln/channel.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Responded to @wpaulino's review, good catches

Comment threadlightning/src/chain/package.rs

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, finally there from my end. Some remaining doc nits but I'm happy to land after this.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/chain/package.rs Outdated
@TheBlueMatt

Copy link
Copy Markdown
Collaborator

CI is mad cause there's a test that was checking an error message:

thread 'ln::functional_tests::accept_busted_but_better_fee' panicked at lightning/src/ln/functional_test_utils.rs:1491:17:
assertion `left == right` failed
left: ProcessingError { err: "Peer's feerate much too low. Actual: 1000. Our expected lower limit: 5000" }
right: ProcessingError { err: "Peer's feerate much too low. Actual: 1000. Our expected lower limit: 5000 (- 250)" }
stack backtrace:
0: rust_begin_unwind
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:595:5
1: core::panicking::panic_fmt
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:67:14
2: core::panicking::assert_failed_inner
3: core::panicking::assert_failed
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:229:5
4: lightning::ln::functional_test_utils::check_closed_event
at ./src/ln/functional_test_utils.rs:1491:5
5: lightning::ln::functional_tests::accept_busted_but_better_fee
at ./src/ln/functional_tests.rs:10016:4
6: lightning::ln::functional_tests::accept_busted_but_better_fee::{{closure}}
at ./src/ln/functional_tests.rs:9948:35
7: core::ops::function::FnOnce::call_once
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/ops/function.rs:250:5
8: core::ops::function::FnOnce::call_once
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
failures:
ln::functional_tests::accept_busted_but_better_fee

TheBlueMatt
TheBlueMatt previously approved these changes Oct 19, 2023

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to clean up the docs in a followup.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/ln/channel.rs
@TheBlueMatt
TheBlueMatt merged commit be8797e into lightningdevkit:mainOct 20, 2023
@benthecarman
benthecarman deleted the flexible-fee-rate branch October 20, 2023 17:48
PXplod pushed a commit to bitlightlabs/rust-lightning that referenced this pull request Sep 30, 2024
0.0.118 - Oct 23, 2023 - "Just the Twelve Sinks"
API Updates
===========
* BOLT12 sending and receiving is now supported as an alpha feature. You may
run into unexpected issues and will need to have a direct connection with
the offer's blinded path introduction points as messages are not yet routed.
We are seeking feedback from early testers (lightningdevkit#2578, lightningdevkit#2039).
* `ConfirmationTarget` has been rewritten to provide information about the
specific use LDK needs the feerate estimate for, rather than the generic
low-, medium-, and high-priority estimates. This allows LDK users to more
accurately target their feerate estimates (lightningdevkit#2660). For those wishing to
retain their existing behavior, see the table below for conversion.
* `ChainHash` is now used in place of `BlockHash` where it represents the
genesis block (lightningdevkit#2662).
* `lightning-invoice` payment utilities now take a `Deref` to
`AChannelManager` (lightningdevkit#2652).
* `peel_onion` is provided to statelessly decode an `OnionMessage` (lightningdevkit#2599).
* `ToSocketAddrs` + `Display` are now impl'd for `SocketAddress` (lightningdevkit#2636, lightningdevkit#2670)
* `Display` is now implemented for `OutPoint` (lightningdevkit#2649).
* `Features::from_be_bytes` is now provided (lightningdevkit#2640).
For those moving to the new `ConfirmationTarget`, the new variants in terms of
the old mempool/low/medium/high priorities are as follows:
* `OnChainSweep` = `HighPriority`
* `MaxAllowedNonAnchorChannelRemoteFee` = `max(25 * 250, HighPriority * 10)`
* `MinAllowedAnchorChannelRemoteFee` = `MempoolMinimum`
* `MinAllowedNonAnchorChannelRemoteFee` = `Background - 250`
* `AnchorChannelFee` = `Background`
* `NonAnchorChannelFee` = `Normal`
* `ChannelCloseMinimum` = `Background`
Bug Fixes
=========
* Calling `ChannelManager::close_channel[_with_feerate_and_script]` on a
channel which did not exist would immediately hang holding several key
`ChannelManager`-internal locks (lightningdevkit#2657).
* Channel information updates received from a failing HTLC are no longer
applied to our `NetworkGraph`. This prevents a node which we attempted to
route a payment through from being able to learn the sender of the payment.
In some rare cases, this may result in marginally reduced payment success
rates (lightningdevkit#2666).
* Anchor outputs are now properly considered when calculating the amount
available to send in HTLCs. This can prevent force-closes in anchor channels
when sending payments which overflow the available balance (lightningdevkit#2674).
* A peer that sends an `update_fulfill_htlc` message for a forwarded HTLC,
then reconnects prior to sending a `commitment_signed` (thus retransmitting
their `update_fulfill_htlc`) may result in the channel stalling and being
unable to make progress (lightningdevkit#2661).
* In exceedingly rare circumstances, messages intended to be sent to a peer
prior to reconnection can be sent after reconnection. This could result in
undefined channel state and force-closes (lightningdevkit#2663).
Backwards Compatibility
=======================
* Creating a blinded path to receive a payment then downgrading to LDK prior to
0.0.117 may result in failure to receive the payment (lightningdevkit#2413).
* Calling `ChannelManager::pay_for_offer` or
`ChannelManager::create_refund_builder` may prevent downgrading to LDK prior
to 0.0.118 until the payment times out and has been removed (lightningdevkit#2039).
Node Compatibility
==================
* LDK now sends a bogus `channel_reestablish` message to peers when they ask to
resume an unknown channel. This should cause LND nodes to force-close and
broadcast the latest channel state to the chain. In order to trigger this
when we wish to force-close a channel, LDK now disconnects immediately after
sending a channel-closing `error` message. This should result in cooperative
peers also working to confirm the latest commitment transaction when we wish
to force-close (lightningdevkit#2658).
Security
========
0.0.118 expands mitigations against transaction cycling attacks to non-anchor
channels, though note that no mitigations which exist today are considered robust
to prevent the class of attacks.
* In order to mitigate against transaction cycling attacks, non-anchor HTLC
transactions are now properly re-signed before broadcasting (lightningdevkit#2667).
In total, this release features 61 files changed, 3470 insertions, 1503
deletions in 85 commits from 12 authors, in alphabetical order:
* Antonio Yang
* Elias Rohrer
* Evan Feenstra
* Fedeparma74
* Gursharan Singh
* Jeffrey Czyz
* Matt Corallo
* Sergi Delgado Segura
* Vladimir Fomene
* Wilmer Paulino
* benthecarman
* slanesuke
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make Fee Estimator more flexible

4 participants

@benthecarman@TheBlueMatt@codecov-commenter@wpaulino
, 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' More flexible fee rate estimates by benthecarman · Pull Request #2660 · lightningdevkit/rust-lightning · GitHub
Skip to content

More flexible fee rate estimates - #2660

Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
benthecarman:flexible-fee-rate
Oct 20, 2023
Merged

More flexible fee rate estimates#2660
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
benthecarman:flexible-fee-rate

Conversation

@benthecarman

@benthecarmanbenthecarman commented Oct 12, 2023

Copy link
Copy Markdown
Contributor

Closes#2659

My attempt at making fee rate estimation more flexible. Names and docs need some work (happy for suggestions).

@TheBlueMatt

Copy link
Copy Markdown
Collaborator

My one real ask if about keeping Background, Normal, and HighPriority, the way they are used in compute_fee_from_spent_amounts doesn't really seem replaceable, maybe it is fine to keep them with this api.

compute_fee_from_spent_amounts is honestly pretty dumb. It just ladders down ConfirmationTarget, but it oculd, like, just use a lower feerate? Like subtract 1? Divide by two? I don't see why it does what it does, it should just use max(HtlcSweep, input_amounts / 2) or something like that.

@TheBlueMattTheBlueMatt added this to the 0.0.118 milestone Oct 13, 2023
@TheBlueMatt

Copy link
Copy Markdown
Collaborator

Tentatively setting 118, but if it doesnt make it it slips.

@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 2 times, most recently from 73686c6 to 3e39bccCompareOctober 14, 2023 00:39
@codecov-commenter

codecov-commenter commented Oct 14, 2023

Copy link
Copy Markdown

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (2c51080) 89.04% compared to head (9baac2f) 88.96%.
Report is 66 commits behind head on main.

❗ Current head 9baac2f differs from pull request most recent head dd15ab0. Consider uploading reports for the commit dd15ab0 to get more accurate results

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@ Coverage Diff @@## main #2660 +/- ##
==========================================
- Coverage 89.04% 88.96% -0.09% 
==========================================
Files 112 112 Lines 87229 87625 +396 Branches 87229 87625 +396 ==========================================
+ Hits 77674 77954 +280 - Misses 7319 7430 +111 - Partials 2236 2241 +5 
FilesCoverage Δ
lightning/src/chain/chaininterface.rs97.14% <100.00%> (ø)
lightning/src/chain/onchaintx.rs80.41% <100.00%> (-1.44%)⬇️
lightning/src/ln/channelmanager.rs81.32% <100.00%> (-0.31%)⬇️
lightning/src/ln/functional_tests.rs97.17% <100.00%> (-0.14%)⬇️
lightning/src/util/config.rs67.87% <ø> (ø)
lightning/src/util/test_utils.rs77.19% <100.00%> (+0.10%)⬆️
lightning/src/ln/channel.rs88.38% <91.66%> (+0.01%)⬆️
lightning/src/chain/package.rs87.65% <77.77%> (+1.00%)⬆️

... and 24 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@benthecarman
benthecarman marked this pull request as ready for review October 14, 2023 05:46
@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 2 times, most recently from 8257e6f to cbe6adfCompareOctober 14, 2023 23:13
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Responded to @TheBlueMatt's review

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all these docs need a good bit more verbiage to make them more friendly to folks newer to lightning, I suggested some alternative text for a few of them.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 3 times, most recently from 0f11c17 to 8e45e78CompareOctober 16, 2023 17:25
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Added some more color around why the min channel fees are important for preventing force closures too

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I think we're getting there. Next time you squash can you line-wrap the lines to 100 chars? Other than that, need another reviewer.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
let mut fee = updated_feerate * (predicted_weight as u64) / 1000;
let sweep_feerate = fee_estimator.bounded_sat_per_1000_weight(ConfirmationTarget::OnChainSweep);
let fee_rate = cmp::min(sweep_feerate, compute_feerate_sat_per_1000_weight(input_amounts / 2, predicted_weight as u64)) as u64;
let fee = fee_rate * (predicted_weight as u64) / 1000;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can use fee_for_weight here

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using that breaks a test, it has an extra -1 in it

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably because fee_for_weight will round up. That test isn't very accurate to begin with because it's estimating the witness weight, which can be off by a few units.

Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/ln/channel.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Responded to @wpaulino's review, good catches

Comment threadlightning/src/chain/package.rs

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, finally there from my end. Some remaining doc nits but I'm happy to land after this.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/chain/package.rs Outdated
@TheBlueMatt

Copy link
Copy Markdown
Collaborator

CI is mad cause there's a test that was checking an error message:

thread 'ln::functional_tests::accept_busted_but_better_fee' panicked at lightning/src/ln/functional_test_utils.rs:1491:17:
assertion `left == right` failed
left: ProcessingError { err: "Peer's feerate much too low. Actual: 1000. Our expected lower limit: 5000" }
right: ProcessingError { err: "Peer's feerate much too low. Actual: 1000. Our expected lower limit: 5000 (- 250)" }
stack backtrace:
0: rust_begin_unwind
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:595:5
1: core::panicking::panic_fmt
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:67:14
2: core::panicking::assert_failed_inner
3: core::panicking::assert_failed
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:229:5
4: lightning::ln::functional_test_utils::check_closed_event
at ./src/ln/functional_test_utils.rs:1491:5
5: lightning::ln::functional_tests::accept_busted_but_better_fee
at ./src/ln/functional_tests.rs:10016:4
6: lightning::ln::functional_tests::accept_busted_but_better_fee::{{closure}}
at ./src/ln/functional_tests.rs:9948:35
7: core::ops::function::FnOnce::call_once
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/ops/function.rs:250:5
8: core::ops::function::FnOnce::call_once
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
failures:
ln::functional_tests::accept_busted_but_better_fee

TheBlueMatt
TheBlueMatt previously approved these changes Oct 19, 2023

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to clean up the docs in a followup.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/ln/channel.rs
@TheBlueMatt
TheBlueMatt merged commit be8797e into lightningdevkit:mainOct 20, 2023
@benthecarman
benthecarman deleted the flexible-fee-rate branch October 20, 2023 17:48
PXplod pushed a commit to bitlightlabs/rust-lightning that referenced this pull request Sep 30, 2024
0.0.118 - Oct 23, 2023 - "Just the Twelve Sinks"
API Updates
===========
* BOLT12 sending and receiving is now supported as an alpha feature. You may
run into unexpected issues and will need to have a direct connection with
the offer's blinded path introduction points as messages are not yet routed.
We are seeking feedback from early testers (lightningdevkit#2578, lightningdevkit#2039).
* `ConfirmationTarget` has been rewritten to provide information about the
specific use LDK needs the feerate estimate for, rather than the generic
low-, medium-, and high-priority estimates. This allows LDK users to more
accurately target their feerate estimates (lightningdevkit#2660). For those wishing to
retain their existing behavior, see the table below for conversion.
* `ChainHash` is now used in place of `BlockHash` where it represents the
genesis block (lightningdevkit#2662).
* `lightning-invoice` payment utilities now take a `Deref` to
`AChannelManager` (lightningdevkit#2652).
* `peel_onion` is provided to statelessly decode an `OnionMessage` (lightningdevkit#2599).
* `ToSocketAddrs` + `Display` are now impl'd for `SocketAddress` (lightningdevkit#2636, lightningdevkit#2670)
* `Display` is now implemented for `OutPoint` (lightningdevkit#2649).
* `Features::from_be_bytes` is now provided (lightningdevkit#2640).
For those moving to the new `ConfirmationTarget`, the new variants in terms of
the old mempool/low/medium/high priorities are as follows:
* `OnChainSweep` = `HighPriority`
* `MaxAllowedNonAnchorChannelRemoteFee` = `max(25 * 250, HighPriority * 10)`
* `MinAllowedAnchorChannelRemoteFee` = `MempoolMinimum`
* `MinAllowedNonAnchorChannelRemoteFee` = `Background - 250`
* `AnchorChannelFee` = `Background`
* `NonAnchorChannelFee` = `Normal`
* `ChannelCloseMinimum` = `Background`
Bug Fixes
=========
* Calling `ChannelManager::close_channel[_with_feerate_and_script]` on a
channel which did not exist would immediately hang holding several key
`ChannelManager`-internal locks (lightningdevkit#2657).
* Channel information updates received from a failing HTLC are no longer
applied to our `NetworkGraph`. This prevents a node which we attempted to
route a payment through from being able to learn the sender of the payment.
In some rare cases, this may result in marginally reduced payment success
rates (lightningdevkit#2666).
* Anchor outputs are now properly considered when calculating the amount
available to send in HTLCs. This can prevent force-closes in anchor channels
when sending payments which overflow the available balance (lightningdevkit#2674).
* A peer that sends an `update_fulfill_htlc` message for a forwarded HTLC,
then reconnects prior to sending a `commitment_signed` (thus retransmitting
their `update_fulfill_htlc`) may result in the channel stalling and being
unable to make progress (lightningdevkit#2661).
* In exceedingly rare circumstances, messages intended to be sent to a peer
prior to reconnection can be sent after reconnection. This could result in
undefined channel state and force-closes (lightningdevkit#2663).
Backwards Compatibility
=======================
* Creating a blinded path to receive a payment then downgrading to LDK prior to
0.0.117 may result in failure to receive the payment (lightningdevkit#2413).
* Calling `ChannelManager::pay_for_offer` or
`ChannelManager::create_refund_builder` may prevent downgrading to LDK prior
to 0.0.118 until the payment times out and has been removed (lightningdevkit#2039).
Node Compatibility
==================
* LDK now sends a bogus `channel_reestablish` message to peers when they ask to
resume an unknown channel. This should cause LND nodes to force-close and
broadcast the latest channel state to the chain. In order to trigger this
when we wish to force-close a channel, LDK now disconnects immediately after
sending a channel-closing `error` message. This should result in cooperative
peers also working to confirm the latest commitment transaction when we wish
to force-close (lightningdevkit#2658).
Security
========
0.0.118 expands mitigations against transaction cycling attacks to non-anchor
channels, though note that no mitigations which exist today are considered robust
to prevent the class of attacks.
* In order to mitigate against transaction cycling attacks, non-anchor HTLC
transactions are now properly re-signed before broadcasting (lightningdevkit#2667).
In total, this release features 61 files changed, 3470 insertions, 1503
deletions in 85 commits from 12 authors, in alphabetical order:
* Antonio Yang
* Elias Rohrer
* Evan Feenstra
* Fedeparma74
* Gursharan Singh
* Jeffrey Czyz
* Matt Corallo
* Sergi Delgado Segura
* Vladimir Fomene
* Wilmer Paulino
* benthecarman
* slanesuke
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make Fee Estimator more flexible

4 participants

@benthecarman@TheBlueMatt@codecov-commenter@wpaulino
, 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); })(); More flexible fee rate estimates by benthecarman · Pull Request #2660 · lightningdevkit/rust-lightning · GitHub
Skip to content

More flexible fee rate estimates - #2660

Merged
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
benthecarman:flexible-fee-rate
Oct 20, 2023
Merged

More flexible fee rate estimates#2660
TheBlueMatt merged 1 commit into
lightningdevkit:mainfrom
benthecarman:flexible-fee-rate

Conversation

@benthecarman

@benthecarmanbenthecarman commented Oct 12, 2023

Copy link
Copy Markdown
Contributor

Closes#2659

My attempt at making fee rate estimation more flexible. Names and docs need some work (happy for suggestions).

@TheBlueMatt

Copy link
Copy Markdown
Collaborator

My one real ask if about keeping Background, Normal, and HighPriority, the way they are used in compute_fee_from_spent_amounts doesn't really seem replaceable, maybe it is fine to keep them with this api.

compute_fee_from_spent_amounts is honestly pretty dumb. It just ladders down ConfirmationTarget, but it oculd, like, just use a lower feerate? Like subtract 1? Divide by two? I don't see why it does what it does, it should just use max(HtlcSweep, input_amounts / 2) or something like that.

@TheBlueMattTheBlueMatt added this to the 0.0.118 milestone Oct 13, 2023
@TheBlueMatt

Copy link
Copy Markdown
Collaborator

Tentatively setting 118, but if it doesnt make it it slips.

@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 2 times, most recently from 73686c6 to 3e39bccCompareOctober 14, 2023 00:39
@codecov-commenter

codecov-commenter commented Oct 14, 2023

Copy link
Copy Markdown

Codecov Report

Attention: 3 lines in your changes are missing coverage. Please review.

Comparison is base (2c51080) 89.04% compared to head (9baac2f) 88.96%.
Report is 66 commits behind head on main.

❗ Current head 9baac2f differs from pull request most recent head dd15ab0. Consider uploading reports for the commit dd15ab0 to get more accurate results

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files
@@ Coverage Diff @@## main #2660 +/- ##
==========================================
- Coverage 89.04% 88.96% -0.09% 
==========================================
Files 112 112 Lines 87229 87625 +396 Branches 87229 87625 +396 ==========================================
+ Hits 77674 77954 +280 - Misses 7319 7430 +111 - Partials 2236 2241 +5 
FilesCoverage Δ
lightning/src/chain/chaininterface.rs97.14% <100.00%> (ø)
lightning/src/chain/onchaintx.rs80.41% <100.00%> (-1.44%)⬇️
lightning/src/ln/channelmanager.rs81.32% <100.00%> (-0.31%)⬇️
lightning/src/ln/functional_tests.rs97.17% <100.00%> (-0.14%)⬇️
lightning/src/util/config.rs67.87% <ø> (ø)
lightning/src/util/test_utils.rs77.19% <100.00%> (+0.10%)⬆️
lightning/src/ln/channel.rs88.38% <91.66%> (+0.01%)⬆️
lightning/src/chain/package.rs87.65% <77.77%> (+1.00%)⬆️

... and 24 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@benthecarman
benthecarman marked this pull request as ready for review October 14, 2023 05:46
@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 2 times, most recently from 8257e6f to cbe6adfCompareOctober 14, 2023 23:13
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Responded to @TheBlueMatt's review

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think all these docs need a good bit more verbiage to make them more friendly to folks newer to lightning, I suggested some alternative text for a few of them.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman
benthecarmanforce-pushed the flexible-fee-rate branch 3 times, most recently from 0f11c17 to 8e45e78CompareOctober 16, 2023 17:25
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Added some more color around why the min channel fees are important for preventing force closures too

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I think we're getting there. Next time you squash can you line-wrap the lines to 100 chars? Other than that, need another reviewer.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
let mut fee = updated_feerate * (predicted_weight as u64) / 1000;
let sweep_feerate = fee_estimator.bounded_sat_per_1000_weight(ConfirmationTarget::OnChainSweep);
let fee_rate = cmp::min(sweep_feerate, compute_feerate_sat_per_1000_weight(input_amounts / 2, predicted_weight as u64)) as u64;
let fee = fee_rate * (predicted_weight as u64) / 1000;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can use fee_for_weight here

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using that breaks a test, it has an extra -1 in it

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably because fee_for_weight will round up. That test isn't very accurate to begin with because it's estimating the witness weight, which can be off by a few units.

Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/ln/channel.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
@benthecarman

Copy link
Copy Markdown
ContributorAuthor

Responded to @wpaulino's review, good catches

Comment threadlightning/src/chain/package.rs

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, finally there from my end. Some remaining doc nits but I'm happy to land after this.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/ln/channel.rs
Comment threadlightning/src/chain/package.rs Outdated
@TheBlueMatt

Copy link
Copy Markdown
Collaborator

CI is mad cause there's a test that was checking an error message:

thread 'ln::functional_tests::accept_busted_but_better_fee' panicked at lightning/src/ln/functional_test_utils.rs:1491:17:
assertion `left == right` failed
left: ProcessingError { err: "Peer's feerate much too low. Actual: 1000. Our expected lower limit: 5000" }
right: ProcessingError { err: "Peer's feerate much too low. Actual: 1000. Our expected lower limit: 5000 (- 250)" }
stack backtrace:
0: rust_begin_unwind
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:595:5
1: core::panicking::panic_fmt
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:67:14
2: core::panicking::assert_failed_inner
3: core::panicking::assert_failed
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:229:5
4: lightning::ln::functional_test_utils::check_closed_event
at ./src/ln/functional_test_utils.rs:1491:5
5: lightning::ln::functional_tests::accept_busted_but_better_fee
at ./src/ln/functional_tests.rs:10016:4
6: lightning::ln::functional_tests::accept_busted_but_better_fee::{{closure}}
at ./src/ln/functional_tests.rs:9948:35
7: core::ops::function::FnOnce::call_once
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/ops/function.rs:250:5
8: core::ops::function::FnOnce::call_once
at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
failures:
ln::functional_tests::accept_busted_but_better_fee

TheBlueMatt
TheBlueMatt previously approved these changes Oct 19, 2023

@TheBlueMattTheBlueMatt left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to clean up the docs in a followup.

Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/package.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/chain/chaininterface.rs Outdated
Comment threadlightning/src/ln/channel.rs
@TheBlueMatt
TheBlueMatt merged commit be8797e into lightningdevkit:mainOct 20, 2023
@benthecarman
benthecarman deleted the flexible-fee-rate branch October 20, 2023 17:48
PXplod pushed a commit to bitlightlabs/rust-lightning that referenced this pull request Sep 30, 2024
0.0.118 - Oct 23, 2023 - "Just the Twelve Sinks"
API Updates
===========
* BOLT12 sending and receiving is now supported as an alpha feature. You may
run into unexpected issues and will need to have a direct connection with
the offer's blinded path introduction points as messages are not yet routed.
We are seeking feedback from early testers (lightningdevkit#2578, lightningdevkit#2039).
* `ConfirmationTarget` has been rewritten to provide information about the
specific use LDK needs the feerate estimate for, rather than the generic
low-, medium-, and high-priority estimates. This allows LDK users to more
accurately target their feerate estimates (lightningdevkit#2660). For those wishing to
retain their existing behavior, see the table below for conversion.
* `ChainHash` is now used in place of `BlockHash` where it represents the
genesis block (lightningdevkit#2662).
* `lightning-invoice` payment utilities now take a `Deref` to
`AChannelManager` (lightningdevkit#2652).
* `peel_onion` is provided to statelessly decode an `OnionMessage` (lightningdevkit#2599).
* `ToSocketAddrs` + `Display` are now impl'd for `SocketAddress` (lightningdevkit#2636, lightningdevkit#2670)
* `Display` is now implemented for `OutPoint` (lightningdevkit#2649).
* `Features::from_be_bytes` is now provided (lightningdevkit#2640).
For those moving to the new `ConfirmationTarget`, the new variants in terms of
the old mempool/low/medium/high priorities are as follows:
* `OnChainSweep` = `HighPriority`
* `MaxAllowedNonAnchorChannelRemoteFee` = `max(25 * 250, HighPriority * 10)`
* `MinAllowedAnchorChannelRemoteFee` = `MempoolMinimum`
* `MinAllowedNonAnchorChannelRemoteFee` = `Background - 250`
* `AnchorChannelFee` = `Background`
* `NonAnchorChannelFee` = `Normal`
* `ChannelCloseMinimum` = `Background`
Bug Fixes
=========
* Calling `ChannelManager::close_channel[_with_feerate_and_script]` on a
channel which did not exist would immediately hang holding several key
`ChannelManager`-internal locks (lightningdevkit#2657).
* Channel information updates received from a failing HTLC are no longer
applied to our `NetworkGraph`. This prevents a node which we attempted to
route a payment through from being able to learn the sender of the payment.
In some rare cases, this may result in marginally reduced payment success
rates (lightningdevkit#2666).
* Anchor outputs are now properly considered when calculating the amount
available to send in HTLCs. This can prevent force-closes in anchor channels
when sending payments which overflow the available balance (lightningdevkit#2674).
* A peer that sends an `update_fulfill_htlc` message for a forwarded HTLC,
then reconnects prior to sending a `commitment_signed` (thus retransmitting
their `update_fulfill_htlc`) may result in the channel stalling and being
unable to make progress (lightningdevkit#2661).
* In exceedingly rare circumstances, messages intended to be sent to a peer
prior to reconnection can be sent after reconnection. This could result in
undefined channel state and force-closes (lightningdevkit#2663).
Backwards Compatibility
=======================
* Creating a blinded path to receive a payment then downgrading to LDK prior to
0.0.117 may result in failure to receive the payment (lightningdevkit#2413).
* Calling `ChannelManager::pay_for_offer` or
`ChannelManager::create_refund_builder` may prevent downgrading to LDK prior
to 0.0.118 until the payment times out and has been removed (lightningdevkit#2039).
Node Compatibility
==================
* LDK now sends a bogus `channel_reestablish` message to peers when they ask to
resume an unknown channel. This should cause LND nodes to force-close and
broadcast the latest channel state to the chain. In order to trigger this
when we wish to force-close a channel, LDK now disconnects immediately after
sending a channel-closing `error` message. This should result in cooperative
peers also working to confirm the latest commitment transaction when we wish
to force-close (lightningdevkit#2658).
Security
========
0.0.118 expands mitigations against transaction cycling attacks to non-anchor
channels, though note that no mitigations which exist today are considered robust
to prevent the class of attacks.
* In order to mitigate against transaction cycling attacks, non-anchor HTLC
transactions are now properly re-signed before broadcasting (lightningdevkit#2667).
In total, this release features 61 files changed, 3470 insertions, 1503
deletions in 85 commits from 12 authors, in alphabetical order:
* Antonio Yang
* Elias Rohrer
* Evan Feenstra
* Fedeparma74
* Gursharan Singh
* Jeffrey Czyz
* Matt Corallo
* Sergi Delgado Segura
* Vladimir Fomene
* Wilmer Paulino
* benthecarman
* slanesuke
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make Fee Estimator more flexible

4 participants

@benthecarman@TheBlueMatt@codecov-commenter@wpaulino