Rework ChannelManager::funding_transaction_signed by wpaulino · Pull Request #4257 · lightningdevkit/rust-lightning

wpaulino · 2025-12-03T18:47:11Z

Previously, we'd emit a FundingTransactionReadyForSigning event once the initial commitment_signed is exchanged for a splicing/dual-funding attempt and require users to call back with their signed inputs using ChannelManager::funding_transaction_signed. While this approach worked in practice, it prevents us from abandoning a splice if we cannot or no longer wish to sign as the splice has already been committed to by this point.

This commit reworks the API such that this is now possible. After exchanging tx_complete, we will no longer immediately send our initial commitment_signed. We will now emit the
FundingTransactionReadyForSigning event and wait for the user to call back before releasing both our initial commitment_signed and our tx_signatures. As a result, the event is now persisted, as there is only one possible path in which it is generated. Note that we continue to only emit the event if a local contribution to negotiated transaction was made.

Future work will expose a cancellation API such that we can abandon splice attempts safely (we can just force close the channel with dual-funding).

ldk-reviews-bot · 2025-12-03T18:47:15Z

👋 Thanks for assigning @jkczyz 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.

codecov · 2025-12-03T21:05:54Z

Codecov Report

❌ Patch coverage is 74.49664% with 76 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.60%. Comparing base (c5d7b13) to head (e502ce3).
⚠️ Report is 30 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channel.rs	81.32%	23 Missing and 8 partials ⚠️
lightning/src/ln/splicing_tests.rs	0.00%	23 Missing ⚠️
lightning/src/ln/channelmanager.rs	78.02%	18 Missing and 2 partials ⚠️
lightning/src/events/mod.rs	87.50%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4257 +/- ##
==========================================
+ Coverage 86.59% 86.60% +0.01% 
==========================================
Files 158 158 Lines 102368 102376 +8 Branches 102368 102376 +8 ==========================================
+ Hits 88641 88659 +18 + Misses 11313 11297 -16 - Partials 2414 2420 +6

Flag	Coverage Δ
fuzzing	`36.99% <16.77%> (+0.05%)`	⬆️
tests	`85.89% <80.72%> (+0.01%)`	⬆️

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-12-06T00:01:01Z

🔔 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.

ldk-reviews-bot · 2025-12-08T00:01:49Z

🔔 2nd 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.

jkczyz · 2025-12-08T21:42:59Z

