@@ -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)]
@@ -7639,10 +7640,30 @@ where
7639
7640
pending_claim: PendingMPPClaimPointer(Arc::clone(pending_claim)),
7640
7641
}
7641
7642
});
7643
+
7644
+ // Create new attribution data as the final hop. Always report a zero hold time, because reporting a
7645
+ // non-zero value will not make a difference in the penalty that may be applied by the sender. If there
7646
+ // is a phantom hop, we need to double-process.
7647
+ let attribution_data =
7648
+ if let Some(phantom_secret) = htlc.prev_hop.phantom_shared_secret {
7649
+ let attribution_data =
7650
+ process_fulfill_attribution_data(None, &phantom_secret, 0);
7651
+ Some(attribution_data)
7652
+ } else {
7653
+ None
7654
+ };
7655
+
7656
+ let attribution_data = process_fulfill_attribution_data(
7657
+ attribution_data.as_ref(),
7658
+ &htlc.prev_hop.incoming_packet_shared_secret,
7659
+ 0,
7660
+ );
7661
+
7642
7662
self.claim_funds_from_hop(
7643
7663
htlc.prev_hop,
7644
7664
payment_preimage,
7645
7665
payment_info.clone(),
7666
+ Some(attribution_data),
7646
7667
|_, definitely_duplicate| {
7647
7668
debug_assert!(
7648
7669
!definitely_duplicate,
@@ -7687,7 +7708,8 @@ where
7687
7708
) -> (Option<MonitorUpdateCompletionAction>, Option<RAAMonitorUpdateBlockingAction>),
7688
7709
>(
7689
7710
&self, prev_hop: HTLCPreviousHopData, payment_preimage: PaymentPreimage,
7690
- payment_info: Option<PaymentClaimDetails>, completion_action: ComplFunc,
7711
+ payment_info: Option<PaymentClaimDetails>, attribution_data: Option<AttributionData>,
7712
+ completion_action: ComplFunc,
7691
7713
) {
7692
7714
let counterparty_node_id = prev_hop.counterparty_node_id.or_else(|| {
7693
7715
let short_to_chan_info = self.short_to_chan_info.read().unwrap();
@@ -7700,7 +7722,13 @@ where
7700
7722
channel_id: prev_hop.channel_id,
7701
7723
htlc_id: prev_hop.htlc_id,
7702
7724
};
7703
- self.claim_mpp_part(htlc_source, payment_preimage, payment_info, completion_action)
7725
+ self.claim_mpp_part(
7726
+ htlc_source,
7727
+ payment_preimage,
7728
+ payment_info,
7729
+ attribution_data,
7730
+ completion_action,
7731
+ )
7704
7732
}
7705
7733
7706
7734
fn claim_mpp_part<
@@ -7710,7 +7738,8 @@ where
7710
7738
) -> (Option<MonitorUpdateCompletionAction>, Option<RAAMonitorUpdateBlockingAction>),
7711
7739
>(
7712
7740
&self, prev_hop: HTLCClaimSource, payment_preimage: PaymentPreimage,
7713
- payment_info: Option<PaymentClaimDetails>, completion_action: ComplFunc,
7741
+ payment_info: Option<PaymentClaimDetails>, attribution_data: Option<AttributionData>,
7742
+ completion_action: ComplFunc,
7714
7743
) {
7715
7744
//TODO: Delay the claimed_funds relaying just like we do outbound relay!
7716
7745
@@ -7751,6 +7780,7 @@ where
7751
7780
prev_hop.htlc_id,
7752
7781
payment_preimage,
7753
7782
payment_info,
7783
+ attribution_data,
7754
7784
&&logger,
7755
7785
);
7756
7786
@@ -7959,7 +7989,8 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
7959
7989
forwarded_htlc_value_msat: Option<u64>, skimmed_fee_msat: Option<u64>, from_onchain: bool,
7960
7990
startup_replay: bool, next_channel_counterparty_node_id: PublicKey,
7961
7991
next_channel_outpoint: OutPoint, next_channel_id: ChannelId,
7962
- next_user_channel_id: Option<u128>,
7992
+ next_user_channel_id: Option<u128>, attribution_data: Option<&AttributionData>,
7993
+ send_timestamp: Option<Duration>,
7963
7994
) {
7964
7995
match source {
7965
7996
HTLCSource::OutboundRoute {
@@ -7991,10 +8022,25 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
7991
8022
let prev_node_id = hop_data.counterparty_node_id;
7992
8023
let completed_blocker =
7993
8024
RAAMonitorUpdateBlockingAction::from_prev_hop_data(&hop_data);
8025
+
8026
+ // Obtain hold time, if available.
8027
+ let now = duration_since_epoch();
8028
+ let hold_time = hold_time(send_timestamp, now).unwrap_or(0);
8029
+
8030
+ // If attribution data was received from downstream, we shift it and get it ready for adding our hold
8031
+ // time. Note that fulfilled HTLCs take a fast path to the incoming side. We don't need to wait for RAA
8032
+ // to record the hold time like we do for failed HTLCs.
8033
+ let attribution_data = process_fulfill_attribution_data(
8034
+ attribution_data,
8035
+ &hop_data.incoming_packet_shared_secret,
8036
+ hold_time,
8037
+ );
8038
+
7994
8039
self.claim_funds_from_hop(
7995
8040
hop_data,
7996
8041
payment_preimage,
7997
8042
None,
8043
+ Some(attribution_data),
7998
8044
|htlc_claim_value_msat, definitely_duplicate| {
7999
8045
let chan_to_release = Some(EventUnblockedChannel {
8000
8046
counterparty_node_id: next_channel_counterparty_node_id,
@@ -9553,7 +9599,7 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
9553
9599
) -> Result<(), MsgHandleErrInternal> {
9554
9600
let funding_txo;
9555
9601
let next_user_channel_id;
9556
- let (htlc_source, forwarded_htlc_value, skimmed_fee_msat) = {
9602
+ let (htlc_source, forwarded_htlc_value, skimmed_fee_msat, send_timestamp ) = {
9557
9603
let per_peer_state = self.per_peer_state.read().unwrap();
9558
9604
let peer_state_mutex = per_peer_state.get(counterparty_node_id).ok_or_else(|| {
9559
9605
debug_assert!(false);
@@ -9608,6 +9654,8 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
9608
9654
funding_txo,
9609
9655
msg.channel_id,
9610
9656
Some(next_user_channel_id),
9657
+ msg.attribution_data.as_ref(),
9658
+ send_timestamp,
9611
9659
);
9612
9660
9613
9661
Ok(())
@@ -10429,6 +10477,8 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
10429
10477
"Claiming HTLC with preimage {} from our monitor",
10430
10478
preimage
10431
10479
);
10480
+ // Claim the funds from the previous hop, if there is one. Because this is in response to a
10481
+ // chain event, no attribution data is available.
10432
10482
self.claim_funds_internal(
10433
10483
htlc_update.source,
10434
10484
preimage,
@@ -10440,6 +10490,8 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
10440
10490
funding_outpoint,
10441
10491
channel_id,
10442
10492
None,
10493
+ None,
10494
+ None,
10443
10495
);
10444
10496
} else {
10445
10497
log_trace!(
@@ -16293,10 +16345,14 @@ where
16293
16345
// Note that we don't need to pass the `payment_info` here - its
16294
16346
// already (clearly) durably on disk in the `ChannelMonitor` so there's
16295
16347
// no need to worry about getting it into others.
16348
+ //
16349
+ // We don't encode any attribution data, because the required onion shared secret isn't
16350
+ // available here.
16296
16351
channel_manager.claim_mpp_part(
16297
16352
part.into(),
16298
16353
payment_preimage,
16299
16354
None,
16355
+ None,
16300
16356
|_, _| {
16301
16357
(
16302
16358
Some(MonitorUpdateCompletionAction::PaymentClaimed {
@@ -16441,6 +16497,7 @@ where
16441
16497
// We use `downstream_closed` in place of `from_onchain` here just as a guess - we
16442
16498
// don't remember in the `ChannelMonitor` where we got a preimage from, but if the
16443
16499
// channel is closed we just assume that it probably came from an on-chain claim.
16500
+ // The same holds for attribution data. We don't have any, so we pass an empty one.
16444
16501
channel_manager.claim_funds_internal(
16445
16502
source,
16446
16503
preimage,
@@ -16452,6 +16509,8 @@ where
16452
16509
downstream_funding,
16453
16510
downstream_channel_id,
16454
16511
None,
16512
+ None,
16513
+ None,
16455
16514
);
16456
16515
}
16457
16516
0 commit comments