Skip to content

Commit 7b77a01

Browse files
committed
Handle closed-chan HTLC claims in claim_funds_from_hop
Currently `claim_funds` does all HTLC claims in one `channel_state` lock, ensuring that we always make claims from channels which are open. It can thus avoid ever having to generate a `ChannelMonitorUpdate` containing a preimage for a closed channel, which we only do in `claim_funds_internal` (for forwarded payments). In the next commit we'll change the locking of `claim_funds_from_hop` so that `claim_funds` is no longer under a single lock but takes a lock for each claim. This allows us to be more flexible with locks going forward, and ultimately isn't a huge change - if our counterparty intends to force-close a channel, us choosing to ignore it by holding the `channel_state` lock for the duration of the claim isn't going to result in a commitment update, it will just result in the preimage already being in the `ChannelMonitor`.
1 parent bffbd37 commit 7b77a01

File tree

1 file changed

+20
-19
lines changed

1 file changed

+20
-19
lines changed

lightning/src/ln/channelmanager.rs

Lines changed: 20 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -4454,7 +4454,26 @@ impl<M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> ChannelManager<M, T, K, F
44544454
return ClaimFundsFromHop::MonitorUpdateFail(counterparty_node_id, res, None);
44554455
},
44564456
}
4457-
} else { return ClaimFundsFromHop::PrevHopForceClosed }
4457+
} else {
4458+
let preimage_update = ChannelMonitorUpdate {
4459+
update_id: CLOSED_CHANNEL_UPDATE_ID,
4460+
updates: vec![ChannelMonitorUpdateStep::PaymentPreimage {
4461+
payment_preimage,
4462+
}],
4463+
};
4464+
// We update the ChannelMonitor on the backward link, after
4465+
// receiving an `update_fulfill_htlc` from the forward link.
4466+
let update_res = self.chain_monitor.update_channel(prev_hop.outpoint, preimage_update);
4467+
if update_res != ChannelMonitorUpdateStatus::Completed {
4468+
// TODO: This needs to be handled somehow - if we receive a monitor update
4469+
// with a preimage we *must* somehow manage to propagate it to the upstream
4470+
// channel, or we must have an ability to receive the same event and try
4471+
// again on restart.
4472+
log_error!(self.logger, "Critical error: failed to update channel monitor with preimage {:?}: {:?}",
4473+
payment_preimage, update_res);
4474+
}
4475+
return ClaimFundsFromHop::PrevHopForceClosed
4476+
}
44584477
}
44594478

44604479
fn finalize_claims(&self, mut sources: Vec<HTLCSource>) {
@@ -4535,24 +4554,6 @@ impl<M: Deref, T: Deref, K: Deref, F: Deref, L: Deref> ChannelManager<M, T, K, F
45354554
_ => None,
45364555
};
45374556
if let ClaimFundsFromHop::PrevHopForceClosed = res {
4538-
let preimage_update = ChannelMonitorUpdate {
4539-
update_id: CLOSED_CHANNEL_UPDATE_ID,
4540-
updates: vec![ChannelMonitorUpdateStep::PaymentPreimage {
4541-
payment_preimage: payment_preimage.clone(),
4542-
}],
4543-
};
4544-
// We update the ChannelMonitor on the backward link, after
4545-
// receiving an offchain preimage event from the forward link (the
4546-
// event being update_fulfill_htlc).
4547-
let update_res = self.chain_monitor.update_channel(prev_outpoint, preimage_update);
4548-
if update_res != ChannelMonitorUpdateStatus::Completed {
4549-
// TODO: This needs to be handled somehow - if we receive a monitor update
4550-
// with a preimage we *must* somehow manage to propagate it to the upstream
4551-
// channel, or we must have an ability to receive the same event and try
4552-
// again on restart.
4553-
log_error!(self.logger, "Critical error: failed to update channel monitor with preimage {:?}: {:?}",
4554-
payment_preimage, update_res);
4555-
}
45564557
// Note that we do *not* set `claimed_htlc` to false here. In fact, this
45574558
// totally could be a duplicate claim, but we have no way of knowing
45584559
// without interrogating the `ChannelMonitor` we've provided the above

0 commit comments

Comments
 (0)