Expose {prev,next}_user_channel_id fields in PaymentForwarded
#2924
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Note Reviews PausedUse the following commands to manage reviews:
WalkthroughThe recent updates enhance the handling of payment forwarding within the Lightning Network's codebase, specifically by refining the Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
tnull
force-pushed
the
2024-03-add-user-channel-id-to-payment-forwarded
branch
from
063595e to
42a69f2
Compare
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (3)
- lightning/src/events/mod.rs (4 hunks)
- lightning/src/ln/channelmanager.rs (9 hunks)
- lightning/src/ln/functional_test_utils.rs (2 hunks)
Files not reviewed due to errors (1)
- (no review received)
Additional comments: 10
lightning/src/events/mod.rs (1)
- 800-817: The addition of
prev_user_channel_idandnext_user_channel_idto thePaymentForwardedevent is a significant enhancement for tracking payments and channels byuser_channel_id. This change directly addresses the PR's objective to streamline the process of tracking payments and channels, thereby optimizing resource usage and simplifying the codebase for developers working on related functionalities.lightning/src/ln/channelmanager.rs (9)
- 5736-5736: The addition of
next_user_channel_idto theclaim_funds_internalfunction signature is aligned with the PR's objectives. Ensure that this new parameter is integrated correctly throughout the system and that its usage is consistent with the intended tracking enhancements.- 5755-5755: Introduction of
prev_user_channel_idis consistent with the PR's objectives of enhancing payment tracking. Verify its effective usage and ensure it does not introduce unintended side effects.- 5816-5816: Ensure that the conditional check involving
prev_channel_idis correctly implemented and necessary for the intended enhancements.- 5842-5843: Augmentation of the
PaymentForwardedevent withprev_user_channel_idandnext_user_channel_idaligns with the PR's objectives. Verify its impact on the event's usage across the system to ensure it contributes to the intended simplification and optimization.- 6821-6821: Introduction of
next_user_channel_idin theinternal_update_fulfill_htlcfunction is consistent with the PR's objectives. Verify its integration and usage within the function and related functionalities to ensure it does not disrupt existing processes.- 6851-6851: Assignment of
next_user_channel_idwithin this conditional block is consistent with the PR's objectives. Verify its correct implementation and impact on related functionalities to ensure it does not introduce unintended side effects.- 6863-6863: The call to
claim_funds_internalwithnext_user_channel_idas a parameter aligns with the PR's objectives. Verify its integration and impact on the system to ensure it contributes to the intended enhancements.- 7365-7365: The call to
claim_funds_internalwithoutnext_user_channel_idin this context appears to be a specific case. Verify the justification for not includingnext_user_channel_idto ensure it aligns with the PR's objectives and does not introduce inconsistencies.- 11325-11325: The call to
claim_funds_internalwithoutnext_user_channel_idin this context appears to be another specific case. Verify the justification for not includingnext_user_channel_idto ensure it aligns with the PR's objectives and does not introduce inconsistencies.
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (3)
- lightning/src/events/mod.rs (4 hunks)
- lightning/src/ln/channelmanager.rs (9 hunks)
- lightning/src/ln/functional_test_utils.rs (2 hunks)
Files skipped from review as they are similar to previous changes (3)
- lightning/src/events/mod.rs
- lightning/src/ln/channelmanager.rs
- lightning/src/ln/functional_test_utils.rs
tnull
force-pushed
the
2024-03-add-user-channel-id-to-payment-forwarded
branch
from
42a69f2 to
7b6a355
Compare
|
@coderabbitai pause, now! |
|
@tnull: Understood, pausing the automated reviews now. Actions performedReviews paused. |
Codecov ReportAttention: Patch coverage is
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #2924 +/- ##
==========================================
+ Coverage 89.15% 90.03% +0.87%
==========================================
Files 117 117
Lines 94868 100403 +5535
Branches 94868 100403 +5535
==========================================
+ Hits 84584 90396 +5812
+ Misses 7808 7560 -248
+ Partials 2476 2447 -29 ☔ View full report in Codecov by Sentry. |
tnull
force-pushed
the
2024-03-add-user-channel-id-to-payment-forwarded
branch
from
7b6a355 to
a062317
Compare
valentinewallace
previously approved these changes
Mar 7, 2024
| @@ -7359,7 +7364,7 @@ where | |||
| log_trace!(logger, "Claiming HTLC with preimage {} from our monitor", preimage); | |||
| self.claim_funds_internal(htlc_update.source, preimage, | |||
| htlc_update.htlc_value_satoshis.map(|v| v * 1000), None, true, | |||
| false, counterparty_node_id, funding_outpoint, channel_id); | |||
| false, counterparty_node_id, funding_outpoint, channel_id, None); | |||
There was a problem hiding this comment.
Would we consider including this field in MonitorEvents in the future so it can be available here?
There was a problem hiding this comment.
Thought about that too, but that might require starting to track it in the ChannelMonitors first, which might be a bit out-of-scope?
There was a problem hiding this comment.
We also currently don't have any concept of how to handle user channel ids after a channel closes - is recycling allowed at that point?
| @@ -6857,7 +6862,7 @@ where | |||
| }; | |||
| self.claim_funds_internal(htlc_source, msg.payment_preimage.clone(), | |||
| Some(forwarded_htlc_value), skimmed_fee_msat, false, false, Some(*counterparty_node_id), | |||
| funding_txo, msg.channel_id | |||
| funding_txo, msg.channel_id, Some(next_user_channel_id), | |||
There was a problem hiding this comment.
FWIW, tests pass when I revert this change.
There was a problem hiding this comment.
Ugh, good catch. That's due to the map_or in the test which makes it too forgiving. I'll see to revisit that.
There was a problem hiding this comment.
Now pushed a fixup to the test: #2924 (comment)
It's not perfect, but I wanted to avoid cluttering the macro by introducing yet another expected_X variable just for this slim use case. Let me know if you'd prefer it over the current approach though.
tnull
dismissed stale reviews from valentinewallace and TheBlueMatt
via
d909a4e
tnull
force-pushed
the
2024-03-add-user-channel-id-to-payment-forwarded
branch
from
a062317 to
d909a4e
Compare
This is useful for users that track channels by `user_channel_id`. For example, in `lightning-liquidity` we currently keep a full `HashMap<ChanelId, u128>` around *just* to be able to associate `PaymentForwarded` events with the channels otherwise tracked by `user_channel_id`.
.. as it's the same as `prev_channel_id` defined a few lines above.
tnull
force-pushed
the
2024-03-add-user-channel-id-to-payment-forwarded
branch
from
d909a4e to
ab4b872
Compare
|
Now pushed a minor fixup to the test: > git diff-tree -U2 a062317 ab4b872
diff --git a/lightning/src/ln/functional_test_utils.rs b/lightning/src/ln/functional_test_utils.rs
index 7319a28a0..0c8909b56 100644
--- a/lightning/src/ln/functional_test_utils.rs
+++ b/lightning/src/ln/functional_test_utils.rs
@@ -2250,9 +2250,20 @@ pub fn expect_payment_forwarded<CM: AChannelManager, H: NodeHolder<CM=CM>>(
// node's channel list
if !downstream_force_closed {
- assert!(node.node().list_channels().iter().any(|x|
- x.counterparty.node_id == next_node.node().get_our_node_id() &&
- x.channel_id == next_channel_id.unwrap() &&
- next_user_channel_id.map_or(true, |user_id| x.user_channel_id == user_id)
- ));
+ // As documented, `next_user_channel_id` will only be `Some` if we didn't settle via an
+ // onchain transaction, just as the `total_fee_earned_msat` field. Rather than
+ // introducing yet another variable, we use the latter's state as a flag to detect
+ // this and only check if it's `Some`.
+ if total_fee_earned_msat.is_none() {
+ assert!(node.node().list_channels().iter().any(|x|
+ x.counterparty.node_id == next_node.node().get_our_node_id() &&
+ x.channel_id == next_channel_id.unwrap()
+ ));
+ } else {
+ assert!(node.node().list_channels().iter().any(|x|
+ x.counterparty.node_id == next_node.node().get_our_node_id() &&
+ x.channel_id == next_channel_id.unwrap() &&
+ x.user_channel_id == next_user_channel_id.unwrap()
+ ));
+ }
}
assert_eq!(claim_from_onchain_tx, downstream_force_closed); |
TheBlueMatt
approved these changes
Mar 20, 2024
valentinewallace
approved these changes
Mar 20, 2024
valentinewallace
merged commit a36b529
into
lightningdevkit:main
13 of 16 checks passed
k0k0ne
pushed a commit
to bitlightlabs/rust-lightning
that referenced
this pull request
Sep 30, 2024
v0.0.123 - May 08, 2024 - "BOLT12 Dust Sweeping" API Updates =========== * To reduce risk of force-closures and improve HTLC reliability the default dust exposure limit has been increased to `MaxDustHTLCExposure::FeeRateMultiplier(10_000)`. Users with existing channels might want to consider using `ChannelManager::update_channel_config` to apply the new default (lightningdevkit#3045). * `ChainMonitor::archive_fully_resolved_channel_monitors` is now provided to remove from memory `ChannelMonitor`s that have been fully resolved on-chain and are now not needed. It uses the new `Persist::archive_persisted_channel` to inform the storage layer that such a monitor should be archived (lightningdevkit#2964). * An `OutputSweeper` is now provided which will automatically sweep `SpendableOutputDescriptor`s, retrying until the sweep confirms (lightningdevkit#2825). * After initiating an outbound channel, a peer disconnection no longer results in immediate channel closure. Rather, if the peer is reconnected before the channel times out LDK will automatically retry opening it (lightningdevkit#2725). * `PaymentPurpose` now has separate variants for BOLT12 payments, which include fields from the `invoice_request` as well as the `OfferId` (lightningdevkit#2970). * `ChannelDetails` now includes a list of in-flight HTLCs (lightningdevkit#2442). * `Event::PaymentForwarded` now includes `skimmed_fee_msat` (lightningdevkit#2858). * The `hashbrown` dependency has been upgraded and the use of `ahash` as the no-std hash table hash function has been removed. As a consequence, LDK's `Hash{Map,Set}`s no longer feature several constructors when LDK is built with no-std; see the `util::hash_tables` module instead. On platforms that `getrandom` supports, setting the `possiblyrandom/getrandom` feature flag will ensure hash tables are resistant to HashDoS attacks, though the `possiblyrandom` crate should detect most common platforms (lightningdevkit#2810, lightningdevkit#2891). * `ChannelMonitor`-originated requests to the `ChannelSigner` can now fail and be retried using `ChannelMonitor::signer_unblocked` (lightningdevkit#2816). * `SpendableOutputDescriptor::to_psbt_input` now includes the `witness_script` where available as well as new proprietary data which can be used to re-derive some spending keys from the base key (lightningdevkit#2761, lightningdevkit#3004). * `OutPoint::to_channel_id` has been removed in favor of `ChannelId::v1_from_funding_outpoint` in preparation for v2 channels with a different `ChannelId` derivation scheme (lightningdevkit#2797). * `PeerManager::get_peer_node_ids` has been replaced with `list_peers` and `peer_by_node_id`, which provide more details (lightningdevkit#2905). * `Bolt11Invoice::get_payee_pub_key` is now provided (lightningdevkit#2909). * `Default[Message]Router` now take an `entropy_source` argument (lightningdevkit#2847). * `ClosureReason::HTLCsTimedOut` has been separated out from `ClosureReason::HolderForceClosed` as it is the most common case (lightningdevkit#2887). * `ClosureReason::CooperativeClosure` is now split into `{Counterparty,Locally}Initiated` variants (lightningdevkit#2863). * `Event::ChannelPending::channel_type` is now provided (lightningdevkit#2872). * `PaymentForwarded::{prev,next}_user_channel_id` are now provided (lightningdevkit#2924). * Channel init messages have been refactored towards V2 channels (lightningdevkit#2871). * `BumpTransactionEvent` now contains the channel and counterparty (lightningdevkit#2873). * `util::scid_utils` is now public, with some trivial utilities to examine short channel ids (lightningdevkit#2694). * `DirectedChannelInfo::{source,target}` are now public (lightningdevkit#2870). * Bounds in `lightning-background-processor` were simplified by using `AChannelManager` (lightningdevkit#2963). * The `Persist` impl for `KVStore` no longer requires `Sized`, allowing for the use of `dyn KVStore` as `Persist` (lightningdevkit#2883, lightningdevkit#2976). * `From<PaymentPreimage>` is now implemented for `PaymentHash` (lightningdevkit#2918). * `NodeId::from_slice` is now provided (lightningdevkit#2942). * `ChannelManager` deserialization may now fail with `DangerousValue` when LDK's persistence API was violated (lightningdevkit#2974). Bug Fixes ========= * Excess fees on counterparty commitment transactions are now included in the dust exposure calculation. This lines behavior up with some cases where transaction fees can be burnt, making them effectively dust exposure (lightningdevkit#3045). * `Future`s used as an `std::...::Future` could grow in size unbounded if it was never woken. For those not using async persistence and using the async `lightning-background-processor`, this could cause a memory leak in the `ChainMonitor` (lightningdevkit#2894). * Inbound channel requests that fail in `ChannelManager::accept_inbound_channel` would previously have stalled from the peer's perspective as no `error` message was sent (lightningdevkit#2953). * Blinded path construction has been tuned to select paths more likely to succeed, improving BOLT12 payment reliability (lightningdevkit#2911, lightningdevkit#2912). * After a reorg, `lightning-transaction-sync` could have failed to follow a transaction that LDK needed information about (lightningdevkit#2946). * `RecipientOnionFields`' `custom_tlvs` are now propagated to recipients when paying with blinded paths (lightningdevkit#2975). * `Event::ChannelClosed` is now properly generated and peers are properly notified for all channels that as a part of a batch channel open fail to be funded (lightningdevkit#3029). * In cases where user event processing is substantially delayed such that we complete multiple round-trips with our peers before a `PaymentSent` event is handled and then restart without persisting the `ChannelManager` after having persisted a `ChannelMonitor[Update]`, on startup we may have `Err`d trying to deserialize the `ChannelManager` (lightningdevkit#3021). * If a peer has relatively high latency, `PeerManager` may have failed to establish a connection (lightningdevkit#2993). * `ChannelUpdate` messages broadcasted for our own channel closures are now slightly more robust (lightningdevkit#2731). * Deserializing malformed BOLT11 invoices may have resulted in an integer overflow panic in debug builds (lightningdevkit#3032). * In exceedingly rare cases (no cases of this are known), LDK may have created an invalid serialization for a `ChannelManager` (lightningdevkit#2998). * Message processing latency handling BOLT12 payments has been reduced (lightningdevkit#2881). * Latency in processing `Event::SpendableOutputs` may be reduced (lightningdevkit#3033). Node Compatibility ================== * LDK's blinded paths were inconsistent with other implementations in several ways, which have been addressed (lightningdevkit#2856, lightningdevkit#2936, lightningdevkit#2945). * LDK's messaging blinded paths now support the latest features which some nodes may begin relying on soon (lightningdevkit#2961). * LDK's BOLT12 structs have been updated to support some last-minute changes to the spec (lightningdevkit#3017, lightningdevkit#3018). * CLN v24.02 requires the `gossip_queries` feature for all peers, however LDK by default does not set it for those not using a `P2PGossipSync` (e.g. those using RGS). This change was reverted in CLN v24.02.2 however for now LDK always sets the `gossip_queries` feature. This change is expected to be reverted in a future LDK release (lightningdevkit#2959). Security ======== 0.0.123 fixes a denial-of-service vulnerability which we believe to be reachable from untrusted input when parsing invalid BOLT11 invoices containing non-ASCII characters. * BOLT11 invoices with non-ASCII characters in the human-readable-part may cause an out-of-bounds read attempt leading to a panic (lightningdevkit#3054). Note that all BOLT11 invoices containing non-ASCII characters are invalid. In total, this release features 150 files changed, 19307 insertions, 6306 deletions in 360 commits since 0.0.121 from 17 authors, in alphabetical order: * Arik Sosman * Duncan Dean * Elias Rohrer * Evan Feenstra * Jeffrey Czyz * Keyue Bao * Matt Corallo * Orbital * Sergi Delgado Segura * Valentine Wallace * Willem Van Lint * Wilmer Paulino * benthecarman * jbesraa * olegkubrakov * optout * shaavan
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is useful for users that track channels by
user_channel_id.For example, in
lightning-liquiditywe currently keep a fullHashMap<ChanelId, u128>around just to be able to associatePaymentForwardedevents with the channels otherwise tracked byuser_channel_id.(cc @wvanlint, @johncantrell97)