Allow passing funding inputs when manually accepting a dual-funded channel

We introduce a `ChannelManager::accept_inbound_channel_with_contribution`
method allowing contributing to the overall channel capacity of an inbound
dual-funded channel by contributing inputs.

Author: dunxen

lightning/src/ln/channel.rs

@@ -14103,22 +14103,22 @@ where
 
 	/// Creates a new dual-funded channel from a remote side's request for one.
 	/// Assumes chain_hash has already been checked and corresponds with what we expect!
-	/// TODO(dual_funding): Allow contributions, pass intended amount and inputs
 	#[allow(dead_code)] // TODO(dual_funding): Remove once V2 channels is enabled.
 	#[rustfmt::skip]
 	pub fn new_inbound<ES: Deref, F: Deref, L: Deref>(
 		fee_estimator: &LowerBoundedFeeEstimator<F>, entropy_source: &ES, signer_provider: &SP,
 		holder_node_id: PublicKey, counterparty_node_id: PublicKey, our_supported_features: &ChannelTypeFeatures,
-		their_features: &InitFeatures, msg: &msgs::OpenChannelV2,
-		user_id: u128, config: &UserConfig, current_chain_height: u32, logger: &L,
+		their_features: &InitFeatures, msg: &msgs::OpenChannelV2, user_id: u128, config: &UserConfig,
+		current_chain_height: u32, logger: &L, our_funding_contribution_sats: u64,
+		our_funding_inputs: Vec<FundingTxInput>,
 	) -> Result<Self, ChannelError>
 		where ES::Target: EntropySource,
 			  F::Target: FeeEstimator,
 			  L::Target: Logger,
 	{
-		// TODO(dual_funding): Take these as input once supported
-		let (our_funding_contribution, our_funding_contribution_sats) = (SignedAmount::ZERO, 0u64);
-		let our_funding_inputs = Vec::new();
+		// This u64 -> i64 cast is safe as `our_funding_contribution_sats` is bounded above by the total
+		// bitcoin supply, which is far less than i64::MAX.
+		let our_funding_contribution = SignedAmount::from_sat(our_funding_contribution_sats as i64);
 
 		let channel_value_satoshis =
 			our_funding_contribution_sats.saturating_add(msg.common_fields.funding_satoshis);

lightning/src/ln/channelmanager.rs

@@ -62,10 +62,10 @@ use crate::ln::channel::{
 	self, hold_time_since, Channel, ChannelError, ChannelUpdateStatus, DisconnectResult,
 	FundedChannel, FundingTxSigned, InboundV1Channel, OutboundV1Channel, PendingV2Channel,
 	ReconnectionMsg, ShutdownResult, SpliceFundingFailed, StfuResponse, UpdateFulfillCommitFetch,
-	WithChannelContext,
+	WithChannelContext, TOTAL_BITCOIN_SUPPLY_SATOSHIS,
 };
 use crate::ln::channel_state::ChannelDetails;
-use crate::ln::funding::SpliceContribution;
+use crate::ln::funding::{FundingTxInput, SpliceContribution};
 use crate::ln::inbound_payment;
 use crate::ln::interactivetxs::InteractiveTxMessageSend;
 use crate::ln::msgs;
@@ -9814,6 +9814,8 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
 			false,
 			user_channel_id,
 			config_overrides,
+			0,
+			vec![],
 		)
 	}
 
@@ -9845,15 +9847,71 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
 			true,
 			user_channel_id,
 			config_overrides,
