Introduce `FundingTransactionReadyForSignatures` event #3889

dunxen · 2025-06-24T12:12:50Z

Cherry-picked from #3735 as it is relevant to splicing and will unblock testing after #3736 lands.

The FundingTransactionReadyForSignatures event requests witnesses from the client for their contributed inputs to an interactively constructed transaction.

The client calls ChannelManager::funding_transaction_signed to provide the witnesses to LDK.

ldk-reviews-bot · 2025-06-24T12:12:52Z

👋 Thanks for assigning @wpaulino as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

lightning/src/events/mod.rs

lightning/src/ln/channelmanager.rs

lightning/src/ln/interactivetxs.rs

codecov · 2025-06-25T11:08:53Z

Codecov Report

❌ Patch coverage is 69.07563% with 184 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.80%. Comparing base (bb48bbc) to head (de9d375).
⚠️ Report is 28 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/interactivetxs.rs	81.41%	77 Missing and 10 partials ⚠️
lightning/src/ln/channelmanager.rs	6.17%	73 Missing and 3 partials ⚠️
lightning/src/ln/channel.rs	55.55%	20 Missing ⚠️
lightning/src/events/mod.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3889      +/-   ##
==========================================
- Coverage   88.93%   88.80%   -0.13%     
==========================================
  Files         174      174              
  Lines      123875   124733     +858     
  Branches   123875   124733     +858     
==========================================
+ Hits       110169   110771     +602     
- Misses      11253    11468     +215     
- Partials     2453     2494      +41

Flag	Coverage Δ
fuzzing	`22.52% <1.36%> (+0.34%)`	⬆️
tests	`88.63% <69.07%> (-0.13%)`	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

ldk-reviews-bot · 2025-06-26T12:13:27Z

🔔 1st Reminder

Hey @wpaulino @optout21! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-06-26T12:13:29Z

🔔 1st Reminder

Hey @wpaulino @optout21! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

optout21

Looks good!

lightning/src/ln/channel.rs

ldk-reviews-bot · 2025-06-28T12:14:21Z

🔔 2nd Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-06-30T12:15:10Z

🔔 3rd Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

jkczyz

Not sure if there was a problem rebasing, but some comments that had been marked resolved weren't fixed.

lightning/src/events/mod.rs

lightning/src/ln/channelmanager.rs

lightning/src/events/mod.rs

dunxen · 2025-07-01T08:08:04Z

Not sure if there was a problem rebasing, but some comments that had been marked resolved weren't fixed.

Yeah, they got lost on a rebase and somehow lost the commit. Rebased to get the one CI fix in. Fixing.

ldk-reviews-bot · 2025-07-02T12:15:51Z

🔔 4th Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-07-05T00:01:03Z

🔔 5th Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

ldk-reviews-bot · 2025-07-07T00:01:47Z

🔔 6th Reminder

Hey @wpaulino! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

lightning/src/events/mod.rs

lightning/src/ln/channel.rs

lightning/src/events/mod.rs

lightning/src/ln/channel.rs

lightning/src/ln/channelmanager.rs

lightning/src/ln/interactivetxs.rs

lightning/src/ln/channel.rs

dunxen

Pushed latest fixups. Comments left on remaining ones.

lightning/src/ln/channel.rs

lightning/src/ln/channelmanager.rs

lightning/src/ln/interactivetxs.rs

lightning/src/ln/channelmanager.rs

lightning/src/ln/channel.rs

wpaulino

Almost there, the commit history could be cleaned up a bit to not have code added in one commit that gets removed in a later one

lightning/src/ln/interactivetxs.rs

lightning/src/events/mod.rs

lightning/src/ln/channel.rs

lightning/src/ln/channelmanager.rs

lightning/src/ln/channel.rs

dunxen · 2025-07-29T07:51:29Z

Almost there, the commit history could be cleaned up a bit to not have code added in one commit that gets removed in a later one

Thanks, I did intend to avoid that but I definitely lost track of the changes.

lightning/src/ln/channel.rs

lightning/src/ln/channelmanager.rs

lightning/src/ln/channel.rs

lightning/src/ln/channelmanager.rs

lightning/src/ln/channel.rs

lightning/src/ln/interactivetxs.rs

lightning/src/events/mod.rs

ldk-reviews-bot · 2025-07-30T09:02:45Z

🔔 1st Reminder

Hey @jkczyz! This PR has been waiting for your review.
Please take a look when you have a chance. If you're unable to review, please let us know so we can find another reviewer.

