expose `feerate_per_kw` in `ChannelDetails` by johncantrell97 · Pull Request #2094 · lightningdevkit/rust-lightning

johncantrell97 · 2023-03-09T22:04:21Z

Wanted to be able to monitor this for channels with disconnected peers. Closes#2093

codecov-commenter · 2023-03-09T22:42:02Z

Codecov Report

Patch coverage: 100.00% and project coverage change: +0.11 🎉

Comparison is base (36834b3) 91.14% compared to head (d76b43f) 91.25%.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files

@@ Coverage Diff @@## main #2094 +/- ##
==========================================
+ Coverage 91.14% 91.25% +0.11% 
==========================================
Files 101 101 Lines 48887 51613 +2726 Branches 48887 51613 +2726 ==========================================
+ Hits 44557 47101 +2544 - Misses 4330 4512 +182

Impacted Files	Coverage Δ
lightning/src/ln/functional_test_utils.rs	`93.79% <ø> (+1.28%)`	⬆️
lightning/src/routing/router.rs	`94.82% <ø> (+0.08%)`	⬆️
lightning/src/ln/channel.rs	`89.83% <100.00%> (+0.47%)`	⬆️
lightning/src/ln/channelmanager.rs	`91.19% <100.00%> (+2.32%)`	⬆️

... and 9 files with indirect coverage changes

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

tnull

Looks good! Would suggest to give the full unit in the field name, see below.

tnull · 2023-03-10T12:31:57Z

 	/// inbound. This may be zero for inbound channels serialized with LDK versions prior to
 	/// 0.0.113.
 	pub user_channel_id: u128,
+	/// The currently negotiated feerate per 1000-weight-unit applied to commitment and htlc txs


Suggested change
/// The currently negotiated feerate per 1000-weight-unit applied to commitment and htlc txs
/// The currently negotiated fee rate denominated in satoshi per 1000weight units, which is applied to commitment and HTLC transactions.

tnull · 2023-03-10T12:38:00Z

+	/// The currently negotiated feerate per 1000-weight-unit applied to commitment and htlc txs
+	///
+	/// This value will be `None` for objects serialized with LDK versions prior to 0.0.115.
+	pub feerate_per_kw: Option<u32>,


To avoid any uncertainty and to align this a bit more with the FeeEstimator interface, could we name this feerate_sat_per_kw or feerate_sat_per_1000_weight?

Yeah, I prefer the latter. I find kw a little confusing if it's been a while since I've looked at fee rate units.

Hm, did just notice that feerate_per_kw is used for HolderSignedTx, CommitmentTransaction, and in a few other function calls. It's not really related to this change but perhaps a global replacement makes sense.

Mh, I'm not sure if this warrants a lot of git noise, so we may just want to change it here and in related parts of the public API to feerate_sat_per_kw or similar.

tnull · 2023-03-10T12:40:40Z

 outbound_scid_alias: if channel.is_usable() { Some(channel.outbound_scid_alias()) } else { None },
 inbound_scid_alias: channel.latest_inbound_scid_alias(),
 channel_value_satoshis: channel.get_value_satoshis(),
+ feerate_per_kw: Some(channel.get_feerate()),


Maybe it would be to include a tiny refactor while you're here and rename Channel::get_feerate to get_feerate_sat_per_kw?

dunxen · 2023-03-10T14:39:24Z

 inbound_htlc_minimum_msat: None,
 inbound_htlc_maximum_msat: None,
 config: None,
+ feerate_sat_per_1000_weight: None


nit: Maybe very nit picky, but should it not be "sats"?

I don't think so, as it's FeeEstimator::get_est_sat_per_1000_weight already and the unit symbol is sat (cf. https://bitcoin.design/guide/designing-products/units-and-symbols/).

Right for unit symbol makes sense, also didn't remember existing usage

@johncantrell97 On that note, as you're already touching ChannelManager, you could also rename the target_feerate_sats_per_1000_weight argument of ChannelManager::close_channel_with_target_feerate to target_feerate_sat_per_1000_weight .

I'm confused, it's plural, the design guide linked says explicitly plural is "sats"? Not like it matters tho.

Oh my, you're actually right. I read the guide and seem to have switched it around in my head. I still think units should be singular (you wouldn't use "USDs" or "BTCs"), but will now shut up and eat my words on the basis of the guide I linked to myself. 🤦‍♂️

