+/// The return type of get_update_fulfill_htlc_and_commit.
+pub enum UpdateFulfillCommitFetch {
+ /// Indicates the HTLC fulfill is new, and either generated an update_fulfill message, placed
+ /// it in the holding cell, or re-generated the update_fulfill message after the same claim was
+ /// previously placed in the holding cell (and has since been removed).
+ NewClaim {
+ /// The ChannelMonitorUpdate which places the new payment preimage in the channel monitor
+ monitor_update: ChannelMonitorUpdate,
+ /// The value of the HTLC which was claimed, in msat.
+ htlc_value_msat: u64,
+ /// The update_fulfill message and commitment_signed message (if the claim was not placed
+ /// in the holding cell).
+ msgs: Option<(msgs::UpdateFulfillHTLC, msgs::CommitmentSigned)>,
+ },
+ /// Indicates the HTLC fulfill is duplicative and already existed either in the holding cell
+ /// or has been forgotten (presumably previously claimed).
+ DuplicateClaim {},
+}
+
+/// The return value of `revoke_and_ack` on success, primarily updates to other channels or HTLC
+/// state.
+pub(super) struct RAAUpdates {
+ pub commitment_update: Option<msgs::CommitmentUpdate>,
+ pub accepted_htlcs: Vec<(PendingHTLCInfo, u64)>,
+ pub failed_htlcs: Vec<(HTLCSource, PaymentHash, HTLCFailReason)>,
+ pub finalized_claimed_htlcs: Vec<HTLCSource>,
+ pub monitor_update: ChannelMonitorUpdate,
+ pub holding_cell_failed_htlcs: Vec<(HTLCSource, PaymentHash)>,
+}
+
+/// The return value of `monitor_updating_restored`
+pub(super) struct MonitorRestoreUpdates {
+ pub raa: Option<msgs::RevokeAndACK>,
+ pub commitment_update: Option<msgs::CommitmentUpdate>,
+ pub order: RAACommitmentOrder,
+ pub accepted_htlcs: Vec<(PendingHTLCInfo, u64)>,
+ pub failed_htlcs: Vec<(HTLCSource, PaymentHash, HTLCFailReason)>,
+ pub finalized_claimed_htlcs: Vec<HTLCSource>,
+ pub funding_broadcastable: Option<Transaction>,
+ pub funding_locked: Option<msgs::FundingLocked>,
+}
+
+/// If the majority of the channels funds are to the fundee and the initiator holds only just
+/// enough funds to cover their reserve value, channels are at risk of getting "stuck". Because the
+/// initiator controls the feerate, if they then go to increase the channel fee, they may have no
+/// balance but the fundee is unable to send a payment as the increase in fee more than drains
+/// their reserve value. Thus, neither side can send a new HTLC and the channel becomes useless.
+/// Thus, before sending an HTLC when we are the initiator, we check that the feerate can increase
+/// by this multiple without hitting this case, before sending.
+/// This multiple is effectively the maximum feerate "jump" we expect until more HTLCs flow over
+/// the channel. Sadly, there isn't really a good number for this - if we expect to have no new
+/// HTLCs for days we may need this to suffice for feerate increases across days, but that may
+/// leave the channel less usable as we hold a bigger reserve.
+#[cfg(fuzzing)]
+pub const FEE_SPIKE_BUFFER_FEE_INCREASE_MULTIPLE: u64 = 2;
+#[cfg(not(fuzzing))]
+const FEE_SPIKE_BUFFER_FEE_INCREASE_MULTIPLE: u64 = 2;
+