-
Notifications
You must be signed in to change notification settings - Fork 418
Intercept HTLC forwards for JIT channels #1835
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
Changes from 1 commit
129e1f6
3a1268e
5efc197
8fe7cbe
c1f1b78
f79ad2e
ddcd9b0
7809c55
acff8f6
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
Co-authored-by: John Cantrell <johncantrell97@gmail.com> Co-authored-by: Valentine Wallace <vwallace@protonmail.com>
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3059,7 +3059,8 @@ impl<M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> ChannelManager<M, T, K, F | |
/// | ||
/// To make use of intercepted HTLCs, use [`ChannelManager::get_intercept_scid`] to generate short | ||
/// channel id(s) to put in the receiver's invoice route hints. These route hints will signal to | ||
/// LDK to generate an [`HTLCIntercepted`] event when it receives the forwarded HTLC. | ||
/// LDK to generate an [`HTLCIntercepted`] event when it receives the forwarded HTLC, and this | ||
/// method or [`ChannelManager::fail_intercepted_htlc`] MUST be called in response to the event. | ||
/// | ||
/// Note that LDK does not enforce fee requirements in `amt_to_forward_msat`, and will not stop | ||
/// you from forwarding more than you received. | ||
|
@@ -3102,6 +3103,35 @@ impl<M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> ChannelManager<M, T, K, F | |
Ok(()) | ||
} | ||
|
||
/// Fails the intercepted HTLC indicated by intercept_id. Should only be called in response to | ||
/// an [`HTLCIntercepted`] event. See [`ChannelManager::forward_intercepted_htlc`]. | ||
/// | ||
/// [`HTLCIntercepted`]: events::Event::HTLCIntercepted | ||
pub fn fail_intercepted_htlc(&self, intercept_id: InterceptId) -> Result<(), APIError> { | ||
let _persistence_guard = PersistenceNotifierGuard::notify_on_drop(&self.total_consistency_lock, &self.persistence_notifier); | ||
|
||
let payment = self.pending_intercepted_htlcs.lock().unwrap().remove(&intercept_id) | ||
.ok_or_else(|| APIError::APIMisuseError { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Mutating this line does not break |
||
err: format!("Payment with InterceptId {:?} not found", intercept_id) | ||
})?; | ||
|
||
if let PendingHTLCRouting::Forward { short_channel_id, .. } = payment.forward_info.routing { | ||
let htlc_source = HTLCSource::PreviousHopData(HTLCPreviousHopData { | ||
short_channel_id: payment.prev_short_channel_id, | ||
outpoint: payment.prev_funding_outpoint, | ||
htlc_id: payment.prev_htlc_id, | ||
incoming_packet_shared_secret: payment.forward_info.incoming_shared_secret, | ||
phantom_shared_secret: None, | ||
}); | ||
|
||
let failure_reason = HTLCFailReason::Reason { failure_code: 0x4000 | 10, data: Vec::new() }; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should this value choice of an onion error message be standardized, otherwise if Eclair use PERM|1 ( Do you think it could be worthy to introduce a new PERM|23 ( There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think there are easier ways to fingerprint implementations as-is, but it would be good for the LSP spec (which this feature is based on) to specify what error should be returned. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If you can add a comment, suggesting the error could be a custom one and as a reminder to update if/when the LSP spec adopts one. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't think it makes sense to do anything else here, and it definitely doesn't make sense to have a custom error. The error we return here absolutely should be the same error as if we didn't have intercepts enabled, which makes unknown_next_peer correct. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. After understanding this PR is only about JIT channel, I think effectively we shouldn't introduce a custom error. We can revisit in the future, when offline receive at the receiver's LSP or things like "delay my HTLC", introduces HTLC delay processing and it makes sense to return new onion errors. |
||
let destination = HTLCDestination::UnknownNextHop { requested_forward_scid: short_channel_id }; | ||
self.fail_htlc_backwards_internal(htlc_source, &payment.forward_info.payment_hash, failure_reason, destination); | ||
} else { unreachable!() } // Only `PendingHTLCRouting::Forward`s are intercepted | ||
|
||
Ok(()) | ||
} | ||
|
||
/// Processes HTLCs which are pending waiting on random forward delay. | ||
/// | ||
/// Should only really ever be called in response to a PendingHTLCsForwardable event. | ||
|
Uh oh!
There was an error while loading. Please reload this page.