@@ -58,12 +58,12 @@ use crate::events::{
58
58
use crate::events::{FundingInfo, PaidBolt12Invoice};
59
59
// Since this struct is returned in `list_channels` methods, expose it here in case users want to
60
60
// construct one themselves.
61
- use crate::ln::channel::PendingV2Channel;
62
61
use crate::ln::channel::{
63
- self, Channel, ChannelError, ChannelUpdateStatus, FundedChannel, InboundV1Channel,
62
+ self, hold_time, Channel, ChannelError, ChannelUpdateStatus, FundedChannel, InboundV1Channel,
64
63
OutboundV1Channel, ReconnectionMsg, ShutdownResult, UpdateFulfillCommitFetch,
65
64
WithChannelContext,
66
65
};
66
+ use crate::ln::channel::{duration_since_epoch, PendingV2Channel};
67
67
use crate::ln::channel_state::ChannelDetails;
68
68
use crate::ln::inbound_payment;
69
69
use crate::ln::msgs;
@@ -77,6 +77,7 @@ use crate::ln::onion_payment::{
77
77
NextPacketDetails,
78
78
};
79
79
use crate::ln::onion_utils::{self};
80
+ use crate::ln::onion_utils::{process_fulfill_attribution_data, AttributionData};
80
81
use crate::ln::onion_utils::{HTLCFailReason, LocalHTLCFailureReason};
81
82
use crate::ln::our_peer_storage::EncryptedOurPeerStorage;
82
83
#[cfg(test)]
@@ -7938,10 +7939,30 @@ where
7938
7939
pending_claim: PendingMPPClaimPointer(Arc::clone(pending_claim)),
7939
7940
}
7940
7941
});
7942
+
7943
+ // Create new attribution data as the final hop. Always report a zero hold time, because reporting a
7944
+ // non-zero value will not make a difference in the penalty that may be applied by the sender. If there
7945
+ // is a phantom hop, we need to double-process.
7946
+ let attribution_data =
7947
+ if let Some(phantom_secret) = htlc.prev_hop.phantom_shared_secret {
7948
+ let attribution_data =
7949
+ process_fulfill_attribution_data(None, &phantom_secret, 0);
7950
+ Some(attribution_data)
7951
+ } else {
7952
+ None
7953
+ };
7954
+
7955
+ let attribution_data = process_fulfill_attribution_data(
7956
+ attribution_data.as_ref(),
7957
+ &htlc.prev_hop.incoming_packet_shared_secret,
7958
+ 0,
7959
+ );
7960
+
7941
7961
self.claim_funds_from_hop(
7942
7962
htlc.prev_hop,
7943
7963
payment_preimage,
7944
7964
payment_info.clone(),
7965
+ Some(attribution_data),
7945
7966
|_, definitely_duplicate| {
7946
7967
debug_assert!(
7947
7968
!definitely_duplicate,
@@ -7986,7 +8007,8 @@ where
7986
8007
) -> (Option<MonitorUpdateCompletionAction>, Option<RAAMonitorUpdateBlockingAction>),
7987
8008
>(
7988
8009
&self, prev_hop: HTLCPreviousHopData, payment_preimage: PaymentPreimage,
7989
- payment_info: Option<PaymentClaimDetails>, completion_action: ComplFunc,
8010
+ payment_info: Option<PaymentClaimDetails>, attribution_data: Option<AttributionData>,
8011
+ completion_action: ComplFunc,
7990
8012
) {
7991
8013
let counterparty_node_id = prev_hop.counterparty_node_id.or_else(|| {
7992
8014
let short_to_chan_info = self.short_to_chan_info.read().unwrap();
@@ -7999,7 +8021,13 @@ where
7999
8021
channel_id: prev_hop.channel_id,
8000
8022
htlc_id: prev_hop.htlc_id,
8001
8023
};
8002
- self.claim_mpp_part(htlc_source, payment_preimage, payment_info, completion_action)
8024
+ self.claim_mpp_part(
8025
+ htlc_source,
8026
+ payment_preimage,
8027
+ payment_info,
8028
+ attribution_data,
8029
+ completion_action,
8030
+ )
8003
8031
}
8004
8032
8005
8033
fn claim_mpp_part<
@@ -8009,7 +8037,8 @@ where
8009
8037
) -> (Option<MonitorUpdateCompletionAction>, Option<RAAMonitorUpdateBlockingAction>),
8010
8038
>(
8011
8039
&self, prev_hop: HTLCClaimSource, payment_preimage: PaymentPreimage,
8012
- payment_info: Option<PaymentClaimDetails>, completion_action: ComplFunc,
8040
+ payment_info: Option<PaymentClaimDetails>, attribution_data: Option<AttributionData>,
8041
+ completion_action: ComplFunc,
8013
8042
) {
8014
8043
//TODO: Delay the claimed_funds relaying just like we do outbound relay!
8015
8044
@@ -8050,6 +8079,7 @@ where
8050
8079
prev_hop.htlc_id,
8051
8080
payment_preimage,
8052
8081
payment_info,
8082
+ attribution_data,
8053
8083
&&logger,
8054
8084
);
8055
8085
@@ -8258,7 +8288,8 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
8258
8288
forwarded_htlc_value_msat: Option<u64>, skimmed_fee_msat: Option<u64>, from_onchain: bool,
8259
8289
startup_replay: bool, next_channel_counterparty_node_id: PublicKey,
8260
8290
next_channel_outpoint: OutPoint, next_channel_id: ChannelId,
8261
- next_user_channel_id: Option<u128>,
8291
+ next_user_channel_id: Option<u128>, attribution_data: Option<&AttributionData>,
8292
+ send_timestamp: Option<Duration>,
8262
8293
) {
8263
8294
match source {
8264
8295
HTLCSource::OutboundRoute {
@@ -8290,10 +8321,25 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
8290
8321
let prev_node_id = hop_data.counterparty_node_id;
8291
8322
let completed_blocker =
8292
8323
RAAMonitorUpdateBlockingAction::from_prev_hop_data(&hop_data);
8324
+
8325
+ // Obtain hold time, if available.
8326
+ let now = duration_since_epoch();
8327
+ let hold_time = hold_time(send_timestamp, now).unwrap_or(0);
8328
+
8329
+ // If attribution data was received from downstream, we shift it and get it ready for adding our hold
8330
+ // time. Note that fulfilled HTLCs take a fast path to the incoming side. We don't need to wait for RAA
8331
+ // to record the hold time like we do for failed HTLCs.
8332
+ let attribution_data = process_fulfill_attribution_data(
8333
+ attribution_data,
8334
+ &hop_data.incoming_packet_shared_secret,
8335
+ hold_time,
8336
+ );
8337
+
8293
8338
self.claim_funds_from_hop(
8294
8339
hop_data,
8295
8340
payment_preimage,
8296
8341
None,
8342
+ Some(attribution_data),
8297
8343
|htlc_claim_value_msat, definitely_duplicate| {
8298
8344
let chan_to_release = Some(EventUnblockedChannel {
8299
8345
counterparty_node_id: next_channel_counterparty_node_id,
@@ -9852,7 +9898,7 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
9852
9898
) -> Result<(), MsgHandleErrInternal> {
9853
9899
let funding_txo;
9854
9900
let next_user_channel_id;
9855
- let (htlc_source, forwarded_htlc_value, skimmed_fee_msat) = {
9901
+ let (htlc_source, forwarded_htlc_value, skimmed_fee_msat, send_timestamp ) = {
9856
9902
let per_peer_state = self.per_peer_state.read().unwrap();
9857
9903
let peer_state_mutex = per_peer_state.get(counterparty_node_id).ok_or_else(|| {
9858
9904
debug_assert!(false);
@@ -9907,6 +9953,8 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
9907
9953
funding_txo,
9908
9954
msg.channel_id,
9909
9955
Some(next_user_channel_id),
9956
+ msg.attribution_data.as_ref(),
9957
+ send_timestamp,
9910
9958
);
9911
9959
9912
9960
Ok(())
@@ -10800,6 +10848,8 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
10800
10848
"Claiming HTLC with preimage {} from our monitor",
10801
10849
preimage
10802
10850
);
10851
+ // Claim the funds from the previous hop, if there is one. Because this is in response to a
10852
+ // chain event, no attribution data is available.
10803
10853
self.claim_funds_internal(
10804
10854
htlc_update.source,
10805
10855
preimage,
@@ -10811,6 +10861,8 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
10811
10861
funding_outpoint,
10812
10862
channel_id,
10813
10863
None,
10864
+ None,
10865
+ None,
10814
10866
);
10815
10867
} else {
10816
10868
log_trace!(
@@ -16677,10 +16729,14 @@ where
16677
16729
// Note that we don't need to pass the `payment_info` here - its
16678
16730
// already (clearly) durably on disk in the `ChannelMonitor` so there's
16679
16731
// no need to worry about getting it into others.
16732
+ //
16733
+ // We don't encode any attribution data, because the required onion shared secret isn't
16734
+ // available here.
16680
16735
channel_manager.claim_mpp_part(
16681
16736
part.into(),
16682
16737
payment_preimage,
16683
16738
None,
16739
+ None,
16684
16740
|_, _| {
16685
16741
(
16686
16742
Some(MonitorUpdateCompletionAction::PaymentClaimed {
@@ -16825,6 +16881,7 @@ where
16825
16881
// We use `downstream_closed` in place of `from_onchain` here just as a guess - we
16826
16882
// don't remember in the `ChannelMonitor` where we got a preimage from, but if the
16827
16883
// channel is closed we just assume that it probably came from an on-chain claim.
16884
+ // The same holds for attribution data. We don't have any, so we pass an empty one.
16828
16885
channel_manager.claim_funds_internal(
16829
16886
source,
16830
16887
preimage,
@@ -16836,6 +16893,8 @@ where
16836
16893
downstream_funding,
16837
16894
downstream_channel_id,
16838
16895
None,
16896
+ None,
16897
+ None,
16839
16898
);
16840
16899
}
16841
16900
0 commit comments