+			0,
+			vec![],
+		)
+	}
+
+	/// Accepts a request to open a dual-funded channel with a contribution provided by us after an
+	/// [`Event::OpenChannelRequest`].
+	///
+	/// The [`Event::OpenChannelRequest::channel_negotiation_type`] field will indicate the open channel
+	/// request is for a dual-funded channel when the variant is `InboundChannelFunds::DualFunded`.
+	///
+	/// The `temporary_channel_id` parameter indicates which inbound channel should be accepted,
+	/// and the `counterparty_node_id` parameter is the id of the peer which has requested to open
+	/// the channel.
+	///
+	/// The `user_channel_id` parameter will be provided back in
+	/// [`Event::ChannelClosed::user_channel_id`] to allow tracking of which events correspond
+	/// with which `accept_inbound_channel_*` call.
+	///
+	/// The `funding_inputs` parameter provides the `txin`s along with their previous transactions, and
+	/// a corresponding witness weight for each input that will be used to contribute towards our
+	/// portion of the channel value. Our contribution will be calculated as the total value of these
+	/// inputs minus the fees we need to cover for the interactive funding transaction. The witness
+	/// weights must correspond to the witnesses you will provide through [`ChannelManager::funding_transaction_signed`]
+	/// after receiving [`Event::FundingTransactionReadyForSigning`].
+	///
+	/// Note that this method will return an error and reject the channel if it requires support for
+	/// zero confirmations.
+	// TODO(dual_funding): Discussion on complications with 0conf dual-funded channels where "locking"
+	// of UTXOs used for funding would be required and other issues.
+	// See https://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/lightning-dev/2023-May/003922.txt
+	///
+	/// [`Event::OpenChannelRequest`]: events::Event::OpenChannelRequest
+	/// [`Event::OpenChannelRequest::channel_negotiation_type`]: events::Event::OpenChannelRequest::channel_negotiation_type
+	/// [`Event::ChannelClosed::user_channel_id`]: events::Event::ChannelClosed::user_channel_id
+	/// [`Event::FundingTransactionReadyForSigning`]: events::Event::FundingTransactionReadyForSigning
+	/// [`ChannelManager::funding_transaction_signed`]: ChannelManager::funding_transaction_signed
+	pub fn accept_inbound_channel_with_contribution(
+		&self, temporary_channel_id: &ChannelId, counterparty_node_id: &PublicKey,
+		user_channel_id: u128, config_overrides: Option<ChannelConfigOverrides>,
+		our_funding_satoshis: u64, funding_inputs: Vec<FundingTxInput>,
+	) -> Result<(), APIError> {
+		self.do_accept_inbound_channel(
+			temporary_channel_id,
+			counterparty_node_id,
+			false,
+			user_channel_id,
+			config_overrides,
+			our_funding_satoshis,
+			funding_inputs,
 		)
 	}
 
 	/// TODO(dual_funding): Allow contributions, pass intended amount and inputs
 	#[rustfmt::skip]
 	fn do_accept_inbound_channel(
 		&self, temporary_channel_id: &ChannelId, counterparty_node_id: &PublicKey, accept_0conf: bool,
-		user_channel_id: u128, config_overrides: Option<ChannelConfigOverrides>
+		user_channel_id: u128, config_overrides: Option<ChannelConfigOverrides>, our_funding_satoshis: u64,
+		funding_inputs: Vec<FundingTxInput>
 	) -> Result<(), APIError> {
+		// We do this check early as we will cast this to i64 for the NegotiationContext, and this is the
+		// actual upper bound which is less than i64::MAX.
+		if our_funding_satoshis >= TOTAL_BITCOIN_SUPPLY_SATOSHIS {
+			return Err(APIError::APIMisuseError{err: format!("the funding contribution must be smaller than the total bitcoin supply, it was {} satoshis", our_funding_satoshis)});
+		}
 
 		let mut config = self.config.read().unwrap().clone();
 
@@ -9911,7 +9969,7 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
 							&self.channel_type_features(), &peer_state.latest_features,
 							&open_channel_msg,
 							user_channel_id, &config, best_block_height,
-							&self.logger,
+							&self.logger, our_funding_satoshis, funding_inputs,
 						).map_err(|e| {
 							let channel_id = open_channel_msg.common_fields.temporary_channel_id;
 							MsgHandleErrInternal::from_chan_no_close(e, channel_id)
@@ -10197,7 +10255,7 @@ This indicates a bug inside LDK. Please report this error at https://github.com/
 					&self.fee_estimator, &self.entropy_source, &self.signer_provider,
 					self.get_our_node_id(), *counterparty_node_id, &self.channel_type_features(),
 					&peer_state.latest_features, msg, user_channel_id,
-					&self.config.read().unwrap(), best_block_height, &self.logger,
+					&self.config.read().unwrap(), best_block_height, &self.logger, 0, vec![],
 				).map_err(|e| MsgHandleErrInternal::from_chan_no_close(e, msg.common_fields.temporary_channel_id))?;
 				let message_send_event = MessageSendEvent::SendAcceptChannelV2 {
 					node_id: *counterparty_node_id,

lightning/src/ln/interactivetxs.rs

@@ -2320,6 +2320,11 @@ impl InteractiveTxConstructor {
 /// given inputs and outputs, and intended contribution. Takes into account the fees and the dust
 /// limit.
 ///
+/// Note that since the type of change output cannot be determined at this point, this calculation
+/// does not account for the weight contributed by the change output itself. The fees for the
+/// weight of this change output should be subtracted from the result of this function call to get
+/// the final amount for the change output (if above dust).
+///
 /// Three outcomes are possible:
 /// - Inputs are sufficient for intended contribution, fees, and a larger-than-dust change:
 ///   `Ok(Some(change_amount))`