// This file is Copyright its original authors, visible in version control // history. // // This file is licensed under the Apache License, Version 2.0 or the MIT license // , at your option. // You may not use this file except in accordance with one or both of these // licenses. use bitcoin::blockdata::script::{Script,Builder}; use bitcoin::blockdata::transaction::{Transaction, EcdsaSighashType}; use bitcoin::util::sighash; use bitcoin::consensus::encode; use bitcoin::hashes::Hash; use bitcoin::hashes::sha256::Hash as Sha256; use bitcoin::hashes::sha256d::Hash as Sha256d; use bitcoin::hash_types::{Txid, BlockHash}; use bitcoin::secp256k1::constants::PUBLIC_KEY_SIZE; use bitcoin::secp256k1::{PublicKey,SecretKey}; use bitcoin::secp256k1::{Secp256k1,ecdsa::Signature}; use bitcoin::secp256k1; use crate::ln::{PaymentPreimage, PaymentHash}; use crate::ln::features::{ChannelTypeFeatures, InitFeatures}; use crate::ln::msgs; use crate::ln::msgs::{DecodeError, OptionalField, DataLossProtect}; use crate::ln::script::{self, ShutdownScript}; use crate::ln::channelmanager::{self, CounterpartyForwardingInfo, PendingHTLCStatus, HTLCSource, HTLCFailReason, HTLCFailureMsg, PendingHTLCInfo, RAACommitmentOrder, BREAKDOWN_TIMEOUT, MIN_CLTV_EXPIRY_DELTA, MAX_LOCAL_BREAKDOWN_TIMEOUT}; use crate::ln::chan_utils::{CounterpartyCommitmentSecrets, TxCreationKeys, HTLCOutputInCommitment, htlc_success_tx_weight, htlc_timeout_tx_weight, make_funding_redeemscript, ChannelPublicKeys, CommitmentTransaction, HolderCommitmentTransaction, ChannelTransactionParameters, CounterpartyChannelTransactionParameters, MAX_HTLCS, get_commitment_transaction_number_obscure_factor, ClosingTransaction}; use crate::ln::chan_utils; use crate::chain::BestBlock; use crate::chain::chaininterface::{FeeEstimator, ConfirmationTarget, LowerBoundedFeeEstimator}; use crate::chain::channelmonitor::{ChannelMonitor, ChannelMonitorUpdate, ChannelMonitorUpdateStep, LATENCY_GRACE_PERIOD_BLOCKS}; use crate::chain::transaction::{OutPoint, TransactionData}; use crate::chain::keysinterface::{Sign, KeysInterface}; use crate::util::events::ClosureReason; use crate::util::ser::{Readable, ReadableArgs, Writeable, Writer, VecWriter}; use crate::util::logger::Logger; use crate::util::errors::APIError; use crate::util::config::{UserConfig, ChannelConfig, LegacyChannelConfig, ChannelHandshakeConfig, ChannelHandshakeLimits}; use crate::util::scid_utils::scid_from_parts; use crate::io; use crate::prelude::*; use core::{cmp,mem,fmt}; use core::ops::Deref; #[cfg(any(test, fuzzing, debug_assertions))] use crate::sync::Mutex; use bitcoin::hashes::hex::ToHex; #[cfg(test)] pub struct ChannelValueStat { pub value_to_self_msat: u64, pub channel_value_msat: u64, pub channel_reserve_msat: u64, pub pending_outbound_htlcs_amount_msat: u64, pub pending_inbound_htlcs_amount_msat: u64, pub holding_cell_outbound_amount_msat: u64, pub counterparty_max_htlc_value_in_flight_msat: u64, // outgoing pub counterparty_dust_limit_msat: u64, } pub struct AvailableBalances { /// The amount that would go to us if we close the channel, ignoring any on-chain fees. pub balance_msat: u64, /// Total amount available for our counterparty to send to us. pub inbound_capacity_msat: u64, /// Total amount available for us to send to our counterparty. pub outbound_capacity_msat: u64, /// The maximum value we can assign to the next outbound HTLC pub next_outbound_htlc_limit_msat: u64, } #[derive(Debug, Clone, Copy, PartialEq)] enum FeeUpdateState { // Inbound states mirroring InboundHTLCState RemoteAnnounced, AwaitingRemoteRevokeToAnnounce, // Note that we do not have a AwaitingAnnouncedRemoteRevoke variant here as it is universally // handled the same as `Committed`, with the only exception in `InboundHTLCState` being the // distinction of when we allow ourselves to forward the HTLC. Because we aren't "forwarding" // the fee update anywhere, we can simply consider the fee update `Committed` immediately // instead of setting it to AwaitingAnnouncedRemoteRevoke. // Outbound state can only be `LocalAnnounced` or `Committed` Outbound, } enum InboundHTLCRemovalReason { FailRelay(msgs::OnionErrorPacket), FailMalformed(([u8; 32], u16)), Fulfill(PaymentPreimage), } enum InboundHTLCState { /// Offered by remote, to be included in next local commitment tx. I.e., the remote sent an /// update_add_htlc message for this HTLC. RemoteAnnounced(PendingHTLCStatus), /// Included in a received commitment_signed message (implying we've /// revoke_and_ack'd it), but the remote hasn't yet revoked their previous /// state (see the example below). We have not yet included this HTLC in a /// commitment_signed message because we are waiting on the remote's /// aforementioned state revocation. One reason this missing remote RAA /// (revoke_and_ack) blocks us from constructing a commitment_signed message /// is because every time we create a new "state", i.e. every time we sign a /// new commitment tx (see [BOLT #2]), we need a new per_commitment_point, /// which are provided one-at-a-time in each RAA. E.g., the last RAA they /// sent provided the per_commitment_point for our current commitment tx. /// The other reason we should not send a commitment_signed without their RAA /// is because their RAA serves to ACK our previous commitment_signed. /// /// Here's an example of how an HTLC could come to be in this state: /// remote --> update_add_htlc(prev_htlc) --> local /// remote --> commitment_signed(prev_htlc) --> local /// remote <-- revoke_and_ack <-- local /// remote <-- commitment_signed(prev_htlc) <-- local /// [note that here, the remote does not respond with a RAA] /// remote --> update_add_htlc(this_htlc) --> local /// remote --> commitment_signed(prev_htlc, this_htlc) --> local /// Now `this_htlc` will be assigned this state. It's unable to be officially /// accepted, i.e. included in a commitment_signed, because we're missing the /// RAA that provides our next per_commitment_point. The per_commitment_point /// is used to derive commitment keys, which are used to construct the /// signatures in a commitment_signed message. /// Implies AwaitingRemoteRevoke. /// /// [BOLT #2]: https://github.com/lightning/bolts/blob/master/02-peer-protocol.md AwaitingRemoteRevokeToAnnounce(PendingHTLCStatus), /// Included in a received commitment_signed message (implying we've revoke_and_ack'd it). /// We have also included this HTLC in our latest commitment_signed and are now just waiting /// on the remote's revoke_and_ack to make this HTLC an irrevocable part of the state of the /// channel (before it can then get forwarded and/or removed). /// Implies AwaitingRemoteRevoke. AwaitingAnnouncedRemoteRevoke(PendingHTLCStatus), Committed, /// Removed by us and a new commitment_signed was sent (if we were AwaitingRemoteRevoke when we /// created it we would have put it in the holding cell instead). When they next revoke_and_ack /// we'll drop it. /// Note that we have to keep an eye on the HTLC until we've received a broadcastable /// commitment transaction without it as otherwise we'll have to force-close the channel to /// claim it before the timeout (obviously doesn't apply to revoked HTLCs that we can't claim /// anyway). That said, ChannelMonitor does this for us (see /// ChannelMonitor::should_broadcast_holder_commitment_txn) so we actually remove the HTLC from /// our own local state before then, once we're sure that the next commitment_signed and /// ChannelMonitor::provide_latest_local_commitment_tx will not include this HTLC. LocalRemoved(InboundHTLCRemovalReason), } struct InboundHTLCOutput { htlc_id: u64, amount_msat: u64, cltv_expiry: u32, payment_hash: PaymentHash, state: InboundHTLCState, } enum OutboundHTLCState { /// Added by us and included in a commitment_signed (if we were AwaitingRemoteRevoke when we /// created it we would have put it in the holding cell instead). When they next revoke_and_ack /// we will promote to Committed (note that they may not accept it until the next time we /// revoke, but we don't really care about that: /// * they've revoked, so worst case we can announce an old state and get our (option on) /// money back (though we won't), and, /// * we'll send them a revoke when they send a commitment_signed, and since only they're /// allowed to remove it, the "can only be removed once committed on both sides" requirement /// doesn't matter to us and it's up to them to enforce it, worst-case they jump ahead but /// we'll never get out of sync). /// Note that we Box the OnionPacket as it's rather large and we don't want to blow up /// OutboundHTLCOutput's size just for a temporary bit LocalAnnounced(Box), Committed, /// Remote removed this (outbound) HTLC. We're waiting on their commitment_signed to finalize /// the change (though they'll need to revoke before we fail the payment). RemoteRemoved(OutboundHTLCOutcome), /// Remote removed this and sent a commitment_signed (implying we've revoke_and_ack'ed it), but /// the remote side hasn't yet revoked their previous state, which we need them to do before we /// can do any backwards failing. Implies AwaitingRemoteRevoke. /// We also have not yet removed this HTLC in a commitment_signed message, and are waiting on a /// remote revoke_and_ack on a previous state before we can do so. AwaitingRemoteRevokeToRemove(OutboundHTLCOutcome), /// Remote removed this and sent a commitment_signed (implying we've revoke_and_ack'ed it), but /// the remote side hasn't yet revoked their previous state, which we need them to do before we /// can do any backwards failing. Implies AwaitingRemoteRevoke. /// We have removed this HTLC in our latest commitment_signed and are now just waiting on a /// revoke_and_ack to drop completely. AwaitingRemovedRemoteRevoke(OutboundHTLCOutcome), } #[derive(Clone)] enum OutboundHTLCOutcome { Success(Option), Failure(HTLCFailReason), } impl From> for OutboundHTLCOutcome { fn from(o: Option) -> Self { match o { None => OutboundHTLCOutcome::Success(None), Some(r) => OutboundHTLCOutcome::Failure(r) } } } impl<'a> Into> for &'a OutboundHTLCOutcome { fn into(self) -> Option<&'a HTLCFailReason> { match self { OutboundHTLCOutcome::Success(_) => None, OutboundHTLCOutcome::Failure(ref r) => Some(r) } } } struct OutboundHTLCOutput { htlc_id: u64, amount_msat: u64, cltv_expiry: u32, payment_hash: PaymentHash, state: OutboundHTLCState, source: HTLCSource, } /// See AwaitingRemoteRevoke ChannelState for more info enum HTLCUpdateAwaitingACK { AddHTLC { // TODO: Time out if we're getting close to cltv_expiry // always outbound amount_msat: u64, cltv_expiry: u32, payment_hash: PaymentHash, source: HTLCSource, onion_routing_packet: msgs::OnionPacket, }, ClaimHTLC { payment_preimage: PaymentPreimage, htlc_id: u64, }, FailHTLC { htlc_id: u64, err_packet: msgs::OnionErrorPacket, }, } /// There are a few "states" and then a number of flags which can be applied: /// We first move through init with OurInitSent -> TheirInitSent -> FundingCreated -> FundingSent. /// TheirChannelReady and OurChannelReady then get set on FundingSent, and when both are set we /// move on to ChannelReady. /// Note that PeerDisconnected can be set on both ChannelReady and FundingSent. /// ChannelReady can then get all remaining flags set on it, until we finish shutdown, then we /// move on to ShutdownComplete, at which point most calls into this channel are disallowed. enum ChannelState { /// Implies we have (or are prepared to) send our open_channel/accept_channel message OurInitSent = 1 << 0, /// Implies we have received their open_channel/accept_channel message TheirInitSent = 1 << 1, /// We have sent funding_created and are awaiting a funding_signed to advance to FundingSent. /// Note that this is nonsense for an inbound channel as we immediately generate funding_signed /// upon receipt of funding_created, so simply skip this state. FundingCreated = 4, /// Set when we have received/sent funding_created and funding_signed and are thus now waiting /// on the funding transaction to confirm. The ChannelReady flags are set to indicate when we /// and our counterparty consider the funding transaction confirmed. FundingSent = 8, /// Flag which can be set on FundingSent to indicate they sent us a channel_ready message. /// Once both TheirChannelReady and OurChannelReady are set, state moves on to ChannelReady. TheirChannelReady = 1 << 4, /// Flag which can be set on FundingSent to indicate we sent them a channel_ready message. /// Once both TheirChannelReady and OurChannelReady are set, state moves on to ChannelReady. OurChannelReady = 1 << 5, ChannelReady = 64, /// Flag which is set on ChannelReady and FundingSent indicating remote side is considered /// "disconnected" and no updates are allowed until after we've done a channel_reestablish /// dance. PeerDisconnected = 1 << 7, /// Flag which is set on ChannelReady, FundingCreated, and FundingSent indicating the user has /// told us a ChannelMonitor update is pending async persistence somewhere and we should pause /// sending any outbound messages until they've managed to finish. MonitorUpdateInProgress = 1 << 8, /// Flag which implies that we have sent a commitment_signed but are awaiting the responding /// revoke_and_ack message. During this time period, we can't generate new commitment_signed /// messages as then we will be unable to determine which HTLCs they included in their /// revoke_and_ack implicit ACK, so instead we have to hold them away temporarily to be sent /// later. /// Flag is set on ChannelReady. AwaitingRemoteRevoke = 1 << 9, /// Flag which is set on ChannelReady or FundingSent after receiving a shutdown message from /// the remote end. If set, they may not add any new HTLCs to the channel, and we are expected /// to respond with our own shutdown message when possible. RemoteShutdownSent = 1 << 10, /// Flag which is set on ChannelReady or FundingSent after sending a shutdown message. At this /// point, we may not add any new HTLCs to the channel. LocalShutdownSent = 1 << 11, /// We've successfully negotiated a closing_signed dance. At this point ChannelManager is about /// to drop us, but we store this anyway. ShutdownComplete = 4096, } const BOTH_SIDES_SHUTDOWN_MASK: u32 = ChannelState::LocalShutdownSent as u32 | ChannelState::RemoteShutdownSent as u32; const MULTI_STATE_FLAGS: u32 = BOTH_SIDES_SHUTDOWN_MASK | ChannelState::PeerDisconnected as u32 | ChannelState::MonitorUpdateInProgress as u32; pub const INITIAL_COMMITMENT_NUMBER: u64 = (1 << 48) - 1; /// The "channel disabled" bit in channel_update must be set based on whether we are connected to /// our counterparty or not. However, we don't want to announce updates right away to avoid /// spamming the network with updates if the connection is flapping. Instead, we "stage" updates to /// our channel_update message and track the current state here. /// See implementation at [`super::channelmanager::ChannelManager::timer_tick_occurred`]. #[derive(Clone, Copy, PartialEq)] pub(super) enum ChannelUpdateStatus { /// We've announced the channel as enabled and are connected to our peer. Enabled, /// Our channel is no longer live, but we haven't announced the channel as disabled yet. DisabledStaged, /// Our channel is live again, but we haven't announced the channel as enabled yet. EnabledStaged, /// We've announced the channel as disabled. Disabled, } /// We track when we sent an `AnnouncementSignatures` to our peer in a few states, described here. #[derive(PartialEq)] pub enum AnnouncementSigsState { /// We have not sent our peer an `AnnouncementSignatures` yet, or our peer disconnected since /// we sent the last `AnnouncementSignatures`. NotSent, /// We sent an `AnnouncementSignatures` to our peer since the last time our peer disconnected. /// This state never appears on disk - instead we write `NotSent`. MessageSent, /// We sent a `CommitmentSigned` after the last `AnnouncementSignatures` we sent. Because we /// only ever have a single `CommitmentSigned` pending at once, if we sent one after sending /// `AnnouncementSignatures` then we know the peer received our `AnnouncementSignatures` if /// they send back a `RevokeAndACK`. /// This state never appears on disk - instead we write `NotSent`. Committed, /// We received a `RevokeAndACK`, effectively ack-ing our `AnnouncementSignatures`, at this /// point we no longer need to re-send our `AnnouncementSignatures` again on reconnect. PeerReceived, } /// An enum indicating whether the local or remote side offered a given HTLC. enum HTLCInitiator { LocalOffered, RemoteOffered, } /// An enum gathering stats on pending HTLCs, either inbound or outbound side. struct HTLCStats { pending_htlcs: u32, pending_htlcs_value_msat: u64, on_counterparty_tx_dust_exposure_msat: u64, on_holder_tx_dust_exposure_msat: u64, holding_cell_msat: u64, on_holder_tx_holding_cell_htlcs_count: u32, // dust HTLCs *non*-included } /// An enum gathering stats on commitment transaction, either local or remote. struct CommitmentStats<'a> { tx: CommitmentTransaction, // the transaction info feerate_per_kw: u32, // the feerate included to build the transaction total_fee_sat: u64, // the total fee included in the transaction num_nondust_htlcs: usize, // the number of HTLC outputs (dust HTLCs *non*-included) htlcs_included: Vec<(HTLCOutputInCommitment, Option<&'a HTLCSource>)>, // the list of HTLCs (dust HTLCs *included*) which were not ignored when building the transaction local_balance_msat: u64, // local balance before fees but considering dust limits remote_balance_msat: u64, // remote balance before fees but considering dust limits preimages: Vec, // preimages for successful offered HTLCs since last commitment } /// Used when calculating whether we or the remote can afford an additional HTLC. struct HTLCCandidate { amount_msat: u64, origin: HTLCInitiator, } impl HTLCCandidate { fn new(amount_msat: u64, origin: HTLCInitiator) -> Self { Self { amount_msat, origin, } } } /// A return value enum for get_update_fulfill_htlc. See UpdateFulfillCommitFetch variants for /// description enum UpdateFulfillFetch { NewClaim { monitor_update: ChannelMonitorUpdate, htlc_value_msat: u64, msg: Option, }, DuplicateClaim {}, } /// 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, pub accepted_htlcs: Vec<(PendingHTLCInfo, u64)>, pub failed_htlcs: Vec<(HTLCSource, PaymentHash, HTLCFailReason)>, pub finalized_claimed_htlcs: Vec, 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, pub commitment_update: Option, pub order: RAACommitmentOrder, pub accepted_htlcs: Vec<(PendingHTLCInfo, u64)>, pub failed_htlcs: Vec<(HTLCSource, PaymentHash, HTLCFailReason)>, pub finalized_claimed_htlcs: Vec, pub funding_broadcastable: Option, pub channel_ready: Option, pub announcement_sigs: Option, } /// The return value of `channel_reestablish` pub(super) struct ReestablishResponses { pub channel_ready: Option, pub raa: Option, pub commitment_update: Option, pub order: RAACommitmentOrder, pub mon_update: Option, pub holding_cell_failed_htlcs: Vec<(HTLCSource, PaymentHash)>, pub announcement_sigs: Option, pub shutdown_msg: Option, } /// 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(any(fuzzing, test))] pub const FEE_SPIKE_BUFFER_FEE_INCREASE_MULTIPLE: u64 = 2; #[cfg(not(any(fuzzing, test)))] const FEE_SPIKE_BUFFER_FEE_INCREASE_MULTIPLE: u64 = 2; /// If we fail to see a funding transaction confirmed on-chain within this many blocks after the /// channel creation on an inbound channel, we simply force-close and move on. /// This constant is the one suggested in BOLT 2. pub(crate) const FUNDING_CONF_DEADLINE_BLOCKS: u32 = 2016; /// In case of a concurrent update_add_htlc proposed by our counterparty, we might /// not have enough balance value remaining to cover the onchain cost of this new /// HTLC weight. If this happens, our counterparty fails the reception of our /// commitment_signed including this new HTLC due to infringement on the channel /// reserve. /// To prevent this case, we compute our outbound update_fee with an HTLC buffer of /// size 2. However, if the number of concurrent update_add_htlc is higher, this still /// leads to a channel force-close. Ultimately, this is an issue coming from the /// design of LN state machines, allowing asynchronous updates. pub(crate) const CONCURRENT_INBOUND_HTLC_FEE_BUFFER: u32 = 2; /// When a channel is opened, we check that the funding amount is enough to pay for relevant /// commitment transaction fees, with at least this many HTLCs present on the commitment /// transaction (not counting the value of the HTLCs themselves). pub(crate) const MIN_AFFORDABLE_HTLC_COUNT: usize = 4; /// When a [`Channel`] has its [`ChannelConfig`] updated, its existing one is stashed for up to this /// number of ticks to allow forwarding HTLCs by nodes that have yet to receive the new /// ChannelUpdate prompted by the config update. This value was determined as follows: /// /// * The expected interval between ticks (1 minute). /// * The average convergence delay of updates across the network, i.e., ~300 seconds on average /// for a node to see an update as seen on ``. /// * `EXPIRE_PREV_CONFIG_TICKS` = convergence_delay / tick_interval pub(crate) const EXPIRE_PREV_CONFIG_TICKS: usize = 5; // TODO: We should refactor this to be an Inbound/OutboundChannel until initial setup handshaking // has been completed, and then turn into a Channel to get compiler-time enforcement of things like // calling channel_id() before we're set up or things like get_outbound_funding_signed on an // inbound channel. // // Holder designates channel data owned for the benefice of the user client. // Counterparty designates channel data owned by the another channel participant entity. pub(super) struct Channel { config: LegacyChannelConfig, // Track the previous `ChannelConfig` so that we can continue forwarding HTLCs that were // constructed using it. The second element in the tuple corresponds to the number of ticks that // have elapsed since the update occurred. prev_config: Option<(ChannelConfig, usize)>, inbound_handshake_limits_override: Option, user_id: u64, channel_id: [u8; 32], channel_state: u32, // When we reach max(6 blocks, minimum_depth), we need to send an AnnouncementSigs message to // our peer. However, we want to make sure they received it, or else rebroadcast it when we // next connect. // We do so here, see `AnnouncementSigsSent` for more details on the state(s). // Note that a number of our tests were written prior to the behavior here which retransmits // AnnouncementSignatures until after an RAA completes, so the behavior is short-circuited in // many tests. #[cfg(any(test, feature = "_test_utils"))] pub(crate) announcement_sigs_state: AnnouncementSigsState, #[cfg(not(any(test, feature = "_test_utils")))] announcement_sigs_state: AnnouncementSigsState, secp_ctx: Secp256k1, channel_value_satoshis: u64, latest_monitor_update_id: u64, holder_signer: Signer, shutdown_scriptpubkey: Option, destination_script: Script, // Our commitment numbers start at 2^48-1 and count down, whereas the ones used in transaction // generation start at 0 and count up...this simplifies some parts of implementation at the // cost of others, but should really just be changed. cur_holder_commitment_transaction_number: u64, cur_counterparty_commitment_transaction_number: u64, value_to_self_msat: u64, // Excluding all pending_htlcs, excluding fees pending_inbound_htlcs: Vec, pending_outbound_htlcs: Vec, holding_cell_htlc_updates: Vec, /// When resending CS/RAA messages on channel monitor restoration or on reconnect, we always /// need to ensure we resend them in the order we originally generated them. Note that because /// there can only ever be one in-flight CS and/or one in-flight RAA at any time, it is /// sufficient to simply set this to the opposite of any message we are generating as we /// generate it. ie when we generate a CS, we set this to RAAFirst as, if there is a pending /// in-flight RAA to resend, it will have been the first thing we generated, and thus we should /// send it first. resend_order: RAACommitmentOrder, monitor_pending_channel_ready: bool, monitor_pending_revoke_and_ack: bool, monitor_pending_commitment_signed: bool, monitor_pending_forwards: Vec<(PendingHTLCInfo, u64)>, monitor_pending_failures: Vec<(HTLCSource, PaymentHash, HTLCFailReason)>, monitor_pending_finalized_fulfills: Vec, // pending_update_fee is filled when sending and receiving update_fee. // // Because it follows the same commitment flow as HTLCs, `FeeUpdateState` is either `Outbound` // or matches a subset of the `InboundHTLCOutput` variants. It is then updated/used when // generating new commitment transactions with exactly the same criteria as inbound/outbound // HTLCs with similar state. pending_update_fee: Option<(u32, FeeUpdateState)>, // If a `send_update_fee()` call is made with ChannelState::AwaitingRemoteRevoke set, we place // it here instead of `pending_update_fee` in the same way as we place outbound HTLC updates in // `holding_cell_htlc_updates` instead of `pending_outbound_htlcs`. It is released into // `pending_update_fee` with the same criteria as outbound HTLC updates but can be updated by // further `send_update_fee` calls, dropping the previous holding cell update entirely. holding_cell_update_fee: Option, next_holder_htlc_id: u64, next_counterparty_htlc_id: u64, feerate_per_kw: u32, /// The timestamp set on our latest `channel_update` message for this channel. It is updated /// when the channel is updated in ways which may impact the `channel_update` message or when a /// new block is received, ensuring it's always at least moderately close to the current real /// time. update_time_counter: u32, #[cfg(debug_assertions)] /// Max to_local and to_remote outputs in a locally-generated commitment transaction holder_max_commitment_tx_output: Mutex<(u64, u64)>, #[cfg(debug_assertions)] /// Max to_local and to_remote outputs in a remote-generated commitment transaction counterparty_max_commitment_tx_output: Mutex<(u64, u64)>, last_sent_closing_fee: Option<(u64, Signature)>, // (fee, holder_sig) target_closing_feerate_sats_per_kw: Option, /// If our counterparty sent us a closing_signed while we were waiting for a `ChannelMonitor` /// update, we need to delay processing it until later. We do that here by simply storing the /// closing_signed message and handling it in `maybe_propose_closing_signed`. pending_counterparty_closing_signed: Option, /// The minimum and maximum absolute fee, in satoshis, we are willing to place on the closing /// transaction. These are set once we reach `closing_negotiation_ready`. #[cfg(test)] pub(crate) closing_fee_limits: Option<(u64, u64)>, #[cfg(not(test))] closing_fee_limits: Option<(u64, u64)>, /// Flag that ensures that `accept_inbound_channel` must be called before `funding_created` /// is executed successfully. The reason for this flag is that when the /// `UserConfig::manually_accept_inbound_channels` config flag is set to true, inbound channels /// are required to be manually accepted by the node operator before the `msgs::AcceptChannel` /// message is created and sent out. During the manual accept process, `accept_inbound_channel` /// is called by `ChannelManager::accept_inbound_channel`. /// /// The flag counteracts that a counterparty node could theoretically send a /// `msgs::FundingCreated` message before the node operator has manually accepted an inbound /// channel request made by the counterparty node. That would execute `funding_created` before /// `accept_inbound_channel`, and `funding_created` should therefore not execute successfully. inbound_awaiting_accept: bool, /// The hash of the block in which the funding transaction was included. funding_tx_confirmed_in: Option, funding_tx_confirmation_height: u32, short_channel_id: Option, /// Either the height at which this channel was created or the height at which it was last /// serialized if it was serialized by versions prior to 0.0.103. /// We use this to close if funding is never broadcasted. channel_creation_height: u32, counterparty_dust_limit_satoshis: u64, #[cfg(test)] pub(super) holder_dust_limit_satoshis: u64, #[cfg(not(test))] holder_dust_limit_satoshis: u64, #[cfg(test)] pub(super) counterparty_max_htlc_value_in_flight_msat: u64, #[cfg(not(test))] counterparty_max_htlc_value_in_flight_msat: u64, #[cfg(test)] pub(super) holder_max_htlc_value_in_flight_msat: u64, #[cfg(not(test))] holder_max_htlc_value_in_flight_msat: u64, /// minimum channel reserve for self to maintain - set by them. counterparty_selected_channel_reserve_satoshis: Option, #[cfg(test)] pub(super) holder_selected_channel_reserve_satoshis: u64, #[cfg(not(test))] holder_selected_channel_reserve_satoshis: u64, counterparty_htlc_minimum_msat: u64, holder_htlc_minimum_msat: u64, #[cfg(test)] pub counterparty_max_accepted_htlcs: u16, #[cfg(not(test))] counterparty_max_accepted_htlcs: u16, //implied by OUR_MAX_HTLCS: max_accepted_htlcs: u16, minimum_depth: Option, counterparty_forwarding_info: Option, pub(crate) channel_transaction_parameters: ChannelTransactionParameters, funding_transaction: Option, counterparty_cur_commitment_point: Option, counterparty_prev_commitment_point: Option, counterparty_node_id: PublicKey, counterparty_shutdown_scriptpubkey: Option