Skip to content

Commit 4ece5fd

Browse files
Update monitor with preimage after channel close
If the channel is hitting the chain right as we receive a preimage, previous to this commit the relevant ChannelMonitor would never learn of this preimage.
1 parent 50ad627 commit 4ece5fd

File tree

2 files changed

+42
-6
lines changed

2 files changed

+42
-6
lines changed

lightning/src/chain/channelmonitor.rs

Lines changed: 27 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -64,14 +64,29 @@ pub struct ChannelMonitorUpdate {
6464
pub(crate) updates: Vec<ChannelMonitorUpdateStep>,
6565
/// The sequence number of this update. Updates *must* be replayed in-order according to this
6666
/// sequence number (and updates may panic if they are not). The update_id values are strictly
67-
/// increasing and increase by one for each new update.
67+
/// increasing and increase by one for each new update, with one exception specified below.
6868
///
6969
/// This sequence number is also used to track up to which points updates which returned
7070
/// ChannelMonitorUpdateErr::TemporaryFailure have been applied to all copies of a given
7171
/// ChannelMonitor when ChannelManager::channel_monitor_updated is called.
72+
///
73+
/// The only instance where update_id values are not strictly increasing is the case where we
74+
/// allow post-force-close updates with a special update ID of [`CLOSED_CHANNEL_UPDATE_ID`]. See
75+
/// its docs for more details.
76+
///
77+
/// [`CLOSED_CHANNEL_UPDATE_ID`]: constant.CLOSED_CHANNEL_UPDATE_ID.html
7278
pub update_id: u64,
7379
}
7480

81+
/// If:
82+
/// (1) a channel has been force closed and
83+
/// (2) we receive a preimage from a forward link that allows us to spend an HTLC output on
84+
/// this channel's (the backward link's) broadcasted commitment transaction
85+
/// then we allow the `ChannelManager` to send a `ChannelMonitorUpdate` with this update ID,
86+
/// with the update providing said payment preimage. No other update types are allowed after
87+
/// force-close.
88+
pub const CLOSED_CHANNEL_UPDATE_ID: u64 = std::u64::MAX;
89+
7590
impl Writeable for ChannelMonitorUpdate {
7691
fn write<W: Writer>(&self, w: &mut W) -> Result<(), ::std::io::Error> {
7792
self.update_id.write(w)?;
@@ -1166,7 +1181,17 @@ impl<ChanSigner: ChannelKeys> ChannelMonitor<ChanSigner> {
11661181
where B::Target: BroadcasterInterface,
11671182
L::Target: Logger,
11681183
{
1169-
if self.latest_update_id + 1 != updates.update_id {
1184+
// ChannelMonitor updates may be applied after force close if we receive a
1185+
// preimage for a broadcasted commitment transaction HTLC output that we'd
1186+
// like to claim on-chain. If this is the case, we no longer have guaranteed
1187+
// access to the monitor's update ID, so we use a sentinel value instead.
1188+
if updates.update_id == CLOSED_CHANNEL_UPDATE_ID {
1189+
match updates.updates[0] {
1190+
ChannelMonitorUpdateStep::PaymentPreimage { .. } => {},
1191+
_ => panic!("Attempted to apply post-force-close ChannelMonitorUpdate that wasn't providing a payment preimage"),
1192+
}
1193+
assert_eq!(updates.updates.len(), 1);
1194+
} else if self.latest_update_id + 1 != updates.update_id {
11701195
panic!("Attempted to apply ChannelMonitorUpdates out of order, check the update_id before passing an update to update_monitor!");
11711196
}
11721197
for update in updates.updates.iter() {

lightning/src/ln/channelmanager.rs

Lines changed: 15 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -37,7 +37,7 @@ use bitcoin::secp256k1;
3737
use chain;
3838
use chain::Watch;
3939
use chain::chaininterface::{BroadcasterInterface, FeeEstimator};
40-
use chain::channelmonitor::{ChannelMonitor, ChannelMonitorUpdate, ChannelMonitorUpdateErr, HTLC_FAIL_BACK_BUFFER, CLTV_CLAIM_BUFFER, LATENCY_GRACE_PERIOD_BLOCKS, ANTI_REORG_DELAY, MonitorEvent};
40+
use chain::channelmonitor::{ChannelMonitor, ChannelMonitorUpdate, ChannelMonitorUpdateStep, ChannelMonitorUpdateErr, HTLC_FAIL_BACK_BUFFER, CLTV_CLAIM_BUFFER, LATENCY_GRACE_PERIOD_BLOCKS, ANTI_REORG_DELAY, MonitorEvent, CLOSED_CHANNEL_UPDATE_ID};
4141
use chain::transaction::{OutPoint, TransactionData};
4242
use ln::channel::{Channel, ChannelError};
4343
use ln::features::{InitFeatures, NodeFeatures};
@@ -2152,12 +2152,23 @@ impl<ChanSigner: ChannelKeys, M: Deref, T: Deref, K: Deref, F: Deref, L: Deref>
21522152
});
21532153
},
21542154
HTLCSource::PreviousHopData(hop_data) => {
2155+
let prev_outpoint = hop_data.outpoint;
21552156
if let Err((counterparty_node_id, err)) = match self.claim_funds_from_hop(&mut channel_state_lock, hop_data, payment_preimage) {
21562157
Ok(()) => Ok(()),
21572158
Err(None) => {
2158-
// TODO: There is probably a channel monitor somewhere that needs to
2159-
// learn the preimage as the channel already hit the chain and that's
2160-
// why it's missing.
2159+
let preimage_update = ChannelMonitorUpdate {
2160+
update_id: CLOSED_CHANNEL_UPDATE_ID,
2161+
updates: vec![ChannelMonitorUpdateStep::PaymentPreimage {
2162+
payment_preimage: payment_preimage.clone(),
2163+
}],
2164+
};
2165+
// We update the ChannelMonitor on the backward link, after
2166+
// receiving an offchain preimage event from the forward link (the
2167+
// event being update_fulfill_htlc).
2168+
if let Err(e) = self.chain_monitor.update_channel(prev_outpoint, preimage_update) {
2169+
log_error!(self.logger, "Critical error: failed to update channel monitor with preimage {:?}: {:?}",
2170+
payment_preimage, e);
2171+
}
21612172
Ok(())
21622173
},
21632174
Err(Some(res)) => Err(res),

0 commit comments

Comments
 (0)