X-Git-Url: http://git.bitcoin.ninja/index.cgi?a=blobdiff_plain;f=lightning%2Fsrc%2Fln%2Fchannel.rs;h=cf543b32d227ea720b35c365ca467b3793383ede;hb=27b9794beddbef6f0cf844d4fc7afed0226c765f;hp=30280f0b1f131a45a883f7b292a2cc3cadbb0997;hpb=e40b6ae8b7480f44ad1f8eb0e4705d2c844562e6;p=rust-lightning diff --git a/lightning/src/ln/channel.rs b/lightning/src/ln/channel.rs index 30280f0b..cf543b32 100644 --- a/lightning/src/ln/channel.rs +++ b/lightning/src/ln/channel.rs @@ -7,9 +7,11 @@ // 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::blockdata::constants::ChainHash; +use bitcoin::blockdata::script::{Script, ScriptBuf, Builder}; +use bitcoin::blockdata::transaction::Transaction; +use bitcoin::sighash; +use bitcoin::sighash::EcdsaSighashType; use bitcoin::consensus::encode; use bitcoin::hashes::Hash; @@ -22,12 +24,12 @@ use bitcoin::secp256k1::{PublicKey,SecretKey}; use bitcoin::secp256k1::{Secp256k1,ecdsa::Signature}; use bitcoin::secp256k1; -use crate::ln::{PaymentPreimage, PaymentHash}; +use crate::ln::{ChannelId, PaymentPreimage, PaymentHash}; use crate::ln::features::{ChannelTypeFeatures, InitFeatures}; use crate::ln::msgs; use crate::ln::msgs::DecodeError; use crate::ln::script::{self, ShutdownScript}; -use crate::ln::channelmanager::{self, CounterpartyForwardingInfo, PendingHTLCStatus, HTLCSource, SentHTLCId, HTLCFailureMsg, PendingHTLCInfo, RAACommitmentOrder, BREAKDOWN_TIMEOUT, MIN_CLTV_EXPIRY_DELTA, MAX_LOCAL_BREAKDOWN_TIMEOUT}; +use crate::ln::channelmanager::{self, CounterpartyForwardingInfo, PendingHTLCStatus, HTLCSource, SentHTLCId, HTLCFailureMsg, PendingHTLCInfo, RAACommitmentOrder, BREAKDOWN_TIMEOUT, MIN_CLTV_EXPIRY_DELTA, MAX_LOCAL_BREAKDOWN_TIMEOUT, ChannelShutdownState}; 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::ln::onion_utils::HTLCFailReason; @@ -35,22 +37,25 @@ use crate::chain::BestBlock; use crate::chain::chaininterface::{FeeEstimator, ConfirmationTarget, LowerBoundedFeeEstimator}; use crate::chain::channelmonitor::{ChannelMonitor, ChannelMonitorUpdate, ChannelMonitorUpdateStep, LATENCY_GRACE_PERIOD_BLOCKS, CLOSED_CHANNEL_UPDATE_ID}; use crate::chain::transaction::{OutPoint, TransactionData}; -use crate::sign::{WriteableEcdsaChannelSigner, EntropySource, ChannelSigner, SignerProvider, NodeSigner, Recipient}; +use crate::sign::{EcdsaChannelSigner, WriteableEcdsaChannelSigner, EntropySource, ChannelSigner, SignerProvider, NodeSigner, Recipient}; use crate::events::ClosureReason; use crate::routing::gossip::NodeId; -use crate::util::ser::{Readable, ReadableArgs, Writeable, Writer, VecWriter}; +use crate::util::ser::{Readable, ReadableArgs, Writeable, Writer}; use crate::util::logger::Logger; use crate::util::errors::APIError; -use crate::util::config::{UserConfig, ChannelConfig, LegacyChannelConfig, ChannelHandshakeConfig, ChannelHandshakeLimits}; +use crate::util::config::{UserConfig, ChannelConfig, LegacyChannelConfig, ChannelHandshakeConfig, ChannelHandshakeLimits, MaxDustHTLCExposure}; use crate::util::scid_utils::scid_from_parts; use crate::io; use crate::prelude::*; use core::{cmp,mem,fmt}; +use core::convert::TryInto; use core::ops::Deref; #[cfg(any(test, fuzzing, debug_assertions))] use crate::sync::Mutex; -use bitcoin::hashes::hex::ToHex; +use crate::sign::type_resolver::ChannelSignerType; + +use super::channel_keys::{DelayedPaymentBasepoint, HtlcBasepoint, RevocationBasepoint}; #[cfg(test)] pub struct ChannelValueStat { @@ -250,38 +255,38 @@ enum HTLCUpdateAwaitingACK { } /// 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. +/// 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 + /// 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. + /// 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 + /// 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. + /// 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. + /// 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 + /// 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 + /// 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 @@ -289,21 +294,36 @@ enum ChannelState { /// 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. + /// Flag is set on `ChannelReady`. AwaitingRemoteRevoke = 1 << 9, - /// Flag which is set on ChannelReady or FundingSent after receiving a shutdown message from + /// 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 + /// 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, + /// Flag which is set on `FundingSent` to indicate this channel is funded in a batch and the + /// broadcasting of the funding transaction is being held until all channels in the batch + /// have received funding_signed and have their monitors persisted. + WaitingForBatch = 1 << 13, } -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; +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; +const STATE_FLAGS: u32 = + MULTI_STATE_FLAGS | + ChannelState::TheirChannelReady as u32 | + ChannelState::OurChannelReady as u32 | + ChannelState::AwaitingRemoteRevoke as u32 | + ChannelState::WaitingForBatch as u32; pub const INITIAL_COMMITMENT_NUMBER: u64 = (1 << 48) - 1; @@ -516,6 +536,15 @@ pub(super) struct MonitorRestoreUpdates { pub announcement_sigs: Option, } +/// The return value of `signer_maybe_unblocked` +#[allow(unused)] +pub(super) struct SignerResumeUpdates { + pub commitment_update: Option, + pub funding_signed: Option, + pub funding_created: Option, + pub channel_ready: Option, +} + /// The return value of `channel_reestablish` pub(super) struct ReestablishResponses { pub channel_ready: Option, @@ -526,11 +555,17 @@ pub(super) struct ReestablishResponses { pub shutdown_msg: Option, } -/// The return type of `force_shutdown` -pub(crate) type ShutdownResult = ( - Option<(PublicKey, OutPoint, ChannelMonitorUpdate)>, - Vec<(HTLCSource, PaymentHash, PublicKey, [u8; 32])> -); +/// The result of a shutdown that should be handled. +#[must_use] +pub(crate) struct ShutdownResult { + /// A channel monitor update to apply. + pub(crate) monitor_update: Option<(PublicKey, OutPoint, ChannelMonitorUpdate)>, + /// A list of dropped outbound HTLCs that can safely be failed backwards immediately. + pub(crate) dropped_outbound_htlcs: Vec<(HTLCSource, PaymentHash, PublicKey, ChannelId)>, + /// An unbroadcasted batch funding transaction id. The closure of this channel should be + /// propagated to the remainder of the batch. + pub(crate) unbroadcasted_batch_funding_txid: 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 @@ -586,6 +621,14 @@ pub(crate) const EXPIRE_PREV_CONFIG_TICKS: usize = 5; /// See [`ChannelContext::sent_message_awaiting_response`] for more information. pub(crate) const DISCONNECT_PEER_AWAITING_RESPONSE_TICKS: usize = 2; +/// The number of ticks that may elapse while we're waiting for an unfunded outbound/inbound channel +/// to be promoted to a [`Channel`] since the unfunded channel was created. An unfunded channel +/// exceeding this age limit will be force-closed and purged from memory. +pub(crate) const UNFUNDED_CHANNEL_AGE_LIMIT_TICKS: usize = 60; + +/// Number of blocks needed for an output from a coinbase transaction to be spendable. +pub(crate) const COINBASE_MATURITY: u32 = 100; + struct PendingChannelMonitorUpdate { update: ChannelMonitorUpdate, } @@ -594,8 +637,59 @@ impl_writeable_tlv_based!(PendingChannelMonitorUpdate, { (0, update, required), }); +/// The `ChannelPhase` enum describes the current phase in life of a lightning channel with each of +/// its variants containing an appropriate channel struct. +pub(super) enum ChannelPhase where SP::Target: SignerProvider { + UnfundedOutboundV1(OutboundV1Channel), + UnfundedInboundV1(InboundV1Channel), + Funded(Channel), +} + +impl<'a, SP: Deref> ChannelPhase where + SP::Target: SignerProvider, + ::EcdsaSigner: ChannelSigner, +{ + pub fn context(&'a self) -> &'a ChannelContext { + match self { + ChannelPhase::Funded(chan) => &chan.context, + ChannelPhase::UnfundedOutboundV1(chan) => &chan.context, + ChannelPhase::UnfundedInboundV1(chan) => &chan.context, + } + } + + pub fn context_mut(&'a mut self) -> &'a mut ChannelContext { + match self { + ChannelPhase::Funded(ref mut chan) => &mut chan.context, + ChannelPhase::UnfundedOutboundV1(ref mut chan) => &mut chan.context, + ChannelPhase::UnfundedInboundV1(ref mut chan) => &mut chan.context, + } + } +} + +/// Contains all state common to unfunded inbound/outbound channels. +pub(super) struct UnfundedChannelContext { + /// A counter tracking how many ticks have elapsed since this unfunded channel was + /// created. If this unfunded channel reaches peer has yet to respond after reaching + /// `UNFUNDED_CHANNEL_AGE_LIMIT_TICKS`, it will be force-closed and purged from memory. + /// + /// This is so that we don't keep channels around that haven't progressed to a funded state + /// in a timely manner. + unfunded_channel_age_ticks: usize, +} + +impl UnfundedChannelContext { + /// Determines whether we should force-close and purge this unfunded channel from memory due to it + /// having reached the unfunded channel age limit. + /// + /// This should be called on every [`super::channelmanager::ChannelManager::timer_tick_occurred`]. + pub fn should_expire_unfunded_channel(&mut self) -> bool { + self.unfunded_channel_age_ticks += 1; + self.unfunded_channel_age_ticks >= UNFUNDED_CHANNEL_AGE_LIMIT_TICKS + } +} + /// Contains everything about the channel including state, and various flags. -pub(super) struct ChannelContext { +pub(super) struct ChannelContext where SP::Target: SignerProvider { config: LegacyChannelConfig, // Track the previous `ChannelConfig` so that we can continue forwarding HTLCs that were @@ -607,8 +701,11 @@ pub(super) struct ChannelContext { user_id: u128, - channel_id: [u8; 32], - temporary_channel_id: Option<[u8; 32]>, // Will be `None` for channels created prior to 0.0.115. + /// The current channel ID. + channel_id: ChannelId, + /// The temporary channel ID used during channel setup. Value kept even after transitioning to a final channel ID. + /// Will be `None` for channels created prior to 0.0.115. + temporary_channel_id: Option, channel_state: u32, // When we reach max(6 blocks, minimum_depth), we need to send an AnnouncementSigs message to @@ -628,9 +725,9 @@ pub(super) struct ChannelContext { latest_monitor_update_id: u64, - holder_signer: Signer, + holder_signer: ChannelSignerType<::EcdsaSigner>, shutdown_scriptpubkey: Option, - destination_script: Script, + destination_script: ScriptBuf, // 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 @@ -638,7 +735,7 @@ pub(super) struct ChannelContext { cur_holder_commitment_transaction_number: u64, cur_counterparty_commitment_transaction_number: u64, - value_to_self_msat: u64, // Excluding all pending_htlcs, excluding fees + value_to_self_msat: u64, // Excluding all pending_htlcs, fees, and anchor outputs pending_inbound_htlcs: Vec, pending_outbound_htlcs: Vec, holding_cell_htlc_updates: Vec, @@ -664,6 +761,18 @@ pub(super) struct ChannelContext { monitor_pending_failures: Vec<(HTLCSource, PaymentHash, HTLCFailReason)>, monitor_pending_finalized_fulfills: Vec, + /// If we went to send a commitment update (ie some messages then [`msgs::CommitmentSigned`]) + /// but our signer (initially) refused to give us a signature, we should retry at some point in + /// the future when the signer indicates it may have a signature for us. + /// + /// This flag is set in such a case. Note that we don't need to persist this as we'll end up + /// setting it again as a side-effect of [`Channel::channel_reestablish`]. + signer_pending_commitment_update: bool, + /// Similar to [`Self::signer_pending_commitment_update`] but we're waiting to send either a + /// [`msgs::FundingCreated`] or [`msgs::FundingSigned`] depending on if this channel is + /// outbound or inbound. + signer_pending_funding: bool, + // pending_update_fee is filled when sending and receiving update_fee. // // Because it follows the same commitment flow as HTLCs, `FeeUpdateState` is either `Outbound` @@ -709,18 +818,18 @@ pub(super) struct ChannelContext { #[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`. + /// If we remove an HTLC (or fee update), commit, and receive our counterparty's + /// `revoke_and_ack`, we remove all knowledge of said HTLC (or fee update). However, the latest + /// local commitment transaction that we can broadcast still contains the HTLC (or old fee) + /// until we receive a further `commitment_signed`. Thus we are not eligible for initiating the + /// `closing_signed` negotiation if we're expecting a counterparty `commitment_signed`. + /// + /// To ensure we don't send a `closing_signed` too early, we track this state here, waiting + /// until we see a `commitment_signed` before doing so. /// - /// 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, + /// We don't bother to persist this - we anticipate this state won't last longer than a few + /// milliseconds, so any accidental force-closes here should be exceedingly rare. + expecting_peer_commitment_signed: bool, /// The hash of the block in which the funding transaction was included. funding_tx_confirmed_in: Option, @@ -769,12 +878,13 @@ pub(super) struct ChannelContext { pub(crate) channel_transaction_parameters: ChannelTransactionParameters, funding_transaction: Option, + is_batch_funding: Option<()>, counterparty_cur_commitment_point: Option, counterparty_prev_commitment_point: Option, counterparty_node_id: PublicKey, - counterparty_shutdown_scriptpubkey: Option