Skip to content

Commit 73bb6e9

Browse files
committed
Clarify the in-flight HTLC state-tracking structs a bit.
This also renames PendingForwardHTLCInfo to PendingHTLCInfo since it now also encompasses Pending *Received* HTLCs.
1 parent c0e5617 commit 73bb6e9

File tree

2 files changed

+39
-35
lines changed

2 files changed

+39
-35
lines changed

lightning/src/ln/channel.rs

Lines changed: 5 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -19,7 +19,7 @@ use ln::features::{ChannelFeatures, InitFeatures};
1919
use ln::msgs;
2020
use ln::msgs::{DecodeError, OptionalField, DataLossProtect};
2121
use ln::channelmonitor::ChannelMonitor;
22-
use ln::channelmanager::{PendingHTLCStatus, HTLCSource, HTLCFailReason, HTLCFailureMsg, PendingForwardHTLCInfo, RAACommitmentOrder, PaymentPreimage, PaymentHash, BREAKDOWN_TIMEOUT, MAX_LOCAL_BREAKDOWN_TIMEOUT};
22+
use ln::channelmanager::{PendingHTLCStatus, HTLCSource, HTLCFailReason, HTLCFailureMsg, PendingHTLCInfo, RAACommitmentOrder, PaymentPreimage, PaymentHash, BREAKDOWN_TIMEOUT, MAX_LOCAL_BREAKDOWN_TIMEOUT};
2323
use ln::chan_utils::{LocalCommitmentTransaction, TxCreationKeys, HTLCOutputInCommitment, HTLC_SUCCESS_TX_WEIGHT, HTLC_TIMEOUT_TX_WEIGHT, make_funding_redeemscript, ChannelPublicKeys};
2424
use ln::chan_utils;
2525
use chain::chaininterface::{FeeEstimator,ConfirmationTarget};
@@ -269,7 +269,7 @@ pub(super) struct Channel<ChanSigner: ChannelKeys> {
269269
monitor_pending_funding_locked: bool,
270270
monitor_pending_revoke_and_ack: bool,
271271
monitor_pending_commitment_signed: bool,
272-
monitor_pending_forwards: Vec<(PendingForwardHTLCInfo, u64)>,
272+
monitor_pending_forwards: Vec<(PendingHTLCInfo, u64)>,
273273
monitor_pending_failures: Vec<(HTLCSource, PaymentHash, HTLCFailReason)>,
274274

275275
// pending_update_fee is filled when sending and receiving update_fee
@@ -1979,7 +1979,7 @@ impl<ChanSigner: ChannelKeys> Channel<ChanSigner> {
19791979
/// waiting on this revoke_and_ack. The generation of this new commitment_signed may also fail,
19801980
/// generating an appropriate error *after* the channel state has been updated based on the
19811981
/// revoke_and_ack message.
1982-
pub fn revoke_and_ack(&mut self, msg: &msgs::RevokeAndACK, fee_estimator: &FeeEstimator) -> Result<(Option<msgs::CommitmentUpdate>, Vec<(PendingForwardHTLCInfo, u64)>, Vec<(HTLCSource, PaymentHash, HTLCFailReason)>, Option<msgs::ClosingSigned>, ChannelMonitor<ChanSigner>), ChannelError<ChanSigner>> {
1982+
pub fn revoke_and_ack(&mut self, msg: &msgs::RevokeAndACK, fee_estimator: &FeeEstimator) -> Result<(Option<msgs::CommitmentUpdate>, Vec<(PendingHTLCInfo, u64)>, Vec<(HTLCSource, PaymentHash, HTLCFailReason)>, Option<msgs::ClosingSigned>, ChannelMonitor<ChanSigner>), ChannelError<ChanSigner>> {
19831983
if (self.channel_state & (ChannelState::ChannelFunded as u32)) != (ChannelState::ChannelFunded as u32) {
19841984
return Err(ChannelError::Close("Got revoke/ACK message when channel was not in an operational state"));
19851985
}
@@ -2285,7 +2285,7 @@ impl<ChanSigner: ChannelKeys> Channel<ChanSigner> {
22852285
/// which failed. The messages which were generated from that call which generated the
22862286
/// monitor update failure must *not* have been sent to the remote end, and must instead
22872287
/// have been dropped. They will be regenerated when monitor_updating_restored is called.
2288-
pub fn monitor_update_failed(&mut self, resend_raa: bool, resend_commitment: bool, mut pending_forwards: Vec<(PendingForwardHTLCInfo, u64)>, mut pending_fails: Vec<(HTLCSource, PaymentHash, HTLCFailReason)>) {
2288+
pub fn monitor_update_failed(&mut self, resend_raa: bool, resend_commitment: bool, mut pending_forwards: Vec<(PendingHTLCInfo, u64)>, mut pending_fails: Vec<(HTLCSource, PaymentHash, HTLCFailReason)>) {
22892289
assert_eq!(self.channel_state & ChannelState::MonitorUpdateFailed as u32, 0);
22902290
self.monitor_pending_revoke_and_ack = resend_raa;
22912291
self.monitor_pending_commitment_signed = resend_commitment;
@@ -2299,7 +2299,7 @@ impl<ChanSigner: ChannelKeys> Channel<ChanSigner> {
22992299
/// Indicates that the latest ChannelMonitor update has been committed by the client
23002300
/// successfully and we should restore normal operation. Returns messages which should be sent
23012301
/// to the remote side.
2302-
pub fn monitor_updating_restored(&mut self) -> (Option<msgs::RevokeAndACK>, Option<msgs::CommitmentUpdate>, RAACommitmentOrder, Vec<(PendingForwardHTLCInfo, u64)>, Vec<(HTLCSource, PaymentHash, HTLCFailReason)>, bool, Option<msgs::FundingLocked>) {
2302+
pub fn monitor_updating_restored(&mut self) -> (Option<msgs::RevokeAndACK>, Option<msgs::CommitmentUpdate>, RAACommitmentOrder, Vec<(PendingHTLCInfo, u64)>, Vec<(HTLCSource, PaymentHash, HTLCFailReason)>, bool, Option<msgs::FundingLocked>) {
23032303
assert_eq!(self.channel_state & ChannelState::MonitorUpdateFailed as u32, ChannelState::MonitorUpdateFailed as u32);
23042304
self.channel_state &= !(ChannelState::MonitorUpdateFailed as u32);
23052305

lightning/src/ln/channelmanager.rs

Lines changed: 34 additions & 30 deletions
Original file line numberDiff line numberDiff line change
@@ -57,15 +57,19 @@ use std::ops::Deref;
5757
// forward the HTLC with information it will give back to us when it does so, or if it should Fail
5858
// the HTLC with the relevant message for the Channel to handle giving to the remote peer.
5959
//
60-
// When a Channel forwards an HTLC to its peer, it will give us back the PendingForwardHTLCInfo
61-
// which we will use to construct an outbound HTLC, with a relevant HTLCSource::PreviousHopData
62-
// filled in to indicate where it came from (which we can use to either fail-backwards or fulfill
63-
// the HTLC backwards along the relevant path).
60+
// Once said HTLC is committed in the Channel, if the PendingHTLCStatus indicated Forward, the
61+
// Channel will return the PendingHTLCInfo back to us, and we will create an HTLCForwardInfo
62+
// with it to track where it came from (in case of onwards-forward error), waiting a random delay
63+
// before we forward it.
64+
//
65+
// We will then use HTLCForwardInfo's PendingHTLCInfo to construct an outbound HTLC, with a
66+
// relevant HTLCSource::PreviousHopData filled in to indicate where it came from (which we can use
67+
// to either fail-backwards or fulfill the HTLC backwards along the relevant path).
6468
// Alternatively, we can fill an outbound HTLC with a HTLCSource::OutboundRoute indicating this is
6569
// our payment, which we can use to decode errors or inform the user that the payment was sent.
66-
/// Stores the info we will need to send when we want to forward an HTLC onwards
70+
6771
#[derive(Clone)] // See Channel::revoke_and_ack for why, tl;dr: Rust bug
68-
pub(super) struct PendingForwardHTLCInfo {
72+
pub(super) struct PendingHTLCInfo {
6973
onion_packet: Option<msgs::OnionPacket>,
7074
incoming_shared_secret: [u8; 32],
7175
payment_hash: PaymentHash,
@@ -83,10 +87,22 @@ pub(super) enum HTLCFailureMsg {
8387
/// Stores whether we can't forward an HTLC or relevant forwarding info
8488
#[derive(Clone)] // See Channel::revoke_and_ack for why, tl;dr: Rust bug
8589
pub(super) enum PendingHTLCStatus {
86-
Forward(PendingForwardHTLCInfo),
90+
Forward(PendingHTLCInfo),
8791
Fail(HTLCFailureMsg),
8892
}
8993

94+
pub(super) enum HTLCForwardInfo {
95+
AddHTLC {
96+
prev_short_channel_id: u64,
97+
prev_htlc_id: u64,
98+
forward_info: PendingHTLCInfo,
99+
},
100+
FailHTLC {
101+
htlc_id: u64,
102+
err_packet: msgs::OnionErrorPacket,
103+
},
104+
}
105+
90106
/// Tracks the inbound corresponding to an outbound HTLC
91107
#[derive(Clone, PartialEq)]
92108
pub(super) struct HTLCPreviousHopData {
@@ -231,18 +247,6 @@ impl MsgHandleErrInternal {
231247
/// second to 30 seconds, but people expect lightning to be, you know, kinda fast, sadly.
232248
const MIN_HTLC_RELAY_HOLDING_CELL_MILLIS: u64 = 100;
233249

234-
pub(super) enum HTLCForwardInfo {
235-
AddHTLC {
236-
prev_short_channel_id: u64,
237-
prev_htlc_id: u64,
238-
forward_info: PendingForwardHTLCInfo,
239-
},
240-
FailHTLC {
241-
htlc_id: u64,
242-
err_packet: msgs::OnionErrorPacket,
243-
},
244-
}
245-
246250
/// For events which result in both a RevokeAndACK and a CommitmentUpdate, by default they should
247251
/// be sent in the order they appear in the return value, however sometimes the order needs to be
248252
/// variable at runtime (eg Channel::channel_reestablish needs to re-send messages in the order
@@ -262,7 +266,7 @@ pub(super) struct ChannelHolder<ChanSigner: ChannelKeys> {
262266
/// short channel id -> forward infos. Key of 0 means payments received
263267
/// Note that while this is held in the same mutex as the channels themselves, no consistency
264268
/// guarantees are made about the existence of a channel with the short id here, nor the short
265-
/// ids in the PendingForwardHTLCInfo!
269+
/// ids in the PendingHTLCInfo!
266270
pub(super) forward_htlcs: HashMap<u64, Vec<HTLCForwardInfo>>,
267271
/// payment_hash -> Vec<(amount_received, htlc_source)> for tracking things that were to us and
268272
/// can be failed/claimed by the user
@@ -575,7 +579,7 @@ macro_rules! handle_monitor_err {
575579
} else if $resend_commitment { "commitment" }
576580
else if $resend_raa { "RAA" }
577581
else { "nothing" },
578-
(&$failed_forwards as &Vec<(PendingForwardHTLCInfo, u64)>).len(),
582+
(&$failed_forwards as &Vec<(PendingHTLCInfo, u64)>).len(),
579583
(&$failed_fails as &Vec<(HTLCSource, PaymentHash, HTLCFailReason)>).len());
580584
if !$resend_commitment {
581585
debug_assert!($action_type == RAACommitmentOrder::RevokeAndACKFirst || !$resend_raa);
@@ -969,7 +973,7 @@ impl<ChanSigner: ChannelKeys, M: Deref> ChannelManager<ChanSigner, M> where M::T
969973
// instead we stay symmetric with the forwarding case, only responding (after a
970974
// delay) once they've send us a commitment_signed!
971975

972-
PendingHTLCStatus::Forward(PendingForwardHTLCInfo {
976+
PendingHTLCStatus::Forward(PendingHTLCInfo {
973977
onion_packet: None,
974978
payment_hash: msg.payment_hash.clone(),
975979
short_channel_id: 0,
@@ -1021,7 +1025,7 @@ impl<ChanSigner: ChannelKeys, M: Deref> ChannelManager<ChanSigner, M> where M::T
10211025
},
10221026
};
10231027

1024-
PendingHTLCStatus::Forward(PendingForwardHTLCInfo {
1028+
PendingHTLCStatus::Forward(PendingHTLCInfo {
10251029
onion_packet: Some(outgoing_packet),
10261030
payment_hash: msg.payment_hash.clone(),
10271031
short_channel_id: short_channel_id,
@@ -1032,7 +1036,7 @@ impl<ChanSigner: ChannelKeys, M: Deref> ChannelManager<ChanSigner, M> where M::T
10321036
};
10331037

10341038
channel_state = Some(self.channel_state.lock().unwrap());
1035-
if let &PendingHTLCStatus::Forward(PendingForwardHTLCInfo { ref onion_packet, ref short_channel_id, ref amt_to_forward, ref outgoing_cltv_value, .. }) = &pending_forward_info {
1039+
if let &PendingHTLCStatus::Forward(PendingHTLCInfo { ref onion_packet, ref short_channel_id, ref amt_to_forward, ref outgoing_cltv_value, .. }) = &pending_forward_info {
10361040
if onion_packet.is_some() { // If short_channel_id is 0 here, we'll reject them in the body here
10371041
let id_option = channel_state.as_ref().unwrap().short_to_id.get(&short_channel_id).cloned();
10381042
let forwarding_id = match id_option {
@@ -2191,7 +2195,7 @@ impl<ChanSigner: ChannelKeys, M: Deref> ChannelManager<ChanSigner, M> where M::T
21912195
// If the update_add is completely bogus, the call will Err and we will close,
21922196
// but if we've sent a shutdown and they haven't acknowledged it yet, we just
21932197
// want to reject the new HTLC and fail it backwards instead of forwarding.
2194-
if let PendingHTLCStatus::Forward(PendingForwardHTLCInfo { incoming_shared_secret, .. }) = pending_forward_info {
2198+
if let PendingHTLCStatus::Forward(PendingHTLCInfo { incoming_shared_secret, .. }) = pending_forward_info {
21952199
let chan_update = self.get_channel_update(chan.get());
21962200
pending_forward_info = PendingHTLCStatus::Fail(HTLCFailureMsg::Relay(msgs::UpdateFailHTLC {
21972201
channel_id: msg.channel_id,
@@ -2322,7 +2326,7 @@ impl<ChanSigner: ChannelKeys, M: Deref> ChannelManager<ChanSigner, M> where M::T
23222326
}
23232327

23242328
#[inline]
2325-
fn forward_htlcs(&self, per_source_pending_forwards: &mut [(u64, Vec<(PendingForwardHTLCInfo, u64)>)]) {
2329+
fn forward_htlcs(&self, per_source_pending_forwards: &mut [(u64, Vec<(PendingHTLCInfo, u64)>)]) {
23262330
for &mut (prev_short_channel_id, ref mut pending_forwards) in per_source_pending_forwards {
23272331
let mut forward_event = None;
23282332
if !pending_forwards.is_empty() {
@@ -3038,7 +3042,7 @@ impl<ChanSigner: ChannelKeys, M: Deref + Sync + Send> ChannelMessageHandler for
30383042
const SERIALIZATION_VERSION: u8 = 1;
30393043
const MIN_SERIALIZATION_VERSION: u8 = 1;
30403044

3041-
impl Writeable for PendingForwardHTLCInfo {
3045+
impl Writeable for PendingHTLCInfo {
30423046
fn write<W: Writer>(&self, writer: &mut W) -> Result<(), ::std::io::Error> {
30433047
self.onion_packet.write(writer)?;
30443048
self.incoming_shared_secret.write(writer)?;
@@ -3050,9 +3054,9 @@ impl Writeable for PendingForwardHTLCInfo {
30503054
}
30513055
}
30523056

3053-
impl<R: ::std::io::Read> Readable<R> for PendingForwardHTLCInfo {
3054-
fn read(reader: &mut R) -> Result<PendingForwardHTLCInfo, DecodeError> {
3055-
Ok(PendingForwardHTLCInfo {
3057+
impl<R: ::std::io::Read> Readable<R> for PendingHTLCInfo {
3058+
fn read(reader: &mut R) -> Result<PendingHTLCInfo, DecodeError> {
3059+
Ok(PendingHTLCInfo {
30563060
onion_packet: Readable::read(reader)?,
30573061
incoming_shared_secret: Readable::read(reader)?,
30583062
payment_hash: Readable::read(reader)?,

0 commit comments

Comments
 (0)