Uh oh!
There was an error while loading. Please reload this page.
Expose amount forwarded in PaymentForwarded event - #2136
Conversation
6823642 to
3ad0f09Compare| claim_from_onchain_tx: from_onchain, | ||
| prev_channel_id, | ||
| next_channel_id, | ||
| amount_forwarded_msat: forwarded_htlc_value_msat, |
| claim_from_onchain_tx: bool, | ||
| /// The final amount forwarded, in milli-satoshis, after the fee is deducted. | ||
| /// The caveat described above the `fee_earned_msat` field applies here as well. | ||
| amount_forwarded_msat: Option<u64>, |
There was a problem hiding this comment.
Is there a name that more clearly indicates this is the outbound amount we forwarded downstream, rather than the amount we received? I think this is fine just want to make sure we don't see anything obviously better, I don't have any ideas, though.
There was a problem hiding this comment.
Something like amount_outbound_forwarded_msat?
There was a problem hiding this comment.
maybe outgoing_amount_forwarded_msat? 🤷
There was a problem hiding this comment.
Going with a blend of the above: outbound_amount_forwarded_msat (because HTLCIntercepted, also uses the word "outbound"...I do see "outgoing" is used elsewhere but at a glance not in anything exposed)
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| claim_from_onchain_tx: bool, | ||
| /// The final amount forwarded, in milli-satoshis, after the fee is deducted. | ||
| /// The caveat described above the `fee_earned_msat` field applies here as well. | ||
| amount_forwarded_msat: Option<u64>, |
There was a problem hiding this comment.
maybe outgoing_amount_forwarded_msat? 🤷
TheBlueMatt
commented
Mar 28, 2023
Feel free to squash the fixup commit(s) down when you next push. |
6b3b0c9 to
cf3c211CompareCodecov ReportPatch coverage:
📣 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 #2136 +/- ##
==========================================
- Coverage 91.40% 91.37% -0.04%
==========================================
Files 102 102 Lines 49736 49568 -168 Branches 49736 49568 -168 ==========================================
- Hits 45461 45291 -170 - Misses 4275 4277 +2
... and 7 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. |
| assert_eq!(events.len(), 1); | ||
| match events[0] { | ||
| Event::PaymentForwarded { fee_earned_msat, prev_channel_id, claim_from_onchain_tx, next_channel_id } => { | ||
| Event::PaymentForwarded { fee_earned_msat, prev_channel_id, claim_from_onchain_tx, next_channel_id, .. } => { |
There was a problem hiding this comment.
Question: for this test macro, if I add the new field, I get stuck trying to update the mid_update_fulfill_dance macro, because I can't see how to get the amount. I notice that fee is obtained there in a perhaps indirect way, by getting the forwarding_fee_base_msat from the channel config (meaning the test is run with 0 proportional fees), which suggests getting the amount from the HTLC might not straightforward here? Or I might be missing something.
There was a problem hiding this comment.
Hmm, yea, you could do a few different things - you could add a new macro variant (ie the top level ($node,,, thing you can just add another one with a new parameter), you could indeed try to deduce the correct amount based on the fee fetched from the channel (though a few tests will fail that), or you could just not worry about it. The code here is simple enough and there are at least a few tests which exercise it, so I'm admittedly not super worried about ensuring we have Maximal Test Coverage of it.
There was a problem hiding this comment.
Then if everyone's okay with it I'll go with the "just not worry about it" option
tnull
left a comment
There was a problem hiding this comment.
Generally looks good to me, just some minor remarks/suggestions.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
cf3c211 to
ee2cb8eCompare0.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
This PR adds the amount forwarded to
PaymentForwardedevents.We'd like this value for analytics. At the moment I've been computing it using
fee_earned_msatand the outbound channel's forwarding policy, but this introduces rounding error (and I think could occasionally be incorrect if the policy was recently updated but not yet propagated).