i have no hard opinion on this to be honest ¯_(ツ)_/¯

I prefer sats but am now seeing that it's indeed already mixed usage in the code base so maybe it's a future cleanup that is needed?

dunxen · 2023-03-13T21:56:19Z

The field name just needs an update

error[E0560]: struct `ChannelDetails` has no field named `feerate_per_kw`
--> lightning/src/routing/router.rs:5741:4
|
5741 | feerate_per_kw: None,
| ^^^^^^^^^^^^^^ `ChannelDetails` does not have this field

renames Channel::get_feerate to get_feerate_sat_per_1000_weight

0.0.115 - Apr 24, 2023 - "Rebroadcast the Bugfixes" API Updates =========== * The MSRV of the main LDK crates has been increased to 1.48 (lightningdevkit#2107). * Attempting to claim an un-expired payment on a channel which has closed no longer fails. The expiry time of payments is exposed via `PaymentClaimable::claim_deadline` (lightningdevkit#2148). * `payment_metadata` is now supported in `Invoice` deserialization, sending, and receiving (via a new `RecipientOnionFields` struct) (lightningdevkit#2139, lightningdevkit#2127). * `Event::PaymentFailed` now exposes a failure reason (lightningdevkit#2142). * BOLT12 messages now support stateless generation and validation (lightningdevkit#1989). * The `NetworkGraph` is now pruned of stale data after RGS processing (lightningdevkit#2161). * Max inbound HTLCs in-flight can be changed in the handshake config (lightningdevkit#2138). * `lightning-transaction-sync` feature `esplora-async-https` was added (lightningdevkit#2085). * A `ChannelPending` event is now emitted after the initial handshake (lightningdevkit#2098). * `PaymentForwarded::outbound_amount_forwarded_msat` was added (lightningdevkit#2136). * `ChannelManager::list_channels_by_counterparty` was added (lightningdevkit#2079). * `ChannelDetails::feerate_sat_per_1000_weight` was added (lightningdevkit#2094). * `Invoice::fallback_addresses` was added to fetch `bitcoin` types (lightningdevkit#2023). * The offer/refund description is now exposed in `Invoice{,Request}` (lightningdevkit#2206). Backwards Compatibility ======================= * Payments sent with the legacy `*_with_route` methods on LDK 0.0.115+ will no longer be retryable via the LDK 0.0.114- `retry_payment` method (lightningdevkit#2139). * `Event::PaymentPathFailed::retry` was removed and will always be `None` for payments initiated on 0.0.115 which fail on an earlier version (lightningdevkit#2063). * `Route`s and `PaymentParameters` with blinded path information will not be readable on prior versions of LDK. Such objects are not currently constructed by LDK, but may be when processing BOLT12 data in a coming release (lightningdevkit#2146). * Providing `ChannelMonitorUpdate`s generated by LDK 0.0.115 to a `ChannelMonitor` on 0.0.114 or before may panic (lightningdevkit#2059). Note that this is in general unsupported, and included here only for completeness. Bug Fixes ========= * Fixed a case where `process_events_async` may `poll` a `Future` which has already completed (lightningdevkit#2081). * Fixed deserialization of `u16` arrays. This bug may have previously corrupted the historical buckets in a `ProbabilisticScorer`. Users relying on the historical buckets may wish to wipe their scorer on upgrade to remove corrupt data rather than waiting on it to decay (lightningdevkit#2191). * The `process_events_async` task is now `Send` and can thus be polled on a multi-threaded runtime (lightningdevkit#2199). * Fixed a missing macro export causing `impl_writeable_tlv_based_enum{,_upgradable}` calls to not compile (lightningdevkit#2091). * Fixed compilation of `lightning-invoice` with both `no-std` and serde (lightningdevkit#2187) * Fix an issue where the `background-processor` would not wake when a `ChannelMonitorUpdate` completed asynchronously, causing delays (lightningdevkit#2090). * Fix an issue where `process_events_async` would exit immediately (lightningdevkit#2145). * `Router` calls from the `ChannelManager` now call `find_route_with_id` rather than `find_route`, as was intended and described in the API (lightningdevkit#2092). * Ensure `process_events_async` always exits if any sleep future returns true, not just if all sleep futures repeatedly return true (lightningdevkit#2145). * `channel_update` messages no longer set the disable bit unless the peer has been disconnected for some time. This should resolve cases where channels are disabled for extended periods of time (lightningdevkit#2198). * We no longer remove CLN nodes from the network graph for violating the BOLT spec in some cases after failing to pay through them (lightningdevkit#2220). * Fixed a debug assertion which may panic under heavy load (lightningdevkit#2172). * `CounterpartyForceClosed::peer_msg` is now wrapped in UntrustedString (lightningdevkit#2114) * Fixed a potential deadlock in `funding_transaction_generated` (lightningdevkit#2158). Security ======== * Transaction re-broadcasting is now substantially more aggressive, including a new regular rebroadcast feature called on a timer from the `background-processor` or from `ChainMonitor::rebroadcast_pending_claims`. This should substantially increase transaction confirmation reliability without relying on downstream `TransactionBroadcaster` implementations for rebroadcasting (lightningdevkit#2203, lightningdevkit#2205, lightningdevkit#2208). * Implemented the changes from BOLT PRs lightningdevkit#1031, lightningdevkit#1032, and lightningdevkit#1040 which resolve a privacy vulnerability which allows an intermediate node on the path to discover the final destination for a payment (lightningdevkit#2062). In total, this release features 110 files changed, 11928 insertions, 6368 deletions in 215 commits from 21 authors, in alphabetical order: * Advait * Alan Cohen * Alec Chen * Allan Douglas R. de Oliveira * Arik Sosman * Elias Rohrer * Evan Feenstra * Jeffrey Czyz * John Cantrell * Lucas Soriano del Pino * Marc Tyndel * Matt Corallo * Paul Miller * Steven * Steven Williamson * Steven Zhao * Tony Giorgio * Valentine Wallace * Wilmer Paulino * benthecarman * munjesi

johncantrell97 force-pushed the expose-fee branch 2 times, most recently from f5f774c to 63d3be8Compare March 9, 2023 22:34

tnull reviewed Mar 10, 2023
View reviewed changes

johncantrell97 force-pushed the expose-fee branch from 63d3be8 to e26dc51Compare March 10, 2023 14:29

dunxen previously approved these changes Mar 10, 2023
View reviewed changes

expose feerate_sat_per_1000_weight in ChannelDetails
d76b43f
renames Channel::get_feerate to get_feerate_sat_per_1000_weight

johncantrell97 dismissed dunxen’s stale review via d76b43fMarch 15, 2023 17:36

johncantrell97 force-pushed the expose-fee branch from e26dc51 to d76b43fCompare March 15, 2023 17:36

TheBlueMatt approved these changes Mar 15, 2023
View reviewed changes

TheBlueMatt assigned tnull and dunxen Mar 15, 2023

dunxen approved these changes Mar 15, 2023
View reviewed changes

TheBlueMatt merged commit 12d799e into lightningdevkit:mainMar 15, 2023

johncantrell97 deleted the expose-fee branch March 15, 2023 21:55

	/// The currently negotiated feerate per 1000-weight-unit applied to commitment and htlc txs
	/// The currently negotiated fee rate denominated in satoshi per 1000weight units, which is applied to commitment and HTLC transactions.

Uh oh!

Conversation

johncantrell97 commented Mar 9, 2023

Uh oh!

codecov-commenter commented Mar 9, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

tnull left a comment

Choose a reason for hiding this comment

Uh oh!

tnullMar 10, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

johncantrell97Mar 10, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dunxenMar 10, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tnullMar 13, 2023• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dunxen commented Mar 13, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

codecov-commenter commented Mar 9, 2023•
edited
Loading

tnullMar 10, 2023•
edited
Loading

johncantrell97Mar 10, 2023•
edited
Loading

dunxenMar 10, 2023•
edited
Loading

tnullMar 13, 2023•
edited
Loading