Skip to content

Reinstate ChannelManager::send_payment_with_route API #3534

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

valentinewallace
Copy link
Contributor

@valentinewallace valentinewallace commented Jan 14, 2025

Closes #3523.

Based on #3531

@valentinewallace valentinewallace added this to the 0.1.1 milestone Jan 14, 2025
#[cfg(test)]
pub(crate) fn send_payment_with_route(
/// Sends a payment along a given route. See [`Self::send_payment`] for more info.
/// [`Route::route_params`] is required to be `Some`.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Then maybe we should take a RouteParameters, Vec<Path> pair?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Check out the new version, we now support None route params as discussed offline.

Copy link
Contributor

@arik-so arik-so left a comment

Choose a reason for hiding this comment

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

Minor comment aside, I think the fixups can be squashed.

@valentinewallace
Copy link
Contributor Author

Squashed and rebased after #3531 landed and added 1 comment:

diff --git a/lightning/src/routing/router.rs b/lightning/src/routing/router.rs
index 60cecfe61..724d85c69 100644
--- a/lightning/src/routing/router.rs
+++ b/lightning/src/routing/router.rs
@@ -227,6 +227,7 @@ impl Router for FixedRouter {
                &self, _recipient: PublicKey, _first_hops: Vec<ChannelDetails>, _tlvs: ReceiveTlvs,
                _amount_msats: Option<u64>, _secp_ctx: &Secp256k1<T>
        ) -> Result<Vec<BlindedPaymentPath>, ()> {
+               // Should be unreachable as this router is only intended to provide a one-time payment route.
                debug_assert!(false);
                Err(())
        }

TheBlueMatt
TheBlueMatt previously approved these changes Jan 24, 2025
let route_params = route.route_params.clone().unwrap_or_else(|| {
// Create a dummy since route params are a required parameter but unused in this case
let payment_params = PaymentParameters::from_node_id(
self.get_our_node_id(), MIN_FINAL_CLTV_EXPIRY_DELTA as u32
Copy link
Collaborator

Choose a reason for hiding this comment

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

nit: I know it doesn't actually matter today, but I'd feel happier if we picked these values based on the route.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated to pull these fields from the Route, didn't complicate the code too much by checking for blinded tails or erroring on bad routes or anything though.

Support more ergonomically sending payments to specific routes.

We removed the original version of this API because it was hard to work with,
but the concept of sending a payment to a specific route is still useful.
Previously, users were able to do this via manually matching the payment id in
their router, but that's cumbersome when we could just handle it internally.
@valentinewallace
Copy link
Contributor Author

Rebased on main due to conflicts

@TheBlueMatt TheBlueMatt merged commit 0454d45 into lightningdevkit:main Jan 27, 2025
24 of 25 checks passed
@TheBlueMatt TheBlueMatt mentioned this pull request Jan 28, 2025
@TheBlueMatt
Copy link
Collaborator

Backported in #3567

TheBlueMatt added a commit to TheBlueMatt/rust-lightning that referenced this pull request Jan 29, 2025
v0.1.1 - Jan 28, 2025 - "Onchain Matters"

API Updates
===========

 * A `ChannelManager::send_payment_with_route` was (re-)added, with semantics
   similar to `ChannelManager::send_payment` (rather than like the pre-0.1
   `send_payent_with_route`, lightningdevkit#3534).
 * `RawBolt11Invoice::{to,from}_raw` were added (lightningdevkit#3549).

Bug Fixes
=========

 * HTLCs which were forwarded where the inbound edge times out within the next
   three blocks will have the inbound HTLC failed backwards irrespective of the
   status of the outbound HTLC. This avoids the peer force-closing the channel
   (and claiming the inbound edge HTLC on-chain) even if we have not yet managed
   to claim the outbound edge on chain (lightningdevkit#3556).
 * On restart, replay of `Event::SpendableOutput`s could have caused
   `OutputSweeper` to generate double-spending transactions, making it unable to
   claim any delayed claims. This was resolved by retaining old claims for more
   than four weeks after they are claimed on-chain to detect replays (lightningdevkit#3559).
 * Fixed the additional feerate we will pay each time we RBF on-chain claims to
   match the Bitcoin Core policy (1 sat/vB) instead of 16 sats/vB (lightningdevkit#3457).
 * Fixed a cased where a custom `Router` which returns an invalid `Route`,
   provided to `ChannelManager`, can result in an outbound payment remaining
   pending forever despite no HTLCs being pending (lightningdevkit#3531).

Security
========

0.1.1 fixes a denial-of-service vulnerability allowing channel counterparties to
cause force-closure of unrelated channels.
 * If a malicious channel counterparty force-closes a channel, broadcasting a
   revoked commitment transaction while the channel at closure time included
   multiple non-dust forwarded outbound HTLCs with identical payment hashes and
   amounts, failure to fail the HTLCs backwards could cause the channels on
   which we recieved the corresponding inbound HTLCs to be force-closed. Note
   that we'll receive, at a minimum, the malicious counterparty's reserve value
   when they broadcast the stale commitment (lightningdevkit#3556). Thanks to Matt Morehouse for
   reporting this issue.
Sign up for free to 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.

Re-introduce send_payment_with_route with the new API
3 participants