Async send always-online counterparty side #4045
Conversation
This method was rustfmt'd in the previous commit, here we clean up that formatting.
This method will be edited in upcoming commits, and the codebase policy is to at least consider removing rustfmt::skips when touching a method.
This method will be edited in upcoming commits, and the codebase policy is to at least consider removing rustfmt::skips when touching a method.
In upcoming commits, we will be adding several more conversions from PendingAddHTLCInfo into HTLCPreviousHopData. This conversion gets repeated all over the ChannelManager already, so lay some groundwork by DRYing it up.
Without this DRYing, we would be repeating the same code to instantiate the PendingAddHTLCInfo several more times in this method, in upcoming commits.
In upcoming commits, we'll be creating blinded paths during the process of creating a revoke_and_ack message within the Channel struct. These paths will be included in said RAA to be used as reply paths for often-offline senders held_htlc_available messages. Because we hold the per-peer lock corresponding to the Channel while creating this RAA, we can't use our typical approach of calling ChannelManager::get_peers_for_blinded_path to create these blinded paths. The ::get_peers method takes each peer's lock in turn in order to check for usable channels/onion message feature support, and it's not permitted to hold multiple peer state locks at the same time due to the potential for deadlocks (see the debug_sync module). To avoid taking other peer state locks while holding a particular Channel's peer state lock, here we cache the set of peers in the OffersMessageFlow, which is the struct that ultimately creates the blinded paths for the RAA.
As part of supporting sending payments as an often-offline sender, the often-offline sender's channel counterparty needs to advertise a feature bit indicating that they support holding onto the sender's HTLC until they receive a release_held_htlc onion message from the recipient indicating that they are online and ready to receive the payment. See-also <lightning/bolts#989> We don't yet advertise support of this feature.
As part of supporting sending payments as an often-offline sender, the sender needs to be able to set a flag in their update_add_htlc message indicating that the HTLC should be held until receipt of a release_held_htlc onion message from the often-offline payment recipient. We don't yet ever set this flag, but lay the groundwork by including the field in the update_add struct. See-also <lightning/bolts#989>
As part of supporting sending payments as an often-offline sender, the sender needs to send held_htlc_available onion messages where the reply path terminates at their always-online channel counterparty that is holding the HTLC until the recipient comes online. That way when the recipient sends release_held_htlc, the sender's counterparty will receive that message. To accomplish this, the sender's always-online counterparty includes said reply path in the revoke_and_ack message corresponding to the held HTLC. Here we add support for this field, though we don't set it yet. We also had to tweak the ser macros for this because impl_writeable_msg had never had to write a Vec in a message TLV field before.
As part of supporting sending payments as an often-offline sender, the sender's always-online channel counterparty needs to hold onto the sender's HTLC until they receive a release_held_htlc onion message from the often-offline recipient. Here we implement storing these held HTLCs in the existing ChannelManager::pending_intercepted_htlcs map. We want to move in the direction of obviating the need to persistence the ChannelManager entirely, so it doesn't really make sense to add a whole new map for these HTLCs.
As part of supporting sending payments as an often-offline sender, the sender needs to send held_htlc_available onion messages such that the reply path to the message terminates at their always-online channel counterparty that is holding the HTLC. That way when the recipient responds with release_held_htlc, the sender's counterparty will receive that message. Here we add a method for creating said reply path, which will be used in the next commit.
As part of supporting sending payments as an often-offline sender, the sender needs to send held_htlc_available onion messages such that the reply path to the message terminates at their always-online channel counterparty that is holding the HTLC. That way when the recipient responds with release_held_htlc, the sender's counterparty will receive that message. Here the counterparty starts including said reply paths in the revoke_and_ack message destined for the sender, so the sender can use these paths in subsequent held_htlc_available messages. We put the paths in the RAA to ensure the sender receives the blinded paths, because failure to deliver the paths means the HTLC will timeout/fail.
As part of supporting sending payments as an often-offline sender, the sender's always-online channel counterparty needs to hold onto the sender's HTLC until they receive a release_held_htlc onion message from the often-offline recipient. Here we implement forwarding these held HTLCs upon receipt of the release message from the recipient.
|
👋 Thanks for assigning @joostjager as a reviewer! |
| if let Some(per_commitment_secret) = per_commitment_secret { | ||
| if self.holder_commitment_point.can_advance() { | ||
| let mut release_htlc_message_paths = Vec::new(); | ||
| for htlc in &self.context.pending_inbound_htlcs { | ||
| // TODO: how to handle the errors here |
There was a problem hiding this comment.
For reviewers:
Would be good to discuss how to handle failure to create the path_for_release_held_htlc here.
This may be fine for v1 since the failures should basically never happen, but in theory we could end up in a situation where the HTLC gets close to expiring and the sender isn't online for the HTLC to be failed back to them, which would result in FC.
It's a little tricky because it seems nontrivial to add support for returning HTLCs-to-fail from this method.
One option would be to make path_for_release_held_htlc infallible by having it fall back to creating a 1-hop blinded path.
Another more robust but more complex-seeming option would be to attempt to create the blinded path when the corresponding update_add is received, and storing the resulting path in the pending HTLC for use when it comes time to generate the RAA. That would allow us to cache the HTLC's pending failure in the InboundHTLCResolution if we fail to create a blinded path for the RAA, though it would reintroduce a potential timing attack that we had eliminated during the refactor that added ChannelManager::decode_update_add_htlcs.
There was a problem hiding this comment.
end up in a situation where the HTLC gets close to expiring and the sender isn't online for the HTLC to be failed back to them, which would result in FC.
It shouldn't the LSP (and LDK generally) won't FC a channel because of an inbound HTLC which we don't have the preimage or (ie its our counterparty's money). The client probably will FC here, but that's a long-standing issue (#4048).
One option would be to make path_for_release_held_htlc infallible by having it fall back to creating a 1-hop blinded path.
Seems fine to me.
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
valentinewallace
requested review from
joostjager
and removed request for
tankyleo
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #4045 +/- ##
==========================================
- Coverage 88.73% 88.69% -0.04%
==========================================
Files 176 176
Lines 129042 129266 +224
Branches 129042 129266 +224
==========================================
+ Hits 114501 114649 +148
- Misses 11939 12016 +77
+ Partials 2602 2601 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Implements the always-online counterparty side of sending payments as an often-offline sender to an often-offline recipient.
Partially addresses #2298
Based on #4044