- Some(channel) => match channel.as_funded_mut() {
- Some(chan) => {


IIUC, we can write a FundingTransactionReadyForSigning for dual funding, but upon restart the channel will be forgotten as it will still be considered pending. So calling funding_transaction_signed will fail in that case. Is this a problem? Or should we at least note this in the docs?

Added a note in the docs that it can happen

ldk-reviews-bot · 2025-12-08T22:51:53Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2026-01-07T22:37:19Z

+ // TODO(splicing): Support async signing
+ .ok_or("Failed to compute commitment_signed signatures".to_owned())?;


Ha, I thought you said this was supporting async signing :p

TheBlueMatt · 2026-01-08T15:41:47Z

+ ));
+ }
+ if channel.context().is_connected() {
+ if let Some(commit_sig) = commit_sig {


Can you add a test that checks that we avoid sending the commit sigs here if the funding_transaction_signed call comes in before the monitor is persisted (async)?

We can actually send our commit sig immediately after funding_transaction_signed, there's no reason to wait for the monitor persist to complete first. We just have to make sure we don't process a counterparty one before it completes.

Previously, we'd emit a `FundingTransactionReadyForSigning` event once the initial `commitment_signed` is exchanged for a splicing/dual-funding attempt and require users to call back with their signed inputs using `ChannelManager::funding_transaction_signed`. While this approach worked in practice, it prevents us from abandoning a splice if we cannot or no longer wish to sign as the splice has already been committed to by this point. This commit reworks the API such that this is now possible. After exchanging `tx_complete`, we will no longer immediately send our initial `commitment_signed`. We will now emit the `FundingTransactionReadyForSigning` event and wait for the user to call back before releasing both our initial `commitment_signed` and our `tx_signatures`. As a result, the event is now persisted, as there is only one possible path in which it is generated. Note that we continue to only emit the event if a local contribution to negotiated transaction was made. Future work will expose a cancellation API such that we can abandon splice attempts safely (we can just force close the channel with dual-funding).

We delay processing it until the user manually approves the splice via `Channel::funding_transaction_signed`, as otherwise, there would be a [`ChannelMonitorUpdateStep::RenegotiatedFunding`] committed that we would need to undo if they no longer wish to proceed. Note that this doesn't need to be done with dual-funded channels as there is no equivalent monitor update for them.

TheBlueMatt · 2026-01-16T19:15:31Z

+ ref unsigned_transaction,
+ } => {
+ 48u8.write(writer)?;
+ write_tlv_fields!(writer, {


Bleh, I'm really not a fan of this. We're really trying hard to write less in ChannelManager right now, it would be really nice to automatically regenerate this on startup if were in a state where we're waiting on the user to sign a funding tx.

It's only generated in one place (internal_tx_complete) where we already incur a write, so it shouldn't matter?

Less about I/O and more about what happens if we don't write a ChannelManager at all.

TheBlueMatt · 2026-01-16T19:33:49Z

+
+ // Handling a monitor update requires dropping peer state locks, so we use the labeled loop
+ // as a goto statement.
+ 'peer_loop: loop {


FWIW I'm also pretty unexcited for yet more loops over all the peers and channels (especially that might change channel state and commit monitors!) called from get_and_clear_pending_msg_events. Somewhat less urgently cause obviously this already exists, but get_and_clear_pending_msg_events is really supposed to be super responsive and quick, and monitors absolutely wreck that. Is there really no way to pass messages back when we're ready to generate them rather than in a separate caller called every millisecond?

I initially had it as part of ChannelManager::funding_transaction_signed, but I wasn't happy with it there due to the two possible error paths: an APIError due to user API misuse, and a ChannelError while processing things that could result in a force close. I can give it another go if you'd like to see how that looks, otherwise this logic needs to live somewhere that happens shortly after without user and counterparty interaction. Two other candidates could be get_and_clear_pending_events and timer_tick_occurred (but this might not be ideal given we're under quiescence if we just missed the tick).

I initially had it as part of ChannelManager::funding_transaction_signed, but I wasn't happy with it there due to the two possible error paths: an APIError due to user API misuse, and a ChannelError while processing things that could result in a force close. I can give it another go if you'd like to see how that looks, otherwise this logic needs to live somewhere that happens shortly after without user and counterparty interaction.
Even if its a bit messy that does seem better - delaying message fetching for a sync monitor update isn't ideal :/
Two other candidates could be get_and_clear_pending_events and timer_tick_occurred (but this might not be ideal given we're under quiescence if we just missed the tick).
Nah, I think get_and_clear_pending_msg_events would be better, I mean we do wipe the holding cell in there already, so its not like its great...tho I'm currently looking to see how easy it is to remove...

ldk-reviews-bot · 2026-01-19T00:00:20Z

🔔 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.

TheBlueMatt

ldk-node needs an update pr now.

TheBlueMatt · 2026-01-20T21:47:24Z

Gah FFS. I thought I had the #4261 tab open...I did not. I accidentally hit merge on this and had to force-push it back. Sorry about that. I guess github now mandates a new PR 😭

wpaulino · 2025-12-03T18:47:11Z

Previously, we'd emit a FundingTransactionReadyForSigning event once the initial commitment_signed is exchanged for a splicing/dual-funding attempt and require users to call back with their signed inputs using ChannelManager::funding_transaction_signed. While this approach worked in practice, it prevents us from abandoning a splice if we cannot or no longer wish to sign as the splice has already been committed to by this point.

This commit reworks the API such that this is now possible. After exchanging tx_complete, we will no longer immediately send our initial commitment_signed. We will now emit the
FundingTransactionReadyForSigning event and wait for the user to call back before releasing both our initial commitment_signed and our tx_signatures. As a result, the event is now persisted, as there is only one possible path in which it is generated. Note that we continue to only emit the event if a local contribution to negotiated transaction was made.

Future work will expose a cancellation API such that we can abandon splice attempts safely (we can just force close the channel with dual-funding).

ldk-reviews-bot · 2025-12-03T18:47:15Z

👋 Thanks for assigning @jkczyz 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.

codecov · 2025-12-03T21:05:54Z

Codecov Report

❌ Patch coverage is 74.49664% with 76 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.60%. Comparing base (c5d7b13) to head (e502ce3).
⚠️ Report is 30 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channel.rs	81.32%	23 Missing and 8 partials ⚠️
lightning/src/ln/splicing_tests.rs	0.00%	23 Missing ⚠️
lightning/src/ln/channelmanager.rs	78.02%	18 Missing and 2 partials ⚠️
lightning/src/events/mod.rs	87.50%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4257 +/- ##
==========================================
+ Coverage 86.59% 86.60% +0.01% 
==========================================
Files 158 158 Lines 102368 102376 +8 Branches 102368 102376 +8 ==========================================
+ Hits 88641 88659 +18 + Misses 11313 11297 -16 - Partials 2414 2420 +6

Flag	Coverage Δ
fuzzing	`36.99% <16.77%> (+0.05%)`	⬆️
tests	`85.89% <80.72%> (+0.01%)`	⬆️

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-12-06T00:01:01Z

🔔 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.

ldk-reviews-bot · 2025-12-08T00:01:49Z

🔔 2nd 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.

jkczyz · 2025-12-08T21:42:59Z

- Some(channel) => match channel.as_funded_mut() {
- Some(chan) => {


IIUC, we can write a FundingTransactionReadyForSigning for dual funding, but upon restart the channel will be forgotten as it will still be considered pending. So calling funding_transaction_signed will fail in that case. Is this a problem? Or should we at least note this in the docs?

Added a note in the docs that it can happen

ldk-reviews-bot · 2025-12-08T22:51:53Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2026-01-07T22:37:19Z

+ // TODO(splicing): Support async signing
+ .ok_or("Failed to compute commitment_signed signatures".to_owned())?;


Ha, I thought you said this was supporting async signing :p

TheBlueMatt · 2026-01-08T15:41:47Z

+ ));
+ }
+ if channel.context().is_connected() {
+ if let Some(commit_sig) = commit_sig {


Can you add a test that checks that we avoid sending the commit sigs here if the funding_transaction_signed call comes in before the monitor is persisted (async)?

We can actually send our commit sig immediately after funding_transaction_signed, there's no reason to wait for the monitor persist to complete first. We just have to make sure we don't process a counterparty one before it completes.

Previously, we'd emit a `FundingTransactionReadyForSigning` event once the initial `commitment_signed` is exchanged for a splicing/dual-funding attempt and require users to call back with their signed inputs using `ChannelManager::funding_transaction_signed`. While this approach worked in practice, it prevents us from abandoning a splice if we cannot or no longer wish to sign as the splice has already been committed to by this point. This commit reworks the API such that this is now possible. After exchanging `tx_complete`, we will no longer immediately send our initial `commitment_signed`. We will now emit the `FundingTransactionReadyForSigning` event and wait for the user to call back before releasing both our initial `commitment_signed` and our `tx_signatures`. As a result, the event is now persisted, as there is only one possible path in which it is generated. Note that we continue to only emit the event if a local contribution to negotiated transaction was made. Future work will expose a cancellation API such that we can abandon splice attempts safely (we can just force close the channel with dual-funding).

We delay processing it until the user manually approves the splice via `Channel::funding_transaction_signed`, as otherwise, there would be a [`ChannelMonitorUpdateStep::RenegotiatedFunding`] committed that we would need to undo if they no longer wish to proceed. Note that this doesn't need to be done with dual-funded channels as there is no equivalent monitor update for them.

TheBlueMatt · 2026-01-16T19:15:31Z

+ ref unsigned_transaction,
+ } => {
+ 48u8.write(writer)?;
+ write_tlv_fields!(writer, {


Bleh, I'm really not a fan of this. We're really trying hard to write less in ChannelManager right now, it would be really nice to automatically regenerate this on startup if were in a state where we're waiting on the user to sign a funding tx.

It's only generated in one place (internal_tx_complete) where we already incur a write, so it shouldn't matter?

Less about I/O and more about what happens if we don't write a ChannelManager at all.

TheBlueMatt · 2026-01-16T19:33:49Z

+
+ // Handling a monitor update requires dropping peer state locks, so we use the labeled loop
+ // as a goto statement.
+ 'peer_loop: loop {


FWIW I'm also pretty unexcited for yet more loops over all the peers and channels (especially that might change channel state and commit monitors!) called from get_and_clear_pending_msg_events. Somewhat less urgently cause obviously this already exists, but get_and_clear_pending_msg_events is really supposed to be super responsive and quick, and monitors absolutely wreck that. Is there really no way to pass messages back when we're ready to generate them rather than in a separate caller called every millisecond?

I initially had it as part of ChannelManager::funding_transaction_signed, but I wasn't happy with it there due to the two possible error paths: an APIError due to user API misuse, and a ChannelError while processing things that could result in a force close. I can give it another go if you'd like to see how that looks, otherwise this logic needs to live somewhere that happens shortly after without user and counterparty interaction. Two other candidates could be get_and_clear_pending_events and timer_tick_occurred (but this might not be ideal given we're under quiescence if we just missed the tick).

I initially had it as part of ChannelManager::funding_transaction_signed, but I wasn't happy with it there due to the two possible error paths: an APIError due to user API misuse, and a ChannelError while processing things that could result in a force close. I can give it another go if you'd like to see how that looks, otherwise this logic needs to live somewhere that happens shortly after without user and counterparty interaction.
Even if its a bit messy that does seem better - delaying message fetching for a sync monitor update isn't ideal :/
Two other candidates could be get_and_clear_pending_events and timer_tick_occurred (but this might not be ideal given we're under quiescence if we just missed the tick).
Nah, I think get_and_clear_pending_msg_events would be better, I mean we do wipe the holding cell in there already, so its not like its great...tho I'm currently looking to see how easy it is to remove...

ldk-reviews-bot · 2026-01-19T00:00:20Z

🔔 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.

TheBlueMatt

ldk-node needs an update pr now.

TheBlueMatt · 2026-01-20T21:47:24Z

Gah FFS. I thought I had the #4261 tab open...I did not. I accidentally hit merge on this and had to force-push it back. Sorry about that. I guess github now mandates a new PR 😭

wpaulino · 2025-12-03T18:47:11Z

Previously, we'd emit a FundingTransactionReadyForSigning event once the initial commitment_signed is exchanged for a splicing/dual-funding attempt and require users to call back with their signed inputs using ChannelManager::funding_transaction_signed. While this approach worked in practice, it prevents us from abandoning a splice if we cannot or no longer wish to sign as the splice has already been committed to by this point.

This commit reworks the API such that this is now possible. After exchanging tx_complete, we will no longer immediately send our initial commitment_signed. We will now emit the
FundingTransactionReadyForSigning event and wait for the user to call back before releasing both our initial commitment_signed and our tx_signatures. As a result, the event is now persisted, as there is only one possible path in which it is generated. Note that we continue to only emit the event if a local contribution to negotiated transaction was made.

Future work will expose a cancellation API such that we can abandon splice attempts safely (we can just force close the channel with dual-funding).

ldk-reviews-bot · 2025-12-03T18:47:15Z

👋 Thanks for assigning @jkczyz 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.

codecov · 2025-12-03T21:05:54Z

Codecov Report

❌ Patch coverage is 74.49664% with 76 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.60%. Comparing base (c5d7b13) to head (e502ce3).
⚠️ Report is 30 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channel.rs	81.32%	23 Missing and 8 partials ⚠️
lightning/src/ln/splicing_tests.rs	0.00%	23 Missing ⚠️
lightning/src/ln/channelmanager.rs	78.02%	18 Missing and 2 partials ⚠️
lightning/src/events/mod.rs	87.50%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4257 +/- ##
==========================================
+ Coverage 86.59% 86.60% +0.01% 
==========================================
Files 158 158 Lines 102368 102376 +8 Branches 102368 102376 +8 ==========================================
+ Hits 88641 88659 +18 + Misses 11313 11297 -16 - Partials 2414 2420 +6

Flag	Coverage Δ
fuzzing	`36.99% <16.77%> (+0.05%)`	⬆️
tests	`85.89% <80.72%> (+0.01%)`	⬆️

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-12-06T00:01:01Z

🔔 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.

ldk-reviews-bot · 2025-12-08T00:01:49Z

🔔 2nd 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.

jkczyz · 2025-12-08T21:42:59Z

- Some(channel) => match channel.as_funded_mut() {
- Some(chan) => {


IIUC, we can write a FundingTransactionReadyForSigning for dual funding, but upon restart the channel will be forgotten as it will still be considered pending. So calling funding_transaction_signed will fail in that case. Is this a problem? Or should we at least note this in the docs?

Added a note in the docs that it can happen

ldk-reviews-bot · 2025-12-08T22:51:53Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2026-01-07T22:37:19Z

+ // TODO(splicing): Support async signing
+ .ok_or("Failed to compute commitment_signed signatures".to_owned())?;


Ha, I thought you said this was supporting async signing :p

TheBlueMatt · 2026-01-08T15:41:47Z

+ ));
+ }
+ if channel.context().is_connected() {
+ if let Some(commit_sig) = commit_sig {


Can you add a test that checks that we avoid sending the commit sigs here if the funding_transaction_signed call comes in before the monitor is persisted (async)?

We can actually send our commit sig immediately after funding_transaction_signed, there's no reason to wait for the monitor persist to complete first. We just have to make sure we don't process a counterparty one before it completes.

Previously, we'd emit a `FundingTransactionReadyForSigning` event once the initial `commitment_signed` is exchanged for a splicing/dual-funding attempt and require users to call back with their signed inputs using `ChannelManager::funding_transaction_signed`. While this approach worked in practice, it prevents us from abandoning a splice if we cannot or no longer wish to sign as the splice has already been committed to by this point. This commit reworks the API such that this is now possible. After exchanging `tx_complete`, we will no longer immediately send our initial `commitment_signed`. We will now emit the `FundingTransactionReadyForSigning` event and wait for the user to call back before releasing both our initial `commitment_signed` and our `tx_signatures`. As a result, the event is now persisted, as there is only one possible path in which it is generated. Note that we continue to only emit the event if a local contribution to negotiated transaction was made. Future work will expose a cancellation API such that we can abandon splice attempts safely (we can just force close the channel with dual-funding).

We delay processing it until the user manually approves the splice via `Channel::funding_transaction_signed`, as otherwise, there would be a [`ChannelMonitorUpdateStep::RenegotiatedFunding`] committed that we would need to undo if they no longer wish to proceed. Note that this doesn't need to be done with dual-funded channels as there is no equivalent monitor update for them.

TheBlueMatt · 2026-01-16T19:15:31Z

+ ref unsigned_transaction,
+ } => {
+ 48u8.write(writer)?;
+ write_tlv_fields!(writer, {


Bleh, I'm really not a fan of this. We're really trying hard to write less in ChannelManager right now, it would be really nice to automatically regenerate this on startup if were in a state where we're waiting on the user to sign a funding tx.

It's only generated in one place (internal_tx_complete) where we already incur a write, so it shouldn't matter?

Less about I/O and more about what happens if we don't write a ChannelManager at all.

TheBlueMatt · 2026-01-16T19:33:49Z

+
+ // Handling a monitor update requires dropping peer state locks, so we use the labeled loop
+ // as a goto statement.
+ 'peer_loop: loop {


FWIW I'm also pretty unexcited for yet more loops over all the peers and channels (especially that might change channel state and commit monitors!) called from get_and_clear_pending_msg_events. Somewhat less urgently cause obviously this already exists, but get_and_clear_pending_msg_events is really supposed to be super responsive and quick, and monitors absolutely wreck that. Is there really no way to pass messages back when we're ready to generate them rather than in a separate caller called every millisecond?

I initially had it as part of ChannelManager::funding_transaction_signed, but I wasn't happy with it there due to the two possible error paths: an APIError due to user API misuse, and a ChannelError while processing things that could result in a force close. I can give it another go if you'd like to see how that looks, otherwise this logic needs to live somewhere that happens shortly after without user and counterparty interaction. Two other candidates could be get_and_clear_pending_events and timer_tick_occurred (but this might not be ideal given we're under quiescence if we just missed the tick).

I initially had it as part of ChannelManager::funding_transaction_signed, but I wasn't happy with it there due to the two possible error paths: an APIError due to user API misuse, and a ChannelError while processing things that could result in a force close. I can give it another go if you'd like to see how that looks, otherwise this logic needs to live somewhere that happens shortly after without user and counterparty interaction.
Even if its a bit messy that does seem better - delaying message fetching for a sync monitor update isn't ideal :/
Two other candidates could be get_and_clear_pending_events and timer_tick_occurred (but this might not be ideal given we're under quiescence if we just missed the tick).
Nah, I think get_and_clear_pending_msg_events would be better, I mean we do wipe the holding cell in there already, so its not like its great...tho I'm currently looking to see how easy it is to remove...

ldk-reviews-bot · 2026-01-19T00:00:20Z

🔔 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.

TheBlueMatt

ldk-node needs an update pr now.

TheBlueMatt · 2026-01-20T21:47:24Z

Gah FFS. I thought I had the #4261 tab open...I did not. I accidentally hit merge on this and had to force-push it back. Sorry about that. I guess github now mandates a new PR 😭

wpaulino · 2025-12-03T18:47:11Z

Previously, we'd emit a FundingTransactionReadyForSigning event once the initial commitment_signed is exchanged for a splicing/dual-funding attempt and require users to call back with their signed inputs using ChannelManager::funding_transaction_signed. While this approach worked in practice, it prevents us from abandoning a splice if we cannot or no longer wish to sign as the splice has already been committed to by this point.

This commit reworks the API such that this is now possible. After exchanging tx_complete, we will no longer immediately send our initial commitment_signed. We will now emit the
FundingTransactionReadyForSigning event and wait for the user to call back before releasing both our initial commitment_signed and our tx_signatures. As a result, the event is now persisted, as there is only one possible path in which it is generated. Note that we continue to only emit the event if a local contribution to negotiated transaction was made.

Future work will expose a cancellation API such that we can abandon splice attempts safely (we can just force close the channel with dual-funding).

ldk-reviews-bot · 2025-12-03T18:47:15Z

👋 Thanks for assigning @jkczyz 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.

codecov · 2025-12-03T21:05:54Z

Codecov Report

❌ Patch coverage is 74.49664% with 76 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.60%. Comparing base (c5d7b13) to head (e502ce3).
⚠️ Report is 30 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channel.rs	81.32%	23 Missing and 8 partials ⚠️
lightning/src/ln/splicing_tests.rs	0.00%	23 Missing ⚠️
lightning/src/ln/channelmanager.rs	78.02%	18 Missing and 2 partials ⚠️
lightning/src/events/mod.rs	87.50%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4257 +/- ##
==========================================
+ Coverage 86.59% 86.60% +0.01% 
==========================================
Files 158 158 Lines 102368 102376 +8 Branches 102368 102376 +8 ==========================================
+ Hits 88641 88659 +18 + Misses 11313 11297 -16 - Partials 2414 2420 +6

Flag	Coverage Δ
fuzzing	`36.99% <16.77%> (+0.05%)`	⬆️
tests	`85.89% <80.72%> (+0.01%)`	⬆️

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-12-06T00:01:01Z

🔔 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.

ldk-reviews-bot · 2025-12-08T00:01:49Z

🔔 2nd 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.

jkczyz · 2025-12-08T21:42:59Z

- Some(channel) => match channel.as_funded_mut() {
- Some(chan) => {


IIUC, we can write a FundingTransactionReadyForSigning for dual funding, but upon restart the channel will be forgotten as it will still be considered pending. So calling funding_transaction_signed will fail in that case. Is this a problem? Or should we at least note this in the docs?

Added a note in the docs that it can happen

ldk-reviews-bot · 2025-12-08T22:51:53Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2026-01-07T22:37:19Z

+ // TODO(splicing): Support async signing
+ .ok_or("Failed to compute commitment_signed signatures".to_owned())?;


Ha, I thought you said this was supporting async signing :p

TheBlueMatt · 2026-01-08T15:41:47Z

+ ));
+ }
+ if channel.context().is_connected() {
+ if let Some(commit_sig) = commit_sig {


Can you add a test that checks that we avoid sending the commit sigs here if the funding_transaction_signed call comes in before the monitor is persisted (async)?

We can actually send our commit sig immediately after funding_transaction_signed, there's no reason to wait for the monitor persist to complete first. We just have to make sure we don't process a counterparty one before it completes.

Previously, we'd emit a `FundingTransactionReadyForSigning` event once the initial `commitment_signed` is exchanged for a splicing/dual-funding attempt and require users to call back with their signed inputs using `ChannelManager::funding_transaction_signed`. While this approach worked in practice, it prevents us from abandoning a splice if we cannot or no longer wish to sign as the splice has already been committed to by this point. This commit reworks the API such that this is now possible. After exchanging `tx_complete`, we will no longer immediately send our initial `commitment_signed`. We will now emit the `FundingTransactionReadyForSigning` event and wait for the user to call back before releasing both our initial `commitment_signed` and our `tx_signatures`. As a result, the event is now persisted, as there is only one possible path in which it is generated. Note that we continue to only emit the event if a local contribution to negotiated transaction was made. Future work will expose a cancellation API such that we can abandon splice attempts safely (we can just force close the channel with dual-funding).

We delay processing it until the user manually approves the splice via `Channel::funding_transaction_signed`, as otherwise, there would be a [`ChannelMonitorUpdateStep::RenegotiatedFunding`] committed that we would need to undo if they no longer wish to proceed. Note that this doesn't need to be done with dual-funded channels as there is no equivalent monitor update for them.

TheBlueMatt · 2026-01-16T19:15:31Z

+ ref unsigned_transaction,
+ } => {
+ 48u8.write(writer)?;
+ write_tlv_fields!(writer, {


Bleh, I'm really not a fan of this. We're really trying hard to write less in ChannelManager right now, it would be really nice to automatically regenerate this on startup if were in a state where we're waiting on the user to sign a funding tx.

It's only generated in one place (internal_tx_complete) where we already incur a write, so it shouldn't matter?

Less about I/O and more about what happens if we don't write a ChannelManager at all.

TheBlueMatt · 2026-01-16T19:33:49Z

+
+ // Handling a monitor update requires dropping peer state locks, so we use the labeled loop
+ // as a goto statement.
+ 'peer_loop: loop {


FWIW I'm also pretty unexcited for yet more loops over all the peers and channels (especially that might change channel state and commit monitors!) called from get_and_clear_pending_msg_events. Somewhat less urgently cause obviously this already exists, but get_and_clear_pending_msg_events is really supposed to be super responsive and quick, and monitors absolutely wreck that. Is there really no way to pass messages back when we're ready to generate them rather than in a separate caller called every millisecond?

I initially had it as part of ChannelManager::funding_transaction_signed, but I wasn't happy with it there due to the two possible error paths: an APIError due to user API misuse, and a ChannelError while processing things that could result in a force close. I can give it another go if you'd like to see how that looks, otherwise this logic needs to live somewhere that happens shortly after without user and counterparty interaction. Two other candidates could be get_and_clear_pending_events and timer_tick_occurred (but this might not be ideal given we're under quiescence if we just missed the tick).

I initially had it as part of ChannelManager::funding_transaction_signed, but I wasn't happy with it there due to the two possible error paths: an APIError due to user API misuse, and a ChannelError while processing things that could result in a force close. I can give it another go if you'd like to see how that looks, otherwise this logic needs to live somewhere that happens shortly after without user and counterparty interaction.
Even if its a bit messy that does seem better - delaying message fetching for a sync monitor update isn't ideal :/
Two other candidates could be get_and_clear_pending_events and timer_tick_occurred (but this might not be ideal given we're under quiescence if we just missed the tick).
Nah, I think get_and_clear_pending_msg_events would be better, I mean we do wipe the holding cell in there already, so its not like its great...tho I'm currently looking to see how easy it is to remove...

ldk-reviews-bot · 2026-01-19T00:00:20Z

🔔 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.

TheBlueMatt

ldk-node needs an update pr now.

TheBlueMatt · 2026-01-20T21:47:24Z

Gah FFS. I thought I had the #4261 tab open...I did not. I accidentally hit merge on this and had to force-push it back. Sorry about that. I guess github now mandates a new PR 😭

wpaulino · 2025-12-03T18:47:11Z

Previously, we'd emit a FundingTransactionReadyForSigning event once the initial commitment_signed is exchanged for a splicing/dual-funding attempt and require users to call back with their signed inputs using ChannelManager::funding_transaction_signed. While this approach worked in practice, it prevents us from abandoning a splice if we cannot or no longer wish to sign as the splice has already been committed to by this point.

This commit reworks the API such that this is now possible. After exchanging tx_complete, we will no longer immediately send our initial commitment_signed. We will now emit the
FundingTransactionReadyForSigning event and wait for the user to call back before releasing both our initial commitment_signed and our tx_signatures. As a result, the event is now persisted, as there is only one possible path in which it is generated. Note that we continue to only emit the event if a local contribution to negotiated transaction was made.

Future work will expose a cancellation API such that we can abandon splice attempts safely (we can just force close the channel with dual-funding).

ldk-reviews-bot · 2025-12-03T18:47:15Z

👋 Thanks for assigning @jkczyz 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.

codecov · 2025-12-03T21:05:54Z

Codecov Report

❌ Patch coverage is 74.49664% with 76 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.60%. Comparing base (c5d7b13) to head (e502ce3).
⚠️ Report is 30 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channel.rs	81.32%	23 Missing and 8 partials ⚠️
lightning/src/ln/splicing_tests.rs	0.00%	23 Missing ⚠️
lightning/src/ln/channelmanager.rs	78.02%	18 Missing and 2 partials ⚠️
lightning/src/events/mod.rs	87.50%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4257 +/- ##
==========================================
+ Coverage 86.59% 86.60% +0.01% 
==========================================
Files 158 158 Lines 102368 102376 +8 Branches 102368 102376 +8 ==========================================
+ Hits 88641 88659 +18 + Misses 11313 11297 -16 - Partials 2414 2420 +6

Flag	Coverage Δ
fuzzing	`36.99% <16.77%> (+0.05%)`	⬆️
tests	`85.89% <80.72%> (+0.01%)`	⬆️

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-12-06T00:01:01Z

🔔 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.

ldk-reviews-bot · 2025-12-08T00:01:49Z

🔔 2nd 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.

jkczyz · 2025-12-08T21:42:59Z

- Some(channel) => match channel.as_funded_mut() {
- Some(chan) => {


IIUC, we can write a FundingTransactionReadyForSigning for dual funding, but upon restart the channel will be forgotten as it will still be considered pending. So calling funding_transaction_signed will fail in that case. Is this a problem? Or should we at least note this in the docs?

Added a note in the docs that it can happen

ldk-reviews-bot · 2025-12-08T22:51:53Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2026-01-07T22:37:19Z

+ // TODO(splicing): Support async signing
+ .ok_or("Failed to compute commitment_signed signatures".to_owned())?;


Ha, I thought you said this was supporting async signing :p

TheBlueMatt · 2026-01-08T15:41:47Z

+ ));
+ }
+ if channel.context().is_connected() {
+ if let Some(commit_sig) = commit_sig {


Can you add a test that checks that we avoid sending the commit sigs here if the funding_transaction_signed call comes in before the monitor is persisted (async)?

We can actually send our commit sig immediately after funding_transaction_signed, there's no reason to wait for the monitor persist to complete first. We just have to make sure we don't process a counterparty one before it completes.

Previously, we'd emit a `FundingTransactionReadyForSigning` event once the initial `commitment_signed` is exchanged for a splicing/dual-funding attempt and require users to call back with their signed inputs using `ChannelManager::funding_transaction_signed`. While this approach worked in practice, it prevents us from abandoning a splice if we cannot or no longer wish to sign as the splice has already been committed to by this point. This commit reworks the API such that this is now possible. After exchanging `tx_complete`, we will no longer immediately send our initial `commitment_signed`. We will now emit the `FundingTransactionReadyForSigning` event and wait for the user to call back before releasing both our initial `commitment_signed` and our `tx_signatures`. As a result, the event is now persisted, as there is only one possible path in which it is generated. Note that we continue to only emit the event if a local contribution to negotiated transaction was made. Future work will expose a cancellation API such that we can abandon splice attempts safely (we can just force close the channel with dual-funding).

We delay processing it until the user manually approves the splice via `Channel::funding_transaction_signed`, as otherwise, there would be a [`ChannelMonitorUpdateStep::RenegotiatedFunding`] committed that we would need to undo if they no longer wish to proceed. Note that this doesn't need to be done with dual-funded channels as there is no equivalent monitor update for them.

TheBlueMatt · 2026-01-16T19:15:31Z

+ ref unsigned_transaction,
+ } => {
+ 48u8.write(writer)?;
+ write_tlv_fields!(writer, {


Bleh, I'm really not a fan of this. We're really trying hard to write less in ChannelManager right now, it would be really nice to automatically regenerate this on startup if were in a state where we're waiting on the user to sign a funding tx.

It's only generated in one place (internal_tx_complete) where we already incur a write, so it shouldn't matter?

Less about I/O and more about what happens if we don't write a ChannelManager at all.

TheBlueMatt · 2026-01-16T19:33:49Z

+
+ // Handling a monitor update requires dropping peer state locks, so we use the labeled loop
+ // as a goto statement.
+ 'peer_loop: loop {


FWIW I'm also pretty unexcited for yet more loops over all the peers and channels (especially that might change channel state and commit monitors!) called from get_and_clear_pending_msg_events. Somewhat less urgently cause obviously this already exists, but get_and_clear_pending_msg_events is really supposed to be super responsive and quick, and monitors absolutely wreck that. Is there really no way to pass messages back when we're ready to generate them rather than in a separate caller called every millisecond?

I initially had it as part of ChannelManager::funding_transaction_signed, but I wasn't happy with it there due to the two possible error paths: an APIError due to user API misuse, and a ChannelError while processing things that could result in a force close. I can give it another go if you'd like to see how that looks, otherwise this logic needs to live somewhere that happens shortly after without user and counterparty interaction. Two other candidates could be get_and_clear_pending_events and timer_tick_occurred (but this might not be ideal given we're under quiescence if we just missed the tick).

I initially had it as part of ChannelManager::funding_transaction_signed, but I wasn't happy with it there due to the two possible error paths: an APIError due to user API misuse, and a ChannelError while processing things that could result in a force close. I can give it another go if you'd like to see how that looks, otherwise this logic needs to live somewhere that happens shortly after without user and counterparty interaction.
Even if its a bit messy that does seem better - delaying message fetching for a sync monitor update isn't ideal :/
Two other candidates could be get_and_clear_pending_events and timer_tick_occurred (but this might not be ideal given we're under quiescence if we just missed the tick).
Nah, I think get_and_clear_pending_msg_events would be better, I mean we do wipe the holding cell in there already, so its not like its great...tho I'm currently looking to see how easy it is to remove...

ldk-reviews-bot · 2026-01-19T00:00:20Z

🔔 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.

TheBlueMatt

ldk-node needs an update pr now.

TheBlueMatt · 2026-01-20T21:47:24Z

Gah FFS. I thought I had the #4261 tab open...I did not. I accidentally hit merge on this and had to force-push it back. Sorry about that. I guess github now mandates a new PR 😭

wpaulino · 2025-12-03T18:47:11Z

Previously, we'd emit a FundingTransactionReadyForSigning event once the initial commitment_signed is exchanged for a splicing/dual-funding attempt and require users to call back with their signed inputs using ChannelManager::funding_transaction_signed. While this approach worked in practice, it prevents us from abandoning a splice if we cannot or no longer wish to sign as the splice has already been committed to by this point.

This commit reworks the API such that this is now possible. After exchanging tx_complete, we will no longer immediately send our initial commitment_signed. We will now emit the
FundingTransactionReadyForSigning event and wait for the user to call back before releasing both our initial commitment_signed and our tx_signatures. As a result, the event is now persisted, as there is only one possible path in which it is generated. Note that we continue to only emit the event if a local contribution to negotiated transaction was made.

Future work will expose a cancellation API such that we can abandon splice attempts safely (we can just force close the channel with dual-funding).

ldk-reviews-bot · 2025-12-03T18:47:15Z

👋 Thanks for assigning @jkczyz 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.

codecov · 2025-12-03T21:05:54Z

Codecov Report

❌ Patch coverage is 74.49664% with 76 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.60%. Comparing base (c5d7b13) to head (e502ce3).
⚠️ Report is 30 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channel.rs	81.32%	23 Missing and 8 partials ⚠️
lightning/src/ln/splicing_tests.rs	0.00%	23 Missing ⚠️
lightning/src/ln/channelmanager.rs	78.02%	18 Missing and 2 partials ⚠️
lightning/src/events/mod.rs	87.50%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4257 +/- ##
==========================================
+ Coverage 86.59% 86.60% +0.01% 
==========================================
Files 158 158 Lines 102368 102376 +8 Branches 102368 102376 +8 ==========================================
+ Hits 88641 88659 +18 + Misses 11313 11297 -16 - Partials 2414 2420 +6

Flag	Coverage Δ
fuzzing	`36.99% <16.77%> (+0.05%)`	⬆️
tests	`85.89% <80.72%> (+0.01%)`	⬆️

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-12-06T00:01:01Z

🔔 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.

ldk-reviews-bot · 2025-12-08T00:01:49Z

🔔 2nd 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.

jkczyz · 2025-12-08T21:42:59Z

- Some(channel) => match channel.as_funded_mut() {
- Some(chan) => {


IIUC, we can write a FundingTransactionReadyForSigning for dual funding, but upon restart the channel will be forgotten as it will still be considered pending. So calling funding_transaction_signed will fail in that case. Is this a problem? Or should we at least note this in the docs?

Added a note in the docs that it can happen

ldk-reviews-bot · 2025-12-08T22:51:53Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2026-01-07T22:37:19Z

+ // TODO(splicing): Support async signing
+ .ok_or("Failed to compute commitment_signed signatures".to_owned())?;


Ha, I thought you said this was supporting async signing :p

TheBlueMatt · 2026-01-08T15:41:47Z

+ ));
+ }
+ if channel.context().is_connected() {
+ if let Some(commit_sig) = commit_sig {


Can you add a test that checks that we avoid sending the commit sigs here if the funding_transaction_signed call comes in before the monitor is persisted (async)?

We can actually send our commit sig immediately after funding_transaction_signed, there's no reason to wait for the monitor persist to complete first. We just have to make sure we don't process a counterparty one before it completes.

Previously, we'd emit a `FundingTransactionReadyForSigning` event once the initial `commitment_signed` is exchanged for a splicing/dual-funding attempt and require users to call back with their signed inputs using `ChannelManager::funding_transaction_signed`. While this approach worked in practice, it prevents us from abandoning a splice if we cannot or no longer wish to sign as the splice has already been committed to by this point. This commit reworks the API such that this is now possible. After exchanging `tx_complete`, we will no longer immediately send our initial `commitment_signed`. We will now emit the `FundingTransactionReadyForSigning` event and wait for the user to call back before releasing both our initial `commitment_signed` and our `tx_signatures`. As a result, the event is now persisted, as there is only one possible path in which it is generated. Note that we continue to only emit the event if a local contribution to negotiated transaction was made. Future work will expose a cancellation API such that we can abandon splice attempts safely (we can just force close the channel with dual-funding).

We delay processing it until the user manually approves the splice via `Channel::funding_transaction_signed`, as otherwise, there would be a [`ChannelMonitorUpdateStep::RenegotiatedFunding`] committed that we would need to undo if they no longer wish to proceed. Note that this doesn't need to be done with dual-funded channels as there is no equivalent monitor update for them.

TheBlueMatt · 2026-01-16T19:15:31Z

+ ref unsigned_transaction,
+ } => {
+ 48u8.write(writer)?;
+ write_tlv_fields!(writer, {


Bleh, I'm really not a fan of this. We're really trying hard to write less in ChannelManager right now, it would be really nice to automatically regenerate this on startup if were in a state where we're waiting on the user to sign a funding tx.

It's only generated in one place (internal_tx_complete) where we already incur a write, so it shouldn't matter?

Less about I/O and more about what happens if we don't write a ChannelManager at all.

TheBlueMatt · 2026-01-16T19:33:49Z

+
+ // Handling a monitor update requires dropping peer state locks, so we use the labeled loop
+ // as a goto statement.
+ 'peer_loop: loop {


FWIW I'm also pretty unexcited for yet more loops over all the peers and channels (especially that might change channel state and commit monitors!) called from get_and_clear_pending_msg_events. Somewhat less urgently cause obviously this already exists, but get_and_clear_pending_msg_events is really supposed to be super responsive and quick, and monitors absolutely wreck that. Is there really no way to pass messages back when we're ready to generate them rather than in a separate caller called every millisecond?

I initially had it as part of ChannelManager::funding_transaction_signed, but I wasn't happy with it there due to the two possible error paths: an APIError due to user API misuse, and a ChannelError while processing things that could result in a force close. I can give it another go if you'd like to see how that looks, otherwise this logic needs to live somewhere that happens shortly after without user and counterparty interaction. Two other candidates could be get_and_clear_pending_events and timer_tick_occurred (but this might not be ideal given we're under quiescence if we just missed the tick).

I initially had it as part of ChannelManager::funding_transaction_signed, but I wasn't happy with it there due to the two possible error paths: an APIError due to user API misuse, and a ChannelError while processing things that could result in a force close. I can give it another go if you'd like to see how that looks, otherwise this logic needs to live somewhere that happens shortly after without user and counterparty interaction.
Even if its a bit messy that does seem better - delaying message fetching for a sync monitor update isn't ideal :/
Two other candidates could be get_and_clear_pending_events and timer_tick_occurred (but this might not be ideal given we're under quiescence if we just missed the tick).
Nah, I think get_and_clear_pending_msg_events would be better, I mean we do wipe the holding cell in there already, so its not like its great...tho I'm currently looking to see how easy it is to remove...

ldk-reviews-bot · 2026-01-19T00:00:20Z

🔔 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.

TheBlueMatt

ldk-node needs an update pr now.

TheBlueMatt · 2026-01-20T21:47:24Z

Gah FFS. I thought I had the #4261 tab open...I did not. I accidentally hit merge on this and had to force-push it back. Sorry about that. I guess github now mandates a new PR 😭

wpaulino · 2025-12-03T18:47:11Z

Previously, we'd emit a FundingTransactionReadyForSigning event once the initial commitment_signed is exchanged for a splicing/dual-funding attempt and require users to call back with their signed inputs using ChannelManager::funding_transaction_signed. While this approach worked in practice, it prevents us from abandoning a splice if we cannot or no longer wish to sign as the splice has already been committed to by this point.

This commit reworks the API such that this is now possible. After exchanging tx_complete, we will no longer immediately send our initial commitment_signed. We will now emit the
FundingTransactionReadyForSigning event and wait for the user to call back before releasing both our initial commitment_signed and our tx_signatures. As a result, the event is now persisted, as there is only one possible path in which it is generated. Note that we continue to only emit the event if a local contribution to negotiated transaction was made.

Future work will expose a cancellation API such that we can abandon splice attempts safely (we can just force close the channel with dual-funding).

ldk-reviews-bot · 2025-12-03T18:47:15Z

👋 Thanks for assigning @jkczyz 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.

codecov · 2025-12-03T21:05:54Z

Codecov Report

❌ Patch coverage is 74.49664% with 76 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.60%. Comparing base (c5d7b13) to head (e502ce3).
⚠️ Report is 30 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channel.rs	81.32%	23 Missing and 8 partials ⚠️
lightning/src/ln/splicing_tests.rs	0.00%	23 Missing ⚠️
lightning/src/ln/channelmanager.rs	78.02%	18 Missing and 2 partials ⚠️
lightning/src/events/mod.rs	87.50%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4257 +/- ##
==========================================
+ Coverage 86.59% 86.60% +0.01% 
==========================================
Files 158 158 Lines 102368 102376 +8 Branches 102368 102376 +8 ==========================================
+ Hits 88641 88659 +18 + Misses 11313 11297 -16 - Partials 2414 2420 +6

Flag	Coverage Δ
fuzzing	`36.99% <16.77%> (+0.05%)`	⬆️
tests	`85.89% <80.72%> (+0.01%)`	⬆️

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-12-06T00:01:01Z

🔔 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.

ldk-reviews-bot · 2025-12-08T00:01:49Z

🔔 2nd 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.

jkczyz · 2025-12-08T21:42:59Z

- Some(channel) => match channel.as_funded_mut() {
- Some(chan) => {


IIUC, we can write a FundingTransactionReadyForSigning for dual funding, but upon restart the channel will be forgotten as it will still be considered pending. So calling funding_transaction_signed will fail in that case. Is this a problem? Or should we at least note this in the docs?

Added a note in the docs that it can happen

ldk-reviews-bot · 2025-12-08T22:51:53Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2026-01-07T22:37:19Z

+ // TODO(splicing): Support async signing
+ .ok_or("Failed to compute commitment_signed signatures".to_owned())?;


Ha, I thought you said this was supporting async signing :p

TheBlueMatt · 2026-01-08T15:41:47Z

+ ));
+ }
+ if channel.context().is_connected() {
+ if let Some(commit_sig) = commit_sig {


Can you add a test that checks that we avoid sending the commit sigs here if the funding_transaction_signed call comes in before the monitor is persisted (async)?

We can actually send our commit sig immediately after funding_transaction_signed, there's no reason to wait for the monitor persist to complete first. We just have to make sure we don't process a counterparty one before it completes.

Previously, we'd emit a `FundingTransactionReadyForSigning` event once the initial `commitment_signed` is exchanged for a splicing/dual-funding attempt and require users to call back with their signed inputs using `ChannelManager::funding_transaction_signed`. While this approach worked in practice, it prevents us from abandoning a splice if we cannot or no longer wish to sign as the splice has already been committed to by this point. This commit reworks the API such that this is now possible. After exchanging `tx_complete`, we will no longer immediately send our initial `commitment_signed`. We will now emit the `FundingTransactionReadyForSigning` event and wait for the user to call back before releasing both our initial `commitment_signed` and our `tx_signatures`. As a result, the event is now persisted, as there is only one possible path in which it is generated. Note that we continue to only emit the event if a local contribution to negotiated transaction was made. Future work will expose a cancellation API such that we can abandon splice attempts safely (we can just force close the channel with dual-funding).

We delay processing it until the user manually approves the splice via `Channel::funding_transaction_signed`, as otherwise, there would be a [`ChannelMonitorUpdateStep::RenegotiatedFunding`] committed that we would need to undo if they no longer wish to proceed. Note that this doesn't need to be done with dual-funded channels as there is no equivalent monitor update for them.

TheBlueMatt · 2026-01-16T19:15:31Z

+ ref unsigned_transaction,
+ } => {
+ 48u8.write(writer)?;
+ write_tlv_fields!(writer, {


Bleh, I'm really not a fan of this. We're really trying hard to write less in ChannelManager right now, it would be really nice to automatically regenerate this on startup if were in a state where we're waiting on the user to sign a funding tx.

It's only generated in one place (internal_tx_complete) where we already incur a write, so it shouldn't matter?

Less about I/O and more about what happens if we don't write a ChannelManager at all.

TheBlueMatt · 2026-01-16T19:33:49Z

+
+ // Handling a monitor update requires dropping peer state locks, so we use the labeled loop
+ // as a goto statement.
+ 'peer_loop: loop {


FWIW I'm also pretty unexcited for yet more loops over all the peers and channels (especially that might change channel state and commit monitors!) called from get_and_clear_pending_msg_events. Somewhat less urgently cause obviously this already exists, but get_and_clear_pending_msg_events is really supposed to be super responsive and quick, and monitors absolutely wreck that. Is there really no way to pass messages back when we're ready to generate them rather than in a separate caller called every millisecond?

I initially had it as part of ChannelManager::funding_transaction_signed, but I wasn't happy with it there due to the two possible error paths: an APIError due to user API misuse, and a ChannelError while processing things that could result in a force close. I can give it another go if you'd like to see how that looks, otherwise this logic needs to live somewhere that happens shortly after without user and counterparty interaction. Two other candidates could be get_and_clear_pending_events and timer_tick_occurred (but this might not be ideal given we're under quiescence if we just missed the tick).

I initially had it as part of ChannelManager::funding_transaction_signed, but I wasn't happy with it there due to the two possible error paths: an APIError due to user API misuse, and a ChannelError while processing things that could result in a force close. I can give it another go if you'd like to see how that looks, otherwise this logic needs to live somewhere that happens shortly after without user and counterparty interaction.
Even if its a bit messy that does seem better - delaying message fetching for a sync monitor update isn't ideal :/
Two other candidates could be get_and_clear_pending_events and timer_tick_occurred (but this might not be ideal given we're under quiescence if we just missed the tick).
Nah, I think get_and_clear_pending_msg_events would be better, I mean we do wipe the holding cell in there already, so its not like its great...tho I'm currently looking to see how easy it is to remove...

ldk-reviews-bot · 2026-01-19T00:00:20Z

🔔 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.

TheBlueMatt

ldk-node needs an update pr now.

TheBlueMatt · 2026-01-20T21:47:24Z

Gah FFS. I thought I had the #4261 tab open...I did not. I accidentally hit merge on this and had to force-push it back. Sorry about that. I guess github now mandates a new PR 😭

wpaulino · 2025-12-03T18:47:11Z

Previously, we'd emit a FundingTransactionReadyForSigning event once the initial commitment_signed is exchanged for a splicing/dual-funding attempt and require users to call back with their signed inputs using ChannelManager::funding_transaction_signed. While this approach worked in practice, it prevents us from abandoning a splice if we cannot or no longer wish to sign as the splice has already been committed to by this point.

This commit reworks the API such that this is now possible. After exchanging tx_complete, we will no longer immediately send our initial commitment_signed. We will now emit the
FundingTransactionReadyForSigning event and wait for the user to call back before releasing both our initial commitment_signed and our tx_signatures. As a result, the event is now persisted, as there is only one possible path in which it is generated. Note that we continue to only emit the event if a local contribution to negotiated transaction was made.

Future work will expose a cancellation API such that we can abandon splice attempts safely (we can just force close the channel with dual-funding).

ldk-reviews-bot · 2025-12-03T18:47:15Z

👋 Thanks for assigning @jkczyz 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.

codecov · 2025-12-03T21:05:54Z

Codecov Report

❌ Patch coverage is 74.49664% with 76 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.60%. Comparing base (c5d7b13) to head (e502ce3).
⚠️ Report is 30 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/channel.rs	81.32%	23 Missing and 8 partials ⚠️
lightning/src/ln/splicing_tests.rs	0.00%	23 Missing ⚠️
lightning/src/ln/channelmanager.rs	78.02%	18 Missing and 2 partials ⚠️
lightning/src/events/mod.rs	87.50%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@ Coverage Diff @@## main #4257 +/- ##
==========================================
+ Coverage 86.59% 86.60% +0.01% 
==========================================
Files 158 158 Lines 102368 102376 +8 Branches 102368 102376 +8 ==========================================
+ Hits 88641 88659 +18 + Misses 11313 11297 -16 - Partials 2414 2420 +6

Flag	Coverage Δ
fuzzing	`36.99% <16.77%> (+0.05%)`	⬆️
tests	`85.89% <80.72%> (+0.01%)`	⬆️

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-12-06T00:01:01Z

🔔 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.

ldk-reviews-bot · 2025-12-08T00:01:49Z

🔔 2nd 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.

jkczyz · 2025-12-08T21:42:59Z

- Some(channel) => match channel.as_funded_mut() {
- Some(chan) => {


IIUC, we can write a FundingTransactionReadyForSigning for dual funding, but upon restart the channel will be forgotten as it will still be considered pending. So calling funding_transaction_signed will fail in that case. Is this a problem? Or should we at least note this in the docs?

Added a note in the docs that it can happen

ldk-reviews-bot · 2025-12-08T22:51:53Z

👋 The first review has been submitted!

Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer.

TheBlueMatt · 2026-01-07T22:37:19Z

+ // TODO(splicing): Support async signing
+ .ok_or("Failed to compute commitment_signed signatures".to_owned())?;


Ha, I thought you said this was supporting async signing :p

TheBlueMatt · 2026-01-08T15:41:47Z

+ ));
+ }
+ if channel.context().is_connected() {
+ if let Some(commit_sig) = commit_sig {


Can you add a test that checks that we avoid sending the commit sigs here if the funding_transaction_signed call comes in before the monitor is persisted (async)?

We can actually send our commit sig immediately after funding_transaction_signed, there's no reason to wait for the monitor persist to complete first. We just have to make sure we don't process a counterparty one before it completes.

Previously, we'd emit a `FundingTransactionReadyForSigning` event once the initial `commitment_signed` is exchanged for a splicing/dual-funding attempt and require users to call back with their signed inputs using `ChannelManager::funding_transaction_signed`. While this approach worked in practice, it prevents us from abandoning a splice if we cannot or no longer wish to sign as the splice has already been committed to by this point. This commit reworks the API such that this is now possible. After exchanging `tx_complete`, we will no longer immediately send our initial `commitment_signed`. We will now emit the `FundingTransactionReadyForSigning` event and wait for the user to call back before releasing both our initial `commitment_signed` and our `tx_signatures`. As a result, the event is now persisted, as there is only one possible path in which it is generated. Note that we continue to only emit the event if a local contribution to negotiated transaction was made. Future work will expose a cancellation API such that we can abandon splice attempts safely (we can just force close the channel with dual-funding).

We delay processing it until the user manually approves the splice via `Channel::funding_transaction_signed`, as otherwise, there would be a [`ChannelMonitorUpdateStep::RenegotiatedFunding`] committed that we would need to undo if they no longer wish to proceed. Note that this doesn't need to be done with dual-funded channels as there is no equivalent monitor update for them.

TheBlueMatt · 2026-01-16T19:15:31Z

+ ref unsigned_transaction,
+ } => {
+ 48u8.write(writer)?;
+ write_tlv_fields!(writer, {


Bleh, I'm really not a fan of this. We're really trying hard to write less in ChannelManager right now, it would be really nice to automatically regenerate this on startup if were in a state where we're waiting on the user to sign a funding tx.

It's only generated in one place (internal_tx_complete) where we already incur a write, so it shouldn't matter?

Less about I/O and more about what happens if we don't write a ChannelManager at all.

TheBlueMatt · 2026-01-16T19:33:49Z

+
+ // Handling a monitor update requires dropping peer state locks, so we use the labeled loop
+ // as a goto statement.
+ 'peer_loop: loop {


FWIW I'm also pretty unexcited for yet more loops over all the peers and channels (especially that might change channel state and commit monitors!) called from get_and_clear_pending_msg_events. Somewhat less urgently cause obviously this already exists, but get_and_clear_pending_msg_events is really supposed to be super responsive and quick, and monitors absolutely wreck that. Is there really no way to pass messages back when we're ready to generate them rather than in a separate caller called every millisecond?

I initially had it as part of ChannelManager::funding_transaction_signed, but I wasn't happy with it there due to the two possible error paths: an APIError due to user API misuse, and a ChannelError while processing things that could result in a force close. I can give it another go if you'd like to see how that looks, otherwise this logic needs to live somewhere that happens shortly after without user and counterparty interaction. Two other candidates could be get_and_clear_pending_events and timer_tick_occurred (but this might not be ideal given we're under quiescence if we just missed the tick).

I initially had it as part of ChannelManager::funding_transaction_signed, but I wasn't happy with it there due to the two possible error paths: an APIError due to user API misuse, and a ChannelError while processing things that could result in a force close. I can give it another go if you'd like to see how that looks, otherwise this logic needs to live somewhere that happens shortly after without user and counterparty interaction.
Even if its a bit messy that does seem better - delaying message fetching for a sync monitor update isn't ideal :/
Two other candidates could be get_and_clear_pending_events and timer_tick_occurred (but this might not be ideal given we're under quiescence if we just missed the tick).
Nah, I think get_and_clear_pending_msg_events would be better, I mean we do wipe the holding cell in there already, so its not like its great...tho I'm currently looking to see how easy it is to remove...

ldk-reviews-bot · 2026-01-19T00:00:20Z

🔔 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.

TheBlueMatt

ldk-node needs an update pr now.

TheBlueMatt · 2026-01-20T21:47:24Z

Gah FFS. I thought I had the #4261 tab open...I did not. I accidentally hit merge on this and had to force-push it back. Sorry about that. I guess github now mandates a new PR 😭

wpaulino added this to the 0.3 milestone Dec 3, 2025

wpaulino requested a review from jkczyz December 3, 2025 18:47

wpaulino self-assigned this Dec 3, 2025

wpaulino force-pushed the funding-transaction-signed-rework branch from 61719cf to 135605fCompare December 3, 2025 19:35

wpaulino added this to Weekly Goals Dec 4, 2025

jkczyz reviewed Dec 8, 2025
View reviewed changes

TheBlueMatt reviewed Jan 8, 2026
View reviewed changes

wpaulino added 2 commits January 14, 2026 14:20

wpaulino force-pushed the funding-transaction-signed-rework branch from 135605f to e502ce3Compare January 14, 2026 22:20

wpaulino requested review from TheBlueMatt and jkczyz January 15, 2026 17:15

TheBlueMatt reviewed Jan 16, 2026
View reviewed changes

TheBlueMatt approved these changes Jan 20, 2026
View reviewed changes

TheBlueMatt merged commit 99247a9 into lightningdevkit:mainJan 20, 2026
19 checks passed

github-project-automationBot moved this to Done in Weekly Goals Jan 20, 2026

wpaulino deleted the funding-transaction-signed-rework branch January 22, 2026 17:44

wpaulino mentioned this pull request Jan 22, 2026
Rework ChannelManager::funding_transaction_signed #4336
Merged

jkczyz mentioned this pull request Mar 19, 2026
Splicing / Dual Funding #4284
Open
50 tasks

wpaulino added this to the 0.3 milestone Dec 3, 2025

wpaulino requested a review from jkczyz December 3, 2025 18:47

wpaulino self-assigned this Dec 3, 2025

wpaulino force-pushed the funding-transaction-signed-rework branch from 61719cf to 135605fCompare December 3, 2025 19:35

wpaulino added this to Weekly Goals Dec 4, 2025

jkczyz reviewed Dec 8, 2025
View reviewed changes

TheBlueMatt reviewed Jan 8, 2026
View reviewed changes

wpaulino added 2 commits January 14, 2026 14:20

wpaulino force-pushed the funding-transaction-signed-rework branch from 135605f to e502ce3Compare January 14, 2026 22:20

wpaulino requested review from TheBlueMatt and jkczyz January 15, 2026 17:15

TheBlueMatt reviewed Jan 16, 2026
View reviewed changes

TheBlueMatt approved these changes Jan 20, 2026
View reviewed changes

TheBlueMatt merged commit 99247a9 into lightningdevkit:mainJan 20, 2026
19 checks passed

github-project-automationBot moved this to Done in Weekly Goals Jan 20, 2026

wpaulino deleted the funding-transaction-signed-rework branch January 22, 2026 17:44

wpaulino mentioned this pull request Jan 22, 2026
Rework ChannelManager::funding_transaction_signed #4336
Merged

jkczyz mentioned this pull request Mar 19, 2026
Splicing / Dual Funding #4284
Open
50 tasks

wpaulino added this to the 0.3 milestone Dec 3, 2025

wpaulino requested a review from jkczyz December 3, 2025 18:47

wpaulino self-assigned this Dec 3, 2025

wpaulino force-pushed the funding-transaction-signed-rework branch from 61719cf to 135605fCompare December 3, 2025 19:35

wpaulino added this to Weekly Goals Dec 4, 2025

jkczyz reviewed Dec 8, 2025
View reviewed changes

TheBlueMatt reviewed Jan 8, 2026
View reviewed changes

wpaulino added 2 commits January 14, 2026 14:20

wpaulino force-pushed the funding-transaction-signed-rework branch from 135605f to e502ce3Compare January 14, 2026 22:20

wpaulino requested review from TheBlueMatt and jkczyz January 15, 2026 17:15

TheBlueMatt reviewed Jan 16, 2026
View reviewed changes

TheBlueMatt approved these changes Jan 20, 2026
View reviewed changes

TheBlueMatt merged commit 99247a9 into lightningdevkit:mainJan 20, 2026
19 checks passed

github-project-automationBot moved this to Done in Weekly Goals Jan 20, 2026

wpaulino deleted the funding-transaction-signed-rework branch January 22, 2026 17:44

wpaulino mentioned this pull request Jan 22, 2026
Rework ChannelManager::funding_transaction_signed #4336
Merged

jkczyz mentioned this pull request Mar 19, 2026
Splicing / Dual Funding #4284
Open
50 tasks

wpaulino added this to the 0.3 milestone Dec 3, 2025

wpaulino requested a review from jkczyz December 3, 2025 18:47

wpaulino self-assigned this Dec 3, 2025

wpaulino force-pushed the funding-transaction-signed-rework branch from 61719cf to 135605fCompare December 3, 2025 19:35

wpaulino added this to Weekly Goals Dec 4, 2025

jkczyz reviewed Dec 8, 2025
View reviewed changes

TheBlueMatt reviewed Jan 8, 2026
View reviewed changes

wpaulino added 2 commits January 14, 2026 14:20

wpaulino force-pushed the funding-transaction-signed-rework branch from 135605f to e502ce3Compare January 14, 2026 22:20

wpaulino requested review from TheBlueMatt and jkczyz January 15, 2026 17:15

TheBlueMatt reviewed Jan 16, 2026
View reviewed changes

TheBlueMatt approved these changes Jan 20, 2026
View reviewed changes

TheBlueMatt merged commit 99247a9 into lightningdevkit:mainJan 20, 2026
19 checks passed

github-project-automationBot moved this to Done in Weekly Goals Jan 20, 2026

wpaulino deleted the funding-transaction-signed-rework branch January 22, 2026 17:44

wpaulino mentioned this pull request Jan 22, 2026
Rework ChannelManager::funding_transaction_signed #4336
Merged

jkczyz mentioned this pull request Mar 19, 2026
Splicing / Dual Funding #4284
Open
50 tasks

wpaulino added this to the 0.3 milestone Dec 3, 2025

wpaulino requested a review from jkczyz December 3, 2025 18:47

wpaulino self-assigned this Dec 3, 2025

wpaulino force-pushed the funding-transaction-signed-rework branch from 61719cf to 135605fCompare December 3, 2025 19:35

wpaulino added this to Weekly Goals Dec 4, 2025

jkczyz reviewed Dec 8, 2025
View reviewed changes

TheBlueMatt reviewed Jan 8, 2026
View reviewed changes

wpaulino added 2 commits January 14, 2026 14:20

wpaulino force-pushed the funding-transaction-signed-rework branch from 135605f to e502ce3Compare January 14, 2026 22:20

wpaulino requested review from TheBlueMatt and jkczyz January 15, 2026 17:15

TheBlueMatt reviewed Jan 16, 2026
View reviewed changes

TheBlueMatt approved these changes Jan 20, 2026
View reviewed changes

TheBlueMatt merged commit 99247a9 into lightningdevkit:mainJan 20, 2026
19 checks passed

github-project-automationBot moved this to Done in Weekly Goals Jan 20, 2026

wpaulino deleted the funding-transaction-signed-rework branch January 22, 2026 17:44

wpaulino mentioned this pull request Jan 22, 2026
Rework ChannelManager::funding_transaction_signed #4336
Merged

jkczyz mentioned this pull request Mar 19, 2026
Splicing / Dual Funding #4284
Open
50 tasks

wpaulino added this to the 0.3 milestone Dec 3, 2025

wpaulino requested a review from jkczyz December 3, 2025 18:47

wpaulino self-assigned this Dec 3, 2025

wpaulino force-pushed the funding-transaction-signed-rework branch from 61719cf to 135605fCompare December 3, 2025 19:35

wpaulino added this to Weekly Goals Dec 4, 2025

jkczyz reviewed Dec 8, 2025
View reviewed changes

TheBlueMatt reviewed Jan 8, 2026
View reviewed changes

wpaulino added 2 commits January 14, 2026 14:20

wpaulino force-pushed the funding-transaction-signed-rework branch from 135605f to e502ce3Compare January 14, 2026 22:20

wpaulino requested review from TheBlueMatt and jkczyz January 15, 2026 17:15

TheBlueMatt reviewed Jan 16, 2026
View reviewed changes

TheBlueMatt approved these changes Jan 20, 2026
View reviewed changes

TheBlueMatt merged commit 99247a9 into lightningdevkit:mainJan 20, 2026
19 checks passed

github-project-automationBot moved this to Done in Weekly Goals Jan 20, 2026

wpaulino deleted the funding-transaction-signed-rework branch January 22, 2026 17:44

wpaulino mentioned this pull request Jan 22, 2026
Rework ChannelManager::funding_transaction_signed #4336
Merged

jkczyz mentioned this pull request Mar 19, 2026
Splicing / Dual Funding #4284
Open
50 tasks

wpaulino added this to the 0.3 milestone Dec 3, 2025

wpaulino requested a review from jkczyz December 3, 2025 18:47

wpaulino self-assigned this Dec 3, 2025

wpaulino force-pushed the funding-transaction-signed-rework branch from 61719cf to 135605fCompare December 3, 2025 19:35

wpaulino added this to Weekly Goals Dec 4, 2025

jkczyz reviewed Dec 8, 2025
View reviewed changes

TheBlueMatt reviewed Jan 8, 2026
View reviewed changes

wpaulino added 2 commits January 14, 2026 14:20

wpaulino force-pushed the funding-transaction-signed-rework branch from 135605f to e502ce3Compare January 14, 2026 22:20

wpaulino requested review from TheBlueMatt and jkczyz January 15, 2026 17:15

TheBlueMatt reviewed Jan 16, 2026
View reviewed changes

TheBlueMatt approved these changes Jan 20, 2026
View reviewed changes

TheBlueMatt merged commit 99247a9 into lightningdevkit:mainJan 20, 2026
19 checks passed

github-project-automationBot moved this to Done in Weekly Goals Jan 20, 2026

wpaulino deleted the funding-transaction-signed-rework branch January 22, 2026 17:44

wpaulino mentioned this pull request Jan 22, 2026
Rework ChannelManager::funding_transaction_signed #4336
Merged

jkczyz mentioned this pull request Mar 19, 2026
Splicing / Dual Funding #4284
Open
50 tasks

wpaulino added this to the 0.3 milestone Dec 3, 2025

wpaulino requested a review from jkczyz December 3, 2025 18:47

wpaulino self-assigned this Dec 3, 2025

wpaulino force-pushed the funding-transaction-signed-rework branch from 61719cf to 135605fCompare December 3, 2025 19:35

wpaulino added this to Weekly Goals Dec 4, 2025

jkczyz reviewed Dec 8, 2025
View reviewed changes

TheBlueMatt reviewed Jan 8, 2026
View reviewed changes

wpaulino added 2 commits January 14, 2026 14:20

wpaulino force-pushed the funding-transaction-signed-rework branch from 135605f to e502ce3Compare January 14, 2026 22:20

wpaulino requested review from TheBlueMatt and jkczyz January 15, 2026 17:15

TheBlueMatt reviewed Jan 16, 2026
View reviewed changes

TheBlueMatt approved these changes Jan 20, 2026
View reviewed changes

TheBlueMatt merged commit 99247a9 into lightningdevkit:mainJan 20, 2026
19 checks passed

github-project-automationBot moved this to Done in Weekly Goals Jan 20, 2026

wpaulino deleted the funding-transaction-signed-rework branch January 22, 2026 17:44

wpaulino mentioned this pull request Jan 22, 2026
Rework ChannelManager::funding_transaction_signed #4336
Merged

jkczyz mentioned this pull request Mar 19, 2026
Splicing / Dual Funding #4284
Open
50 tasks

		Some(channel) => match channel.as_funded_mut() {
		Some(chan) => {

		// TODO(splicing): Support async signing
		.ok_or("Failed to compute commitment_signed signatures".to_owned())?;

Uh oh!

Conversation

wpaulino commented Dec 3, 2025

Uh oh!

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

Uh oh!

Uh oh!

codecovBot commented Dec 3, 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 Dec 6, 2025

Uh oh!

ldk-reviews-bot commented Dec 8, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

ldk-reviews-bot commented Dec 8, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ldk-reviews-bot commented Jan 19, 2026

Uh oh!

TheBlueMatt left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

TheBlueMatt commented Jan 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Conversation

wpaulino commented Dec 3, 2025

Uh oh!

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

Uh oh!

Uh oh!

codecovBot commented Dec 3, 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 Dec 6, 2025

Uh oh!

ldk-reviews-bot commented Dec 8, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

ldk-reviews-bot commented Dec 3, 2025•
edited
Loading

codecovBot commented Dec 3, 2025•
edited
Loading

ldk-reviews-bot commented Dec 3, 2025•
edited
Loading

codecovBot commented Dec 3, 2025•
edited
Loading