The `FundingTransactionReadyForSignatures` event requests witnesses from the client for their contributed inputs to an interactively constructed transaction. The client calls `ChannelManager::funding_transaction_signed` to provide the witnesses to LDK. The `handle_channel_resumption` method handles resumption from both a channel re-establish and a monitor update. When the corresponding monitor update for the commitment_signed message completes, we will push the event here. We can thus only ever provide holder signatures after a monitor update has completed. We can also get rid of the reestablish code involved with `monitor_pending_tx_signatures` and remove that field too.

…hecks In a following commit, We'll use the contained scriptPubKeys to validate P2WPKH and P2TR key path spends and to assist in checking that signatures in provided holder witnesses use SIGHASH_ALL to prevent funds being frozen or held ransom.

LDK checks the following: * Each input spends an output that is one of P2WPKH, P2WSH, or P2TR. These were already checked by LDK when the inputs to be contributed were provided. * All signatures use the `SIGHASH_ALL` sighash type. * P2WPKH and P2TR key path spends are valid (verifies signatures) NOTE: * When checking P2WSH spends, LDK tries to decode 70-72 byte witness elements as ECDSA signatures with a sighash flag. If the internal DER-decoding fails, then LDK just assumes it wasn't a signature and carries with checks. If the element can be decoded as an ECDSA signature, the the sighash flag must be `SIGHASH_ALL`. * When checking P2TR script-path spends, LDK assumes all elements of exactly 65 bytes with the last byte matching any valid sighash flag byte are schnorr signatures and checks that the sighash type is `SIGHASH_ALL`. If the last byte is not any valid sighash flag, the element is assumed not to be a signature and is ignored. Elements of 64 bytes are not checked because if they were schnorr signatures then they would implicitly be `SIGHASH_DEFAULT` which is an alias of `SIGHASH_ALL`.

wpaulino · 2025-07-31T21:19:56Z

lightning/src/ln/channel.rs

@@ -6856,13 +6810,12 @@ where
 			channel_id: Some(self.context.channel_id()),
 		};

-		let tx_signatures = self
+		let _ = self


Suggested change

let _ = self

self

Since this now returns void, it's best to ignore the return value completely. Otherwise, if the return parameter changes, rustc won't complain about it.

Good catch. Thanks!

wpaulino · 2025-07-31T21:29:31Z

lightning/src/ln/channel.rs

-				return Ok((None, None));
-			}
-
+			// Note that `holder_tx_signatures_opt` will be `None` if we sent `tx_signatures` first or if the


We should remove the TODOs about verifying witnesses above, also the input count check seems redundant as it's already checked in received_tx_signatures.

wpaulino · 2025-07-31T21:32:36Z

lightning/src/ln/channel.rs

-			if holder_tx_signatures_opt.is_some() && self.is_awaiting_initial_mon_persist() {
-				log_debug!(logger, "Not sending tx_signatures: a monitor update is in progress. Setting monitor_pending_tx_signatures.");
-				self.context.monitor_pending_tx_signatures = holder_tx_signatures_opt;
-				return Ok((None, None));


We used to return early if holder_tx_signatures wasn't ready, but now we don't and immediately transition to AwaitingChannelReady. Also this state isn't applicable for splicing, we'd want to go back to ChannelReady, but I guess that could be left for follow-up work.

Should we add a TODO(splicing) here?

Seems I lost a check here when I was working on testing.

Will add a TODO for splicing.

wpaulino · 2025-07-31T21:33:27Z

lightning/src/ln/channel.rs

-				}
-				return Err(());
-			};
+		let commitment_signed = if let Ok(update) = self.send_commitment_no_state_update(logger) {


Unrelated rustfmt change snuck in?

wpaulino · 2025-07-31T21:34:12Z

lightning/src/ln/channel.rs

-									self.context.monitor_pending_tx_signatures = session.holder_tx_signatures().clone();
-								}
+							if session.holder_tx_signatures().is_none() {
+								debug_assert!(self.context.channel_state.is_monitor_update_in_progress());


Sorry this was my mistake, we actually can't guarantee this, similar to the other debug_assert we dealt with.

No worries. Thanks, I think I just forgot to remove this one too.

wpaulino · 2025-07-31T21:52:40Z

lightning/src/ln/interactivetxs.rs

+				'elements: for element in witness {
+					match element.len() {
+						// Possibly a DER-encoded ECDSA signature with a sighash type byte assuming low-S
+						70..=72 => {


Shouldn't it be 73 max to account for the sighash flag itself? Would be nice to have coverage of all lengths.

Ah right, 72 bytes is actually high-r and low-s which is standard. So should be 73 here.
Thanks!

wpaulino · 2025-07-31T21:56:56Z

lightning/src/ln/interactivetxs.rs

+			]),
+			// P2WSH (Swept lightning anchor)
+			Witness::from_slice(&[
+				&vec![], // empty
+				&<Vec<u8>>::from_hex("2102fd481d39bdbc090313b530fddfd1aa004a9e3263da1406cf806670fdeb8ebb91ac736460b268").unwrap(),
+			]),
+			// P2WSH (Swept lightning anchor)
+			Witness::from_slice(&[
+				&vec![], // empty
+				&<Vec<u8>>::from_hex("2102fd481d39bdbc090313b530fddfd1aa004a9e3263da1406cf806670fdeb8ebb91ac736460b268").unwrap(),


Why are these repeated?

The real transaction I found had 3 identical spending conditions for lightning anchor sweeps.

wpaulino · 2025-07-31T21:57:13Z

lightning/src/ln/interactivetxs.rs

+				&<Vec<u8>>::from_hex("30440220036e88464b21c8bd819d97ae746622da00053ec1374a932f33aa1ab60170c9da022041cabc146ebdd12f6316a2f72f870771e8e6ff51f3cadad4027eab2e4437701101").unwrap(),
+				&<Vec<u8>>::from_hex("030c7196376bc1df61b6da6ee711868fd30e370dd273332bfb02a2287d11e2e9c5").unwrap(),
+			]),
+			// P2WSH (Swept lightning anchor)


We should also include one that has a signature.

wpaulino · 2025-07-31T21:58:29Z

lightning/src/ln/interactivetxs.rs

+		}];
+
+		let outputs: Vec<InteractiveTxOutput> = vec![
+			InteractiveTxOutput {


Nit: one output should be enough, no need to make the test longer than it needs to be

I grabbed real transactions and their signatures from on-chain. I could probably construct them myself if you'd like?

wpaulino · 2025-07-31T21:59:13Z

lightning/src/ln/interactivetxs.rs

@@ -3095,4 +3277,331 @@ mod tests {
 			assert_eq!(res, Ok(Some(262)));
 		}
 	}
+
+	#[test]
+	fn test_verify_tx_signatures_p2tr() {


This seems to be testing more than just P2TR.

Right, I think handcrafting the transactions and actually creating sigs would be better than trying to find test candidates from on chain.

Please be sure to include remote inputs in any handcrafted transactions to ensure the index pairing it correct after filtering remote inputs (looks like it is correct). AFAICT, the NegotiatedTxInputs below are only for one party, so we never test that the correct input_idx is passed to the cache.

jkczyz

Need to review the last commit still.

jkczyz · 2025-08-01T02:43:49Z

lightning/src/events/mod.rs

+	/// The transaction contains all inputs provided by both parties along with the channel's funding
+	/// output and a change output if applicable.


This may contain outputs added during interactive construction, too.

jkczyz · 2025-08-01T02:45:15Z

lightning/src/events/mod.rs

+	/// [`ChannelManager`]: crate::ln::channelmanager::ChannelManager
+	/// [`ChannelManager::funding_transaction_signed`]: crate::ln::channelmanager::ChannelManager::funding_transaction_signed
+	FundingTransactionReadyForSigning {
+		/// The channel_id of the channel which you'll need to pass back into


Add ticks to channel_id

jkczyz · 2025-08-01T02:45:32Z

lightning/src/events/mod.rs

+		///
+		/// [`ChannelManager::funding_transaction_signed`]: crate::ln::channelmanager::ChannelManager::funding_transaction_signed
+		channel_id: ChannelId,
+		/// The counterparty's node_id, which you'll need to pass back into


Likewise for node_id.

jkczyz · 2025-08-01T02:50:57Z

lightning/src/ln/channel.rs

-			// so they'll be sent as soon as that's done.
-			self.context.monitor_pending_tx_signatures = Some(tx_signatures);
-		}
+		self.interactive_tx_signing_session.as_mut().map(|session| session.received_commitment_signed());


Could we use if let instead of obscuring the a side effect in map?

Sure! Sorry, terrible habit of mine mixing mutability in functional methods.

jkczyz · 2025-08-01T03:03:58Z

lightning/src/ln/channelmanager.rs

+							},
+							Err(err) => {
+								result = Err(err);
+								return notify;


Is there a need for notify or can we just use an explicit return of a NotifyOption everywhere? Doesn't look like any code is executed later.

You're right. Can just return the literal here.

jkczyz · 2025-08-01T03:11:20Z

lightning/src/ln/channel.rs

+			.as_mut()
+			.ok_or_else(|| APIError::APIMisuseError {
+				err: format!(
+					"Channel with id {} not expecting funding signatures",


Let's just say "Channel {} not expecting funding signatures

jkczyz · 2025-08-01T03:13:26Z

lightning/src/ln/channelmanager.rs

+					}, None));
+			} else if signing_session.local_inputs_count() == 0 {
+				match signing_session.provide_holder_witnesses(channel.context.channel_id(), vec![]) {
+					Ok(Some(tx_signatures)) => pending_msg_events.push(MessageSendEvent::SendTxSignatures { node_id: counterparty_node_id, msg: tx_signatures }),


Would it make sense to call FundedChannel::funding_transaction_signed (or refactor part of that code) so the setting is all in one place?

jkczyz · 2025-08-01T03:18:38Z

lightning/src/ln/channelmanager.rs

+					Ok(None) => debug_assert!(false, "If our tx_signatures is empty, then we should send it first!"),
+					Err(_) => debug_assert!(
+						false,
+						"Zero inputs were provided & zero witnesses were provided, but a count mismatch was somehow found",


Suggested change

"Zero inputs were provided & zero witnesses were provided, but a count mismatch was somehow found",

"Zero inputs and witnesses were provided, but a count mismatch was somehow found",

jkczyz · 2025-08-01T03:21:24Z

lightning/src/ln/channel.rs

-			if holder_tx_signatures_opt.is_some() && self.is_awaiting_initial_mon_persist() {
-				log_debug!(logger, "Not sending tx_signatures: a monitor update is in progress. Setting monitor_pending_tx_signatures.");
-				self.context.monitor_pending_tx_signatures = holder_tx_signatures_opt;
-				return Ok((None, None));


Should we add a TODO(splicing) here?

dunxen

Appreciate the review!

Reworking the PR now.

dunxen · 2025-08-01T10:33:04Z

lightning/src/ln/interactivetxs.rs

+			]),
+			// P2WSH (Swept lightning anchor)
+			Witness::from_slice(&[
+				&vec![], // empty
+				&<Vec<u8>>::from_hex("2102fd481d39bdbc090313b530fddfd1aa004a9e3263da1406cf806670fdeb8ebb91ac736460b268").unwrap(),
+			]),
+			// P2WSH (Swept lightning anchor)
+			Witness::from_slice(&[
+				&vec![], // empty
+				&<Vec<u8>>::from_hex("2102fd481d39bdbc090313b530fddfd1aa004a9e3263da1406cf806670fdeb8ebb91ac736460b268").unwrap(),


The real transaction I found had 3 identical spending conditions for lightning anchor sweeps.

dunxen · 2025-08-01T10:33:12Z

lightning/src/ln/interactivetxs.rs

+		}];
+
+		let outputs: Vec<InteractiveTxOutput> = vec![
+			InteractiveTxOutput {


I grabbed real transactions and their signatures from on-chain. I could probably construct them myself if you'd like?

dunxen · 2025-08-01T10:38:39Z

lightning/src/ln/interactivetxs.rs

+				'elements: for element in witness {
+					match element.len() {
+						// Possibly a DER-encoded ECDSA signature with a sighash type byte assuming low-S
+						70..=72 => {


Ah right, 72 bytes is actually high-r and low-s which is standard. So should be 73 here.
Thanks!

dunxen · 2025-08-01T10:40:25Z

lightning/src/ln/interactivetxs.rs

@@ -3095,4 +3277,331 @@ mod tests {
 			assert_eq!(res, Ok(Some(262)));
 		}
 	}
+
+	#[test]
+	fn test_verify_tx_signatures_p2tr() {


Right, I think handcrafting the transactions and actually creating sigs would be better than trying to find test candidates from on chain.

dunxen · 2025-08-01T10:44:42Z

lightning/src/ln/channel.rs

-			// so they'll be sent as soon as that's done.
-			self.context.monitor_pending_tx_signatures = Some(tx_signatures);
-		}
+		self.interactive_tx_signing_session.as_mut().map(|session| session.received_commitment_signed());


Sure! Sorry, terrible habit of mine mixing mutability in functional methods.

dunxen · 2025-08-01T10:45:17Z

lightning/src/ln/channel.rs

@@ -6856,13 +6810,12 @@ where
 			channel_id: Some(self.context.channel_id()),
 		};

-		let tx_signatures = self
+		let _ = self


Good catch. Thanks!

dunxen · 2025-08-01T10:47:55Z

lightning/src/ln/channel.rs

-			if holder_tx_signatures_opt.is_some() && self.is_awaiting_initial_mon_persist() {
-				log_debug!(logger, "Not sending tx_signatures: a monitor update is in progress. Setting monitor_pending_tx_signatures.");
-				self.context.monitor_pending_tx_signatures = holder_tx_signatures_opt;
-				return Ok((None, None));


Seems I lost a check here when I was working on testing.

Will add a TODO for splicing.

dunxen · 2025-08-01T10:48:30Z

lightning/src/ln/channel.rs

-									self.context.monitor_pending_tx_signatures = session.holder_tx_signatures().clone();
-								}
+							if session.holder_tx_signatures().is_none() {
+								debug_assert!(self.context.channel_state.is_monitor_update_in_progress());


No worries. Thanks, I think I just forgot to remove this one too.

dunxen · 2025-08-01T10:49:21Z

lightning/src/ln/channelmanager.rs

+							.filter_map(|input| {
+								if input.witness.is_empty() {
+									None
+								} else {
+									Some(input.witness)
+								}
+							})


Lol duh! thanks :)

dunxen · 2025-08-01T10:49:51Z

lightning/src/ln/channelmanager.rs

+							},
+							Err(err) => {
+								result = Err(err);
+								return notify;


You're right. Can just return the literal here.

jkczyz · 2025-08-01T16:29:41Z

lightning/src/ln/interactivetxs.rs

+	fn prev_output(&self) -> &TxOut {
+		match self {
+			InputOwned::Single(single) => &single.prev_output,
+			InputOwned::Shared(shared) => &shared.prev_output,
+		}
+	}


Looks like this is never used.

jkczyz · 2025-08-01T16:32:08Z

lightning/src/ln/interactivetxs.rs

@@ -363,6 +379,10 @@ impl ConstructedTransaction {
 			.zip(witnesses)
 			.for_each(|(input, witness)| input.witness = witness);
 	}
+
+	pub fn holder_is_initiator(&self) -> bool {


Doesn't need to be pub.

jkczyz · 2025-08-01T17:12:09Z

lightning/src/ln/interactivetxs.rs

+					APIError::APIMisuseError { err }
+				})?;
+
+				continue 'inputs;


Consider using helper functions instead of using labeled continues.

jkczyz · 2025-08-01T17:39:24Z

lightning/src/ln/interactivetxs.rs

+
+			// P2WSH - No validation just sighash checks
+			if script_pubkey.is_p2wsh() {
+				'elements: for element in witness {


Are these labels even necessary if you never continue to an outer loop?

jkczyz · 2025-08-01T17:39:50Z

lightning/src/ln/interactivetxs.rs

+							let err = format!("An ECDSA signature in the witness for input {input_idx} does not use SIGHASH_ALL");
+							return Err(APIError::APIMisuseError { err });
+						},
+						_ => continue 'elements,


Not needed.

jkczyz · 2025-08-01T17:40:25Z

lightning/src/ln/interactivetxs.rs

+								.map(|sig| matches!(sig.sighash_type, EcdsaSighashType::All))
+								.unwrap_or(true)
+							{
+								continue 'elements;


Negate the condition to avoid needing a continue.

jkczyz · 2025-08-01T17:46:18Z

lightning/src/ln/interactivetxs.rs

@@ -3095,4 +3277,331 @@ mod tests {
 			assert_eq!(res, Ok(Some(262)));
 		}
 	}
+
+	#[test]
+	fn test_verify_tx_signatures_p2tr() {


Please be sure to include remote inputs in any handcrafted transactions to ensure the index pairing it correct after filtering remote inputs (looks like it is correct). AFAICT, the NegotiatedTxInputs below are only for one party, so we never test that the correct input_idx is passed to the cache.

dunxen added Dual-funding Splicing labels Jun 24, 2025

dunxen requested review from wpaulino, optout21 and jkczyz June 24, 2025 12:13

jkczyz reviewed Jun 24, 2025

View reviewed changes

dunxen mentioned this pull request Jun 25, 2025

Contribute funding inputs on accepting dual-funded channel #3735

Draft

dunxen force-pushed the 2025-06-readyforsigningevent branch from 165d59d to 8ca6d79 Compare June 25, 2025 10:59

optout21 reviewed Jun 26, 2025

View reviewed changes

dunxen force-pushed the 2025-06-readyforsigningevent branch from 890633d to a1de384 Compare June 27, 2025 07:20

jkczyz reviewed Jun 27, 2025

View reviewed changes

lightning/src/ln/channel.rs Outdated Show resolved Hide resolved

dunxen force-pushed the 2025-06-readyforsigningevent branch 2 times, most recently from 7df5779 to c8f981c Compare June 30, 2025 10:29

jkczyz reviewed Jun 30, 2025

View reviewed changes

dunxen force-pushed the 2025-06-readyforsigningevent branch 2 times, most recently from c15f426 to ff1489d Compare July 1, 2025 09:18

dunxen force-pushed the 2025-06-readyforsigningevent branch from ff1489d to 0a586e6 Compare July 4, 2025 07:05

wpaulino reviewed Jul 7, 2025

View reviewed changes

dunxen force-pushed the 2025-06-readyforsigningevent branch 2 times, most recently from a9e1a3a to 83e78d6 Compare July 14, 2025 09:34

wpaulino reviewed Jul 17, 2025

View reviewed changes

dunxen force-pushed the 2025-06-readyforsigningevent branch from b161cba to 4dde88e Compare July 21, 2025 17:56

dunxen commented Jul 21, 2025

View reviewed changes

lightning/src/ln/channel.rs Outdated Show resolved Hide resolved

lightning/src/ln/channelmanager.rs Outdated Show resolved Hide resolved

dunxen force-pushed the 2025-06-readyforsigningevent branch 2 times, most recently from 58b5381 to 50e7cf4 Compare July 23, 2025 13:45

wpaulino reviewed Jul 23, 2025

View reviewed changes

dunxen force-pushed the 2025-06-readyforsigningevent branch 2 times, most recently from ca2d5e0 to b45913a Compare July 28, 2025 09:01

dunxen requested review from wpaulino and jkczyz July 28, 2025 09:02

wpaulino reviewed Jul 28, 2025

View reviewed changes

dunxen force-pushed the 2025-06-readyforsigningevent branch 2 times, most recently from e518bd2 to 0dbc64f Compare July 29, 2025 12:43

wpaulino reviewed Jul 29, 2025

View reviewed changes

dunxen force-pushed the 2025-06-readyforsigningevent branch 5 times, most recently from 0b377f9 to 07e3526 Compare July 30, 2025 20:50

dunxen added 3 commits July 31, 2025 09:57

dunxen force-pushed the 2025-06-readyforsigningevent branch from 07e3526 to de9d375 Compare July 31, 2025 07:57

dunxen requested a review from wpaulino July 31, 2025 11:36

wpaulino reviewed Jul 31, 2025

View reviewed changes

jkczyz reviewed Aug 1, 2025

View reviewed changes

dunxen commented Aug 1, 2025

View reviewed changes

jkczyz reviewed Aug 1, 2025

View reviewed changes

		/// The transaction contains all inputs provided by both parties along with the channel's funding
		/// output and a change output if applicable.

	"Zero inputs were provided & zero witnesses were provided, but a count mismatch was somehow found",
	"Zero inputs and witnesses were provided, but a count mismatch was somehow found",

Introduce FundingTransactionReadyForSignatures event #3889

Are you sure you want to change the base?

Introduce FundingTransactionReadyForSignatures event #3889

Uh oh!

Conversation

dunxen commented Jun 24, 2025

Uh oh!

ldk-reviews-bot commented Jun 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

codecov bot commented Jun 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

ldk-reviews-bot commented Jun 26, 2025

Uh oh!

ldk-reviews-bot commented Jun 26, 2025

Uh oh!

optout21 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ldk-reviews-bot commented Jun 28, 2025

Uh oh!

ldk-reviews-bot commented Jun 30, 2025

Uh oh!

jkczyz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dunxen commented Jul 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ldk-reviews-bot commented Jul 2, 2025

Uh oh!

ldk-reviews-bot commented Jul 5, 2025

Uh oh!

ldk-reviews-bot commented Jul 7, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dunxen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

wpaulino left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Introduce `FundingTransactionReadyForSignatures` event #3889

Introduce `FundingTransactionReadyForSignatures` event #3889

ldk-reviews-bot commented Jun 24, 2025 •

edited

Loading

codecov bot commented Jun 25, 2025 •

edited

Loading

dunxen commented Jul 1, 2025 •

edited

Loading