Skip to content

Conversation

@joostjager
Copy link
Contributor

@joostjager joostjager commented Nov 11, 2025

Add a new safe_channels feature flag that gates in-development work toward persisting channel monitors and channels atomically, preventing them from desynchronizing and causing force closures.

This commit begins that transition by storing both pieces together and adding consistency checks during writes. These checks mirror what the channel manager currently validates only on reload, but performing them earlier increases coverage and surfaces inconsistencies sooner.

@ldk-reviews-bot
Copy link

ldk-reviews-bot commented Nov 11, 2025

👋 I see @valentinewallace was un-assigned.
If you'd like another reviewer assignment, please click here.

@joostjager joostjager force-pushed the chan-monitor-consistency-check branch 3 times, most recently from dda4c5c to b00ff03 Compare November 14, 2025 10:56
@joostjager joostjager changed the title add channel <-> channel monitor consistency check Channel <-> channel monitor consistency check Nov 14, 2025
@joostjager joostjager force-pushed the chan-monitor-consistency-check branch 2 times, most recently from c3771b6 to f387f90 Compare November 14, 2025 11:01
@codecov
Copy link

codecov bot commented Nov 14, 2025

Codecov Report

❌ Patch coverage is 62.94118% with 63 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.27%. Comparing base (bb5504e) to head (44538f9).

Files with missing lines Patch % Lines
lightning/src/ln/channel.rs 56.25% 61 Missing and 2 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #4218      +/-   ##
==========================================
- Coverage   89.33%   89.27%   -0.06%     
==========================================
  Files         180      180              
  Lines      138680   138786     +106     
  Branches   138680   138786     +106     
==========================================
+ Hits       123888   123906      +18     
- Misses      12172    12258      +86     
- Partials     2620     2622       +2     
Flag Coverage Δ
fuzzing 34.99% <36.47%> (-1.00%) ⬇️
tests 88.64% <62.94%> (-0.06%) ⬇️

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.

@joostjager joostjager force-pushed the chan-monitor-consistency-check branch 3 times, most recently from 00a95f1 to a82719b Compare November 14, 2025 19:36
@joostjager joostjager changed the title Channel <-> channel monitor consistency check Store and check channel data in channel monitors Add a new safe_channels feature flag that gates in-development work toward persisting channel monitors and channels atomically, preventing them from desynchronizing and causing force closures. This commit begins that transition by storing both pieces together and adding consistency checks during writes. These checks mirror what the channel manager currently validates only on reload, but performing them earlier increases coverage and surfaces inconsistencies sooner. Nov 14, 2025
@joostjager joostjager changed the title Store and check channel data in channel monitors Add a new safe_channels feature flag that gates in-development work toward persisting channel monitors and channels atomically, preventing them from desynchronizing and causing force closures. This commit begins that transition by storing both pieces together and adding consistency checks during writes. These checks mirror what the channel manager currently validates only on reload, but performing them earlier increases coverage and surfaces inconsistencies sooner. Store and check channel data in channel monitors Nov 14, 2025
@joostjager joostjager force-pushed the chan-monitor-consistency-check branch from a82719b to d4d0879 Compare November 18, 2025 14:13
@joostjager joostjager removed the request for review from valentinewallace November 19, 2025 14:50

/// The encoded channel data associated with this ChannelMonitor, if any.
#[cfg(feature = "safe_channels")]
pub encoded_channel: Option<Vec<u8>>,
Copy link
Contributor Author

@joostjager joostjager Nov 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Continuing discussion here @valentinewallace #4151 (comment)

Did you explore encoding the FundedChannel itself rather than a bag of bytes? I guess it would require propagating the signer trait parameter, which is kind of annoying?

I think it is possible, but with a few workarounds. The advantage would be that we have a clear target struct to strip all the data off that is redundant for channel monitor.

https://github.com/joostjager/rust-lightning/compare/chan-monitor-unencoded-chan%7E1...joostjager:rust-lightning:chan-monitor-unencoded-chan?expand=1 (wip)

We do need to allow cloning of the channel to get a copy to store inside the monitor and monitor update. Also equality needs to be implemented. And it is the case that a channel contains a list of blocked monitor updates, that can again contain a channel copy. Not sure if we getting into something undesirable with that form of nesting.

The pending_splice field also turned out to be difficult to clone. For now, I just took the serialized version of it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Problems above have mostly been solved now

@joostjager joostjager self-assigned this Nov 20, 2025
@joostjager
Copy link
Contributor Author

joostjager commented Nov 24, 2025

Tests now pass with the unencoded channel as part of ChannelMonitorUpdate. Spent considerable time figuring out how to fix the infinite type recursion problem caused by blocked_monitor_updates (which again contain FundedChannelState instances), but didn't succeed. For now, the serialized versions are stored in blocked_monitor_updates to break the recursion.

Isolated repro: https://github.com/lightningdevkit/rust-lightning/compare/main...joostjager:repro-recursive-ser-issue?expand=1

Additional trace logs to help with debugging.
@joostjager joostjager force-pushed the chan-monitor-consistency-check branch from 05fbe65 to 2dc7ca2 Compare November 24, 2025 15:28
Preparation for serializing the enum. The serialization macros do not
support multiple unnamed fields.
Add a new `safe_channels` feature flag that gates in-development work
toward persisting channel monitors and channels atomically, preventing
them from desynchronizing and causing force closures.

This commit begins that transition by storing both pieces together and
adding consistency checks during writes. These checks mirror what the
channel manager currently validates only on reload, but performing them
earlier increases coverage and surfaces inconsistencies sooner.
@joostjager joostjager force-pushed the chan-monitor-consistency-check branch from 2dc7ca2 to 17f71b0 Compare November 25, 2025 07:33
@joostjager joostjager force-pushed the chan-monitor-consistency-check branch 3 times, most recently from c11d5ec to 96dc75d Compare November 25, 2025 08:41
@joostjager joostjager force-pushed the chan-monitor-consistency-check branch from 96dc75d to 44538f9 Compare November 25, 2025 09:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

2 participants