You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Block the mon update removing a preimage until upstream mon writes
When we forward a payment and receive an `update_fulfill_htlc`
message from the downstream channel, we immediately claim the HTLC
on the upstream channel, before even doing a `commitment_signed`
dance on the downstream channel. This implies that our
`ChannelMonitorUpdate`s "go out" in the right order - first we
ensure we'll get our money by writing the preimage down, then we
write the update that resolves giving money on the downstream node.
This is safe as long as `ChannelMonitorUpdate`s complete in the
order in which they are generated, but of course looking forward we
want to support asynchronous updates, which may complete in any
order.
Thus, here, we enforce the correct ordering by blocking the
downstream `ChannelMonitorUpdate` until the upstream one completes.
Like the `PaymentSent` event handling we do so only for the
`revoke_and_ack` `ChannelMonitorUpdate`, ensuring the
preimage-containing upstream update has a full RTT to complete
before we actually manage to slow anything down.
// Note that we do not need to push an `actions_blocking_raa_monitor_updates`
5591
+
// entry here, even though we *do* need to block the next RAA coming in from
5592
+
// generating a monitor update which we let fly. We do this instead in the
5593
+
// `claim_funds_internal` by attaching a `ReleaseRAAChannelMonitorUpdate`
5594
+
// action to the event generated when we "claim" the sent payment. This is
5595
+
// guaranteed to all complete before we process the RAA even though there is no
5596
+
// lock held through that point as we aren't allowed to see another P2P message
5597
+
// from the counterparty until we return, but `claim_funds_internal` runs
5598
+
// first.
5572
5599
funding_txo = chan.get().context.get_funding_txo().expect("We won't accept a fulfill until funded");
5573
5600
res
5574
5601
},
5575
5602
hash_map::Entry::Vacant(_) => returnErr(MsgHandleErrInternal::send_err_msg_no_close(format!("Got a message for a channel from the wrong node! No such channel for the passed counterparty_node_id {}", counterparty_node_id), msg.channel_id))
log_trace!(self.logger,"Claiming HTLC with preimage {} from our monitor", log_bytes!(preimage.0));
5955
-
self.claim_funds_internal(htlc_update.source, preimage, htlc_update.htlc_value_satoshis.map(|v| v *1000),true, funding_outpoint,false);
5997
+
self.claim_funds_internal(htlc_update.source, preimage, htlc_update.htlc_value_satoshis.map(|v| v *1000),true,counterparty_node_id,funding_outpoint,false);
5956
5998
}else{
5957
5999
log_trace!(self.logger,"Failing HTLC with hash {} from our monitor", log_bytes!(htlc_update.payment_hash.0));
5958
6000
let receiver = HTLCDestination::NextHopChannel{node_id: counterparty_node_id,channel_id: funding_outpoint.to_channel_id()};
0 commit comments