Drop `Deref` indirection for most trait parameters by valentinewallace · Pull Request #4311 · lightningdevkit/rust-lightning

valentinewallace · 2026-01-13T19:16:02Z

Reduces generics and verbosity across the codebase, should provide equivalent behavior.

Inspired by #4309 (comment). Basically, instead of Deref indirection we instead impl<T: Trait, D: Deref<Target = Trait>> Trait for D for all our traits.

The majority of the codebase's traits are done in this PR, but we do skip a good amount still. In a lot of cases traits are skipped because of compiler complaints about (potential-) conflicting trait implementations, but also ran into some lifetime issues and some c_bindings issues.

ldk-reviews-bot · 2026-01-13T19:16:05Z

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

valentinewallace · 2026-01-13T19:16:30Z

If this looks good and works for language bindings, I/claude can do it for all the other traits. I feel like this is a solid improvement.

valentinewallace · 2026-01-13T19:17:01Z

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

valentinewallace · 2026-01-13T19:19:56Z

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

TheBlueMatt · 2026-01-13T20:32:05Z

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

It means updating the generation logic to support it, but it certainly isn't directly problematic.

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

You can write it as impl<T: BroadcasterInterface, B: Deref<Target = T>> BroadcasterInterface for B { instead of impl<B: Deref<Target: BroadcasterInterface>> BroadcasterInterface for B {.

TheBlueMatt · 2026-01-13T20:32:28Z

Conceptually tho yea imo we should do this. Its "the right way" to do it in rust.

codecov · 2026-01-13T23:55:54Z

Codecov Report

❌ Patch coverage is 81.59722% with 212 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.98%. Comparing base (f9ad345) to head (101d206).
⚠️ Report is 19 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/msgs.rs	35.05%	126 Missing ⚠️
lightning/src/util/persist.rs	45.94%	20 Missing ⚠️
lightning/src/ln/channel.rs	93.85%	14 Missing ⚠️
lightning/src/ln/peer_handler.rs	70.58%	9 Missing and 1 partial ⚠️
lightning-background-processor/src/lib.rs	68.18%	7 Missing ⚠️
lightning/src/chain/channelmonitor.rs	91.02%	7 Missing ⚠️
lightning/src/util/anchor_channel_reserves.rs	0.00%	6 Missing ⚠️
lightning/src/chain/chainmonitor.rs	77.77%	4 Missing ⚠️
lightning/src/onion_message/messenger.rs	92.00%	4 Missing ⚠️
lightning-net-tokio/src/lib.rs	0.00%	3 Missing ⚠️
... and 6 more

Additional details and impacted files

@@ Coverage Diff @@## main #4311 +/- ##
==========================================
- Coverage 86.09% 85.98% -0.12% 
==========================================
Files 156 156 Lines 102804 102609 -195 Branches 102804 102609 -195 ==========================================
- Hits 88508 88225 -283 - Misses 11788 11873 +85 - Partials 2508 2511 +3

Flag	Coverage Δ
tests	`85.98% <81.59%> (-0.12%)`	⬇️

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.

tnull

Note that you'll need to bump lightning-liquidity's version to 0.3.0+git to get the SemVer checks to pass, as it's an API-breaking change.

joostjager · 2026-01-15T18:42:15Z

Is the Logger a candidate too for this?

valentinewallace · 2026-01-15T18:49:01Z

Is the Logger a candidate too for this?

Yes, I will un-draft the PR once all the traits are complete :)

ldk-reviews-bot · 2026-01-15T19:18:08Z

🔔 1st Reminder

Hey @TheBlueMatt! 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.

joostjager · 2026-01-15T22:26:38Z

 	fn message_received(&self);
 }

+impl<T: ChannelMessageHandler + ?Sized, C: Deref<Target = T>> ChannelMessageHandler for C {


Is this really better than using Arc instead of Deref, and accepting that for no-std the API might look slightly different?
There aren't that many no-std projects.

Yeah maybe we should resolve this here #4309 (comment) before moving forward with this direction? Is it still difficult to add new trait params now that we have Claude?

Ask Claude to add a logger to ChannelMonitor, and then report back 😂

valentinewallace · 2026-01-20T17:26:20Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

TheBlueMatt · 2026-01-20T19:18:34Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

valentinewallace · 2026-01-20T19:24:26Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.
It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

I'm aware, but I'm not sure if it's something that should be fixed or whether the new rust-lightning API isn't good. Thought he might know off the top of his head :p

TheBlueMatt · 2026-01-20T19:31:20Z

Fair enough. It does look like its just a conflict cause there's a deref-bounded auto-impl, which shouldn't be crazy to fix. Would have to go actually try to be sure though.

tnull

Seems this needs yet another rebase unfortunately!

Useful for upcoming commits where we otherwise break SemVer checks by changing the ALiquidityManager associated types.

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Unfortunately the same improvement can't be made for KVStoreSync and Persist, due to the blanket implementation where all KVStoreSync traits implement Persist resulting in conflicting implementations. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. This could be split into multiple commits (e.g. one for OnionMessenger message handler types, one for PeerManager message handler types) but it would require adding a new IgnoringOnionMessageHandler type for the messenger handlers, due to the IgnoringMessageHandler's Deref implementation conflicting otherwise. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

valentinewallace · 2026-01-30T15:23:28Z

Rebased

valentinewallace · 2026-01-30T22:11:20Z

Only change since @tnull's last ACK was a rebase, landing

valentinewallace · 2026-01-13T19:16:02Z

Reduces generics and verbosity across the codebase, should provide equivalent behavior.

Inspired by #4309 (comment). Basically, instead of Deref indirection we instead impl<T: Trait, D: Deref<Target = Trait>> Trait for D for all our traits.

The majority of the codebase's traits are done in this PR, but we do skip a good amount still. In a lot of cases traits are skipped because of compiler complaints about (potential-) conflicting trait implementations, but also ran into some lifetime issues and some c_bindings issues.

ldk-reviews-bot · 2026-01-13T19:16:05Z

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

valentinewallace · 2026-01-13T19:16:30Z

If this looks good and works for language bindings, I/claude can do it for all the other traits. I feel like this is a solid improvement.

valentinewallace · 2026-01-13T19:17:01Z

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

valentinewallace · 2026-01-13T19:19:56Z

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

TheBlueMatt · 2026-01-13T20:32:05Z

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

It means updating the generation logic to support it, but it certainly isn't directly problematic.

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

You can write it as impl<T: BroadcasterInterface, B: Deref<Target = T>> BroadcasterInterface for B { instead of impl<B: Deref<Target: BroadcasterInterface>> BroadcasterInterface for B {.

TheBlueMatt · 2026-01-13T20:32:28Z

Conceptually tho yea imo we should do this. Its "the right way" to do it in rust.

codecov · 2026-01-13T23:55:54Z

Codecov Report

❌ Patch coverage is 81.59722% with 212 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.98%. Comparing base (f9ad345) to head (101d206).
⚠️ Report is 19 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/msgs.rs	35.05%	126 Missing ⚠️
lightning/src/util/persist.rs	45.94%	20 Missing ⚠️
lightning/src/ln/channel.rs	93.85%	14 Missing ⚠️
lightning/src/ln/peer_handler.rs	70.58%	9 Missing and 1 partial ⚠️
lightning-background-processor/src/lib.rs	68.18%	7 Missing ⚠️
lightning/src/chain/channelmonitor.rs	91.02%	7 Missing ⚠️
lightning/src/util/anchor_channel_reserves.rs	0.00%	6 Missing ⚠️
lightning/src/chain/chainmonitor.rs	77.77%	4 Missing ⚠️
lightning/src/onion_message/messenger.rs	92.00%	4 Missing ⚠️
lightning-net-tokio/src/lib.rs	0.00%	3 Missing ⚠️
... and 6 more

Additional details and impacted files

@@ Coverage Diff @@## main #4311 +/- ##
==========================================
- Coverage 86.09% 85.98% -0.12% 
==========================================
Files 156 156 Lines 102804 102609 -195 Branches 102804 102609 -195 ==========================================
- Hits 88508 88225 -283 - Misses 11788 11873 +85 - Partials 2508 2511 +3

Flag	Coverage Δ
tests	`85.98% <81.59%> (-0.12%)`	⬇️

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.

tnull

Note that you'll need to bump lightning-liquidity's version to 0.3.0+git to get the SemVer checks to pass, as it's an API-breaking change.

joostjager · 2026-01-15T18:42:15Z

Is the Logger a candidate too for this?

valentinewallace · 2026-01-15T18:49:01Z

Is the Logger a candidate too for this?

Yes, I will un-draft the PR once all the traits are complete :)

ldk-reviews-bot · 2026-01-15T19:18:08Z

🔔 1st Reminder

Hey @TheBlueMatt! 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.

joostjager · 2026-01-15T22:26:38Z

 	fn message_received(&self);
 }

+impl<T: ChannelMessageHandler + ?Sized, C: Deref<Target = T>> ChannelMessageHandler for C {


Is this really better than using Arc instead of Deref, and accepting that for no-std the API might look slightly different?
There aren't that many no-std projects.

Yeah maybe we should resolve this here #4309 (comment) before moving forward with this direction? Is it still difficult to add new trait params now that we have Claude?

Ask Claude to add a logger to ChannelMonitor, and then report back 😂

valentinewallace · 2026-01-20T17:26:20Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

TheBlueMatt · 2026-01-20T19:18:34Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

valentinewallace · 2026-01-20T19:24:26Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.
It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

I'm aware, but I'm not sure if it's something that should be fixed or whether the new rust-lightning API isn't good. Thought he might know off the top of his head :p

TheBlueMatt · 2026-01-20T19:31:20Z

Fair enough. It does look like its just a conflict cause there's a deref-bounded auto-impl, which shouldn't be crazy to fix. Would have to go actually try to be sure though.

tnull

Seems this needs yet another rebase unfortunately!

Useful for upcoming commits where we otherwise break SemVer checks by changing the ALiquidityManager associated types.

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Unfortunately the same improvement can't be made for KVStoreSync and Persist, due to the blanket implementation where all KVStoreSync traits implement Persist resulting in conflicting implementations. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. This could be split into multiple commits (e.g. one for OnionMessenger message handler types, one for PeerManager message handler types) but it would require adding a new IgnoringOnionMessageHandler type for the messenger handlers, due to the IgnoringMessageHandler's Deref implementation conflicting otherwise. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

valentinewallace · 2026-01-30T15:23:28Z

Rebased

valentinewallace · 2026-01-30T22:11:20Z

Only change since @tnull's last ACK was a rebase, landing

valentinewallace · 2026-01-13T19:16:02Z

Reduces generics and verbosity across the codebase, should provide equivalent behavior.

Inspired by #4309 (comment). Basically, instead of Deref indirection we instead impl<T: Trait, D: Deref<Target = Trait>> Trait for D for all our traits.

The majority of the codebase's traits are done in this PR, but we do skip a good amount still. In a lot of cases traits are skipped because of compiler complaints about (potential-) conflicting trait implementations, but also ran into some lifetime issues and some c_bindings issues.

ldk-reviews-bot · 2026-01-13T19:16:05Z

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

valentinewallace · 2026-01-13T19:16:30Z

If this looks good and works for language bindings, I/claude can do it for all the other traits. I feel like this is a solid improvement.

valentinewallace · 2026-01-13T19:17:01Z

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

valentinewallace · 2026-01-13T19:19:56Z

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

TheBlueMatt · 2026-01-13T20:32:05Z

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

It means updating the generation logic to support it, but it certainly isn't directly problematic.

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

You can write it as impl<T: BroadcasterInterface, B: Deref<Target = T>> BroadcasterInterface for B { instead of impl<B: Deref<Target: BroadcasterInterface>> BroadcasterInterface for B {.

TheBlueMatt · 2026-01-13T20:32:28Z

Conceptually tho yea imo we should do this. Its "the right way" to do it in rust.

codecov · 2026-01-13T23:55:54Z

Codecov Report

❌ Patch coverage is 81.59722% with 212 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.98%. Comparing base (f9ad345) to head (101d206).
⚠️ Report is 19 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/msgs.rs	35.05%	126 Missing ⚠️
lightning/src/util/persist.rs	45.94%	20 Missing ⚠️
lightning/src/ln/channel.rs	93.85%	14 Missing ⚠️
lightning/src/ln/peer_handler.rs	70.58%	9 Missing and 1 partial ⚠️
lightning-background-processor/src/lib.rs	68.18%	7 Missing ⚠️
lightning/src/chain/channelmonitor.rs	91.02%	7 Missing ⚠️
lightning/src/util/anchor_channel_reserves.rs	0.00%	6 Missing ⚠️
lightning/src/chain/chainmonitor.rs	77.77%	4 Missing ⚠️
lightning/src/onion_message/messenger.rs	92.00%	4 Missing ⚠️
lightning-net-tokio/src/lib.rs	0.00%	3 Missing ⚠️
... and 6 more

Additional details and impacted files

@@ Coverage Diff @@## main #4311 +/- ##
==========================================
- Coverage 86.09% 85.98% -0.12% 
==========================================
Files 156 156 Lines 102804 102609 -195 Branches 102804 102609 -195 ==========================================
- Hits 88508 88225 -283 - Misses 11788 11873 +85 - Partials 2508 2511 +3

Flag	Coverage Δ
tests	`85.98% <81.59%> (-0.12%)`	⬇️

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.

tnull

Note that you'll need to bump lightning-liquidity's version to 0.3.0+git to get the SemVer checks to pass, as it's an API-breaking change.

joostjager · 2026-01-15T18:42:15Z

Is the Logger a candidate too for this?

valentinewallace · 2026-01-15T18:49:01Z

Is the Logger a candidate too for this?

Yes, I will un-draft the PR once all the traits are complete :)

ldk-reviews-bot · 2026-01-15T19:18:08Z

🔔 1st Reminder

Hey @TheBlueMatt! 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.

joostjager · 2026-01-15T22:26:38Z

 	fn message_received(&self);
 }

+impl<T: ChannelMessageHandler + ?Sized, C: Deref<Target = T>> ChannelMessageHandler for C {


Is this really better than using Arc instead of Deref, and accepting that for no-std the API might look slightly different?
There aren't that many no-std projects.

Yeah maybe we should resolve this here #4309 (comment) before moving forward with this direction? Is it still difficult to add new trait params now that we have Claude?

Ask Claude to add a logger to ChannelMonitor, and then report back 😂

valentinewallace · 2026-01-20T17:26:20Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

TheBlueMatt · 2026-01-20T19:18:34Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

valentinewallace · 2026-01-20T19:24:26Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.
It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

I'm aware, but I'm not sure if it's something that should be fixed or whether the new rust-lightning API isn't good. Thought he might know off the top of his head :p

TheBlueMatt · 2026-01-20T19:31:20Z

Fair enough. It does look like its just a conflict cause there's a deref-bounded auto-impl, which shouldn't be crazy to fix. Would have to go actually try to be sure though.

tnull

Seems this needs yet another rebase unfortunately!

Useful for upcoming commits where we otherwise break SemVer checks by changing the ALiquidityManager associated types.

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Unfortunately the same improvement can't be made for KVStoreSync and Persist, due to the blanket implementation where all KVStoreSync traits implement Persist resulting in conflicting implementations. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. This could be split into multiple commits (e.g. one for OnionMessenger message handler types, one for PeerManager message handler types) but it would require adding a new IgnoringOnionMessageHandler type for the messenger handlers, due to the IgnoringMessageHandler's Deref implementation conflicting otherwise. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

valentinewallace · 2026-01-30T15:23:28Z

Rebased

valentinewallace · 2026-01-30T22:11:20Z

Only change since @tnull's last ACK was a rebase, landing

valentinewallace · 2026-01-13T19:16:02Z

Reduces generics and verbosity across the codebase, should provide equivalent behavior.

Inspired by #4309 (comment). Basically, instead of Deref indirection we instead impl<T: Trait, D: Deref<Target = Trait>> Trait for D for all our traits.

The majority of the codebase's traits are done in this PR, but we do skip a good amount still. In a lot of cases traits are skipped because of compiler complaints about (potential-) conflicting trait implementations, but also ran into some lifetime issues and some c_bindings issues.

ldk-reviews-bot · 2026-01-13T19:16:05Z

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

valentinewallace · 2026-01-13T19:16:30Z

If this looks good and works for language bindings, I/claude can do it for all the other traits. I feel like this is a solid improvement.

valentinewallace · 2026-01-13T19:17:01Z

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

valentinewallace · 2026-01-13T19:19:56Z

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

TheBlueMatt · 2026-01-13T20:32:05Z

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

It means updating the generation logic to support it, but it certainly isn't directly problematic.

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

You can write it as impl<T: BroadcasterInterface, B: Deref<Target = T>> BroadcasterInterface for B { instead of impl<B: Deref<Target: BroadcasterInterface>> BroadcasterInterface for B {.

TheBlueMatt · 2026-01-13T20:32:28Z

Conceptually tho yea imo we should do this. Its "the right way" to do it in rust.

codecov · 2026-01-13T23:55:54Z

Codecov Report

❌ Patch coverage is 81.59722% with 212 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.98%. Comparing base (f9ad345) to head (101d206).
⚠️ Report is 19 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/msgs.rs	35.05%	126 Missing ⚠️
lightning/src/util/persist.rs	45.94%	20 Missing ⚠️
lightning/src/ln/channel.rs	93.85%	14 Missing ⚠️
lightning/src/ln/peer_handler.rs	70.58%	9 Missing and 1 partial ⚠️
lightning-background-processor/src/lib.rs	68.18%	7 Missing ⚠️
lightning/src/chain/channelmonitor.rs	91.02%	7 Missing ⚠️
lightning/src/util/anchor_channel_reserves.rs	0.00%	6 Missing ⚠️
lightning/src/chain/chainmonitor.rs	77.77%	4 Missing ⚠️
lightning/src/onion_message/messenger.rs	92.00%	4 Missing ⚠️
lightning-net-tokio/src/lib.rs	0.00%	3 Missing ⚠️
... and 6 more

Additional details and impacted files

@@ Coverage Diff @@## main #4311 +/- ##
==========================================
- Coverage 86.09% 85.98% -0.12% 
==========================================
Files 156 156 Lines 102804 102609 -195 Branches 102804 102609 -195 ==========================================
- Hits 88508 88225 -283 - Misses 11788 11873 +85 - Partials 2508 2511 +3

Flag	Coverage Δ
tests	`85.98% <81.59%> (-0.12%)`	⬇️

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.

tnull

Note that you'll need to bump lightning-liquidity's version to 0.3.0+git to get the SemVer checks to pass, as it's an API-breaking change.

joostjager · 2026-01-15T18:42:15Z

Is the Logger a candidate too for this?

valentinewallace · 2026-01-15T18:49:01Z

Is the Logger a candidate too for this?

Yes, I will un-draft the PR once all the traits are complete :)

ldk-reviews-bot · 2026-01-15T19:18:08Z

🔔 1st Reminder

Hey @TheBlueMatt! 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.

joostjager · 2026-01-15T22:26:38Z

 	fn message_received(&self);
 }

+impl<T: ChannelMessageHandler + ?Sized, C: Deref<Target = T>> ChannelMessageHandler for C {


Is this really better than using Arc instead of Deref, and accepting that for no-std the API might look slightly different?
There aren't that many no-std projects.

Yeah maybe we should resolve this here #4309 (comment) before moving forward with this direction? Is it still difficult to add new trait params now that we have Claude?

Ask Claude to add a logger to ChannelMonitor, and then report back 😂

valentinewallace · 2026-01-20T17:26:20Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

TheBlueMatt · 2026-01-20T19:18:34Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

valentinewallace · 2026-01-20T19:24:26Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.
It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

I'm aware, but I'm not sure if it's something that should be fixed or whether the new rust-lightning API isn't good. Thought he might know off the top of his head :p

TheBlueMatt · 2026-01-20T19:31:20Z

Fair enough. It does look like its just a conflict cause there's a deref-bounded auto-impl, which shouldn't be crazy to fix. Would have to go actually try to be sure though.

tnull

Seems this needs yet another rebase unfortunately!

Useful for upcoming commits where we otherwise break SemVer checks by changing the ALiquidityManager associated types.

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Unfortunately the same improvement can't be made for KVStoreSync and Persist, due to the blanket implementation where all KVStoreSync traits implement Persist resulting in conflicting implementations. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. This could be split into multiple commits (e.g. one for OnionMessenger message handler types, one for PeerManager message handler types) but it would require adding a new IgnoringOnionMessageHandler type for the messenger handlers, due to the IgnoringMessageHandler's Deref implementation conflicting otherwise. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

valentinewallace · 2026-01-30T15:23:28Z

Rebased

valentinewallace · 2026-01-30T22:11:20Z

Only change since @tnull's last ACK was a rebase, landing

valentinewallace · 2026-01-13T19:16:02Z

Reduces generics and verbosity across the codebase, should provide equivalent behavior.

Inspired by #4309 (comment). Basically, instead of Deref indirection we instead impl<T: Trait, D: Deref<Target = Trait>> Trait for D for all our traits.

The majority of the codebase's traits are done in this PR, but we do skip a good amount still. In a lot of cases traits are skipped because of compiler complaints about (potential-) conflicting trait implementations, but also ran into some lifetime issues and some c_bindings issues.

ldk-reviews-bot · 2026-01-13T19:16:05Z

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

valentinewallace · 2026-01-13T19:16:30Z

If this looks good and works for language bindings, I/claude can do it for all the other traits. I feel like this is a solid improvement.

valentinewallace · 2026-01-13T19:17:01Z

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

valentinewallace · 2026-01-13T19:19:56Z

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

TheBlueMatt · 2026-01-13T20:32:05Z

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

It means updating the generation logic to support it, but it certainly isn't directly problematic.

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

You can write it as impl<T: BroadcasterInterface, B: Deref<Target = T>> BroadcasterInterface for B { instead of impl<B: Deref<Target: BroadcasterInterface>> BroadcasterInterface for B {.

TheBlueMatt · 2026-01-13T20:32:28Z

Conceptually tho yea imo we should do this. Its "the right way" to do it in rust.

codecov · 2026-01-13T23:55:54Z

Codecov Report

❌ Patch coverage is 81.59722% with 212 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.98%. Comparing base (f9ad345) to head (101d206).
⚠️ Report is 19 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/msgs.rs	35.05%	126 Missing ⚠️
lightning/src/util/persist.rs	45.94%	20 Missing ⚠️
lightning/src/ln/channel.rs	93.85%	14 Missing ⚠️
lightning/src/ln/peer_handler.rs	70.58%	9 Missing and 1 partial ⚠️
lightning-background-processor/src/lib.rs	68.18%	7 Missing ⚠️
lightning/src/chain/channelmonitor.rs	91.02%	7 Missing ⚠️
lightning/src/util/anchor_channel_reserves.rs	0.00%	6 Missing ⚠️
lightning/src/chain/chainmonitor.rs	77.77%	4 Missing ⚠️
lightning/src/onion_message/messenger.rs	92.00%	4 Missing ⚠️
lightning-net-tokio/src/lib.rs	0.00%	3 Missing ⚠️
... and 6 more

Additional details and impacted files

@@ Coverage Diff @@## main #4311 +/- ##
==========================================
- Coverage 86.09% 85.98% -0.12% 
==========================================
Files 156 156 Lines 102804 102609 -195 Branches 102804 102609 -195 ==========================================
- Hits 88508 88225 -283 - Misses 11788 11873 +85 - Partials 2508 2511 +3

Flag	Coverage Δ
tests	`85.98% <81.59%> (-0.12%)`	⬇️

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.

tnull

Note that you'll need to bump lightning-liquidity's version to 0.3.0+git to get the SemVer checks to pass, as it's an API-breaking change.

joostjager · 2026-01-15T18:42:15Z

Is the Logger a candidate too for this?

valentinewallace · 2026-01-15T18:49:01Z

Is the Logger a candidate too for this?

Yes, I will un-draft the PR once all the traits are complete :)

ldk-reviews-bot · 2026-01-15T19:18:08Z

🔔 1st Reminder

Hey @TheBlueMatt! 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.

joostjager · 2026-01-15T22:26:38Z

 	fn message_received(&self);
 }

+impl<T: ChannelMessageHandler + ?Sized, C: Deref<Target = T>> ChannelMessageHandler for C {


Is this really better than using Arc instead of Deref, and accepting that for no-std the API might look slightly different?
There aren't that many no-std projects.

Yeah maybe we should resolve this here #4309 (comment) before moving forward with this direction? Is it still difficult to add new trait params now that we have Claude?

Ask Claude to add a logger to ChannelMonitor, and then report back 😂

valentinewallace · 2026-01-20T17:26:20Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

TheBlueMatt · 2026-01-20T19:18:34Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

valentinewallace · 2026-01-20T19:24:26Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.
It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

I'm aware, but I'm not sure if it's something that should be fixed or whether the new rust-lightning API isn't good. Thought he might know off the top of his head :p

TheBlueMatt · 2026-01-20T19:31:20Z

Fair enough. It does look like its just a conflict cause there's a deref-bounded auto-impl, which shouldn't be crazy to fix. Would have to go actually try to be sure though.

tnull

Seems this needs yet another rebase unfortunately!

Useful for upcoming commits where we otherwise break SemVer checks by changing the ALiquidityManager associated types.

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Unfortunately the same improvement can't be made for KVStoreSync and Persist, due to the blanket implementation where all KVStoreSync traits implement Persist resulting in conflicting implementations. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. This could be split into multiple commits (e.g. one for OnionMessenger message handler types, one for PeerManager message handler types) but it would require adding a new IgnoringOnionMessageHandler type for the messenger handlers, due to the IgnoringMessageHandler's Deref implementation conflicting otherwise. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

valentinewallace · 2026-01-30T15:23:28Z

Rebased

valentinewallace · 2026-01-30T22:11:20Z

Only change since @tnull's last ACK was a rebase, landing

valentinewallace · 2026-01-13T19:16:02Z

Reduces generics and verbosity across the codebase, should provide equivalent behavior.

Inspired by #4309 (comment). Basically, instead of Deref indirection we instead impl<T: Trait, D: Deref<Target = Trait>> Trait for D for all our traits.

The majority of the codebase's traits are done in this PR, but we do skip a good amount still. In a lot of cases traits are skipped because of compiler complaints about (potential-) conflicting trait implementations, but also ran into some lifetime issues and some c_bindings issues.

ldk-reviews-bot · 2026-01-13T19:16:05Z

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

valentinewallace · 2026-01-13T19:16:30Z

If this looks good and works for language bindings, I/claude can do it for all the other traits. I feel like this is a solid improvement.

valentinewallace · 2026-01-13T19:17:01Z

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

valentinewallace · 2026-01-13T19:19:56Z

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

TheBlueMatt · 2026-01-13T20:32:05Z

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

It means updating the generation logic to support it, but it certainly isn't directly problematic.

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

You can write it as impl<T: BroadcasterInterface, B: Deref<Target = T>> BroadcasterInterface for B { instead of impl<B: Deref<Target: BroadcasterInterface>> BroadcasterInterface for B {.

TheBlueMatt · 2026-01-13T20:32:28Z

Conceptually tho yea imo we should do this. Its "the right way" to do it in rust.

codecov · 2026-01-13T23:55:54Z

Codecov Report

❌ Patch coverage is 81.59722% with 212 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.98%. Comparing base (f9ad345) to head (101d206).
⚠️ Report is 19 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/msgs.rs	35.05%	126 Missing ⚠️
lightning/src/util/persist.rs	45.94%	20 Missing ⚠️
lightning/src/ln/channel.rs	93.85%	14 Missing ⚠️
lightning/src/ln/peer_handler.rs	70.58%	9 Missing and 1 partial ⚠️
lightning-background-processor/src/lib.rs	68.18%	7 Missing ⚠️
lightning/src/chain/channelmonitor.rs	91.02%	7 Missing ⚠️
lightning/src/util/anchor_channel_reserves.rs	0.00%	6 Missing ⚠️
lightning/src/chain/chainmonitor.rs	77.77%	4 Missing ⚠️
lightning/src/onion_message/messenger.rs	92.00%	4 Missing ⚠️
lightning-net-tokio/src/lib.rs	0.00%	3 Missing ⚠️
... and 6 more

Additional details and impacted files

@@ Coverage Diff @@## main #4311 +/- ##
==========================================
- Coverage 86.09% 85.98% -0.12% 
==========================================
Files 156 156 Lines 102804 102609 -195 Branches 102804 102609 -195 ==========================================
- Hits 88508 88225 -283 - Misses 11788 11873 +85 - Partials 2508 2511 +3

Flag	Coverage Δ
tests	`85.98% <81.59%> (-0.12%)`	⬇️

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.

tnull

Note that you'll need to bump lightning-liquidity's version to 0.3.0+git to get the SemVer checks to pass, as it's an API-breaking change.

joostjager · 2026-01-15T18:42:15Z

Is the Logger a candidate too for this?

valentinewallace · 2026-01-15T18:49:01Z

Is the Logger a candidate too for this?

Yes, I will un-draft the PR once all the traits are complete :)

ldk-reviews-bot · 2026-01-15T19:18:08Z

🔔 1st Reminder

Hey @TheBlueMatt! 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.

joostjager · 2026-01-15T22:26:38Z

 	fn message_received(&self);
 }

+impl<T: ChannelMessageHandler + ?Sized, C: Deref<Target = T>> ChannelMessageHandler for C {


Is this really better than using Arc instead of Deref, and accepting that for no-std the API might look slightly different?
There aren't that many no-std projects.

Yeah maybe we should resolve this here #4309 (comment) before moving forward with this direction? Is it still difficult to add new trait params now that we have Claude?

Ask Claude to add a logger to ChannelMonitor, and then report back 😂

valentinewallace · 2026-01-20T17:26:20Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

TheBlueMatt · 2026-01-20T19:18:34Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

valentinewallace · 2026-01-20T19:24:26Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.
It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

I'm aware, but I'm not sure if it's something that should be fixed or whether the new rust-lightning API isn't good. Thought he might know off the top of his head :p

TheBlueMatt · 2026-01-20T19:31:20Z

Fair enough. It does look like its just a conflict cause there's a deref-bounded auto-impl, which shouldn't be crazy to fix. Would have to go actually try to be sure though.

tnull

Seems this needs yet another rebase unfortunately!

Useful for upcoming commits where we otherwise break SemVer checks by changing the ALiquidityManager associated types.

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Unfortunately the same improvement can't be made for KVStoreSync and Persist, due to the blanket implementation where all KVStoreSync traits implement Persist resulting in conflicting implementations. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. This could be split into multiple commits (e.g. one for OnionMessenger message handler types, one for PeerManager message handler types) but it would require adding a new IgnoringOnionMessageHandler type for the messenger handlers, due to the IgnoringMessageHandler's Deref implementation conflicting otherwise. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

valentinewallace · 2026-01-30T15:23:28Z

Rebased

valentinewallace · 2026-01-30T22:11:20Z

Only change since @tnull's last ACK was a rebase, landing

valentinewallace · 2026-01-13T19:16:02Z

Reduces generics and verbosity across the codebase, should provide equivalent behavior.

Inspired by #4309 (comment). Basically, instead of Deref indirection we instead impl<T: Trait, D: Deref<Target = Trait>> Trait for D for all our traits.

The majority of the codebase's traits are done in this PR, but we do skip a good amount still. In a lot of cases traits are skipped because of compiler complaints about (potential-) conflicting trait implementations, but also ran into some lifetime issues and some c_bindings issues.

ldk-reviews-bot · 2026-01-13T19:16:05Z

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

valentinewallace · 2026-01-13T19:16:30Z

If this looks good and works for language bindings, I/claude can do it for all the other traits. I feel like this is a solid improvement.

valentinewallace · 2026-01-13T19:17:01Z

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

valentinewallace · 2026-01-13T19:19:56Z

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

TheBlueMatt · 2026-01-13T20:32:05Z

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

It means updating the generation logic to support it, but it certainly isn't directly problematic.

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

You can write it as impl<T: BroadcasterInterface, B: Deref<Target = T>> BroadcasterInterface for B { instead of impl<B: Deref<Target: BroadcasterInterface>> BroadcasterInterface for B {.

TheBlueMatt · 2026-01-13T20:32:28Z

Conceptually tho yea imo we should do this. Its "the right way" to do it in rust.

codecov · 2026-01-13T23:55:54Z

Codecov Report

❌ Patch coverage is 81.59722% with 212 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.98%. Comparing base (f9ad345) to head (101d206).
⚠️ Report is 19 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/msgs.rs	35.05%	126 Missing ⚠️
lightning/src/util/persist.rs	45.94%	20 Missing ⚠️
lightning/src/ln/channel.rs	93.85%	14 Missing ⚠️
lightning/src/ln/peer_handler.rs	70.58%	9 Missing and 1 partial ⚠️
lightning-background-processor/src/lib.rs	68.18%	7 Missing ⚠️
lightning/src/chain/channelmonitor.rs	91.02%	7 Missing ⚠️
lightning/src/util/anchor_channel_reserves.rs	0.00%	6 Missing ⚠️
lightning/src/chain/chainmonitor.rs	77.77%	4 Missing ⚠️
lightning/src/onion_message/messenger.rs	92.00%	4 Missing ⚠️
lightning-net-tokio/src/lib.rs	0.00%	3 Missing ⚠️
... and 6 more

Additional details and impacted files

@@ Coverage Diff @@## main #4311 +/- ##
==========================================
- Coverage 86.09% 85.98% -0.12% 
==========================================
Files 156 156 Lines 102804 102609 -195 Branches 102804 102609 -195 ==========================================
- Hits 88508 88225 -283 - Misses 11788 11873 +85 - Partials 2508 2511 +3

Flag	Coverage Δ
tests	`85.98% <81.59%> (-0.12%)`	⬇️

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.

tnull

Note that you'll need to bump lightning-liquidity's version to 0.3.0+git to get the SemVer checks to pass, as it's an API-breaking change.

joostjager · 2026-01-15T18:42:15Z

Is the Logger a candidate too for this?

valentinewallace · 2026-01-15T18:49:01Z

Is the Logger a candidate too for this?

Yes, I will un-draft the PR once all the traits are complete :)

ldk-reviews-bot · 2026-01-15T19:18:08Z

🔔 1st Reminder

Hey @TheBlueMatt! 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.

joostjager · 2026-01-15T22:26:38Z

 	fn message_received(&self);
 }

+impl<T: ChannelMessageHandler + ?Sized, C: Deref<Target = T>> ChannelMessageHandler for C {


Is this really better than using Arc instead of Deref, and accepting that for no-std the API might look slightly different?
There aren't that many no-std projects.

Yeah maybe we should resolve this here #4309 (comment) before moving forward with this direction? Is it still difficult to add new trait params now that we have Claude?

Ask Claude to add a logger to ChannelMonitor, and then report back 😂

valentinewallace · 2026-01-20T17:26:20Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

TheBlueMatt · 2026-01-20T19:18:34Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

valentinewallace · 2026-01-20T19:24:26Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.
It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

I'm aware, but I'm not sure if it's something that should be fixed or whether the new rust-lightning API isn't good. Thought he might know off the top of his head :p

TheBlueMatt · 2026-01-20T19:31:20Z

Fair enough. It does look like its just a conflict cause there's a deref-bounded auto-impl, which shouldn't be crazy to fix. Would have to go actually try to be sure though.

tnull

Seems this needs yet another rebase unfortunately!

Useful for upcoming commits where we otherwise break SemVer checks by changing the ALiquidityManager associated types.

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Unfortunately the same improvement can't be made for KVStoreSync and Persist, due to the blanket implementation where all KVStoreSync traits implement Persist resulting in conflicting implementations. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. This could be split into multiple commits (e.g. one for OnionMessenger message handler types, one for PeerManager message handler types) but it would require adding a new IgnoringOnionMessageHandler type for the messenger handlers, due to the IgnoringMessageHandler's Deref implementation conflicting otherwise. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

valentinewallace · 2026-01-30T15:23:28Z

Rebased

valentinewallace · 2026-01-30T22:11:20Z

Only change since @tnull's last ACK was a rebase, landing

valentinewallace · 2026-01-13T19:16:02Z

Reduces generics and verbosity across the codebase, should provide equivalent behavior.

Inspired by #4309 (comment). Basically, instead of Deref indirection we instead impl<T: Trait, D: Deref<Target = Trait>> Trait for D for all our traits.

The majority of the codebase's traits are done in this PR, but we do skip a good amount still. In a lot of cases traits are skipped because of compiler complaints about (potential-) conflicting trait implementations, but also ran into some lifetime issues and some c_bindings issues.

ldk-reviews-bot · 2026-01-13T19:16:05Z

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

valentinewallace · 2026-01-13T19:16:30Z

If this looks good and works for language bindings, I/claude can do it for all the other traits. I feel like this is a solid improvement.

valentinewallace · 2026-01-13T19:17:01Z

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

valentinewallace · 2026-01-13T19:19:56Z

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

TheBlueMatt · 2026-01-13T20:32:05Z

@TheBlueMatt would appreciate conceptual review to make sure this works for the language bindings.

It means updating the generation logic to support it, but it certainly isn't directly problematic.

Actually, it looks like this might not work for 1.75 (associated type bounds are unstable). Not sure if we plan on bumping that anytime soon?

You can write it as impl<T: BroadcasterInterface, B: Deref<Target = T>> BroadcasterInterface for B { instead of impl<B: Deref<Target: BroadcasterInterface>> BroadcasterInterface for B {.

TheBlueMatt · 2026-01-13T20:32:28Z

Conceptually tho yea imo we should do this. Its "the right way" to do it in rust.

codecov · 2026-01-13T23:55:54Z

Codecov Report

❌ Patch coverage is 81.59722% with 212 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.98%. Comparing base (f9ad345) to head (101d206).
⚠️ Report is 19 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/msgs.rs	35.05%	126 Missing ⚠️
lightning/src/util/persist.rs	45.94%	20 Missing ⚠️
lightning/src/ln/channel.rs	93.85%	14 Missing ⚠️
lightning/src/ln/peer_handler.rs	70.58%	9 Missing and 1 partial ⚠️
lightning-background-processor/src/lib.rs	68.18%	7 Missing ⚠️
lightning/src/chain/channelmonitor.rs	91.02%	7 Missing ⚠️
lightning/src/util/anchor_channel_reserves.rs	0.00%	6 Missing ⚠️
lightning/src/chain/chainmonitor.rs	77.77%	4 Missing ⚠️
lightning/src/onion_message/messenger.rs	92.00%	4 Missing ⚠️
lightning-net-tokio/src/lib.rs	0.00%	3 Missing ⚠️
... and 6 more

Additional details and impacted files

@@ Coverage Diff @@## main #4311 +/- ##
==========================================
- Coverage 86.09% 85.98% -0.12% 
==========================================
Files 156 156 Lines 102804 102609 -195 Branches 102804 102609 -195 ==========================================
- Hits 88508 88225 -283 - Misses 11788 11873 +85 - Partials 2508 2511 +3

Flag	Coverage Δ
tests	`85.98% <81.59%> (-0.12%)`	⬇️

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.

tnull

Note that you'll need to bump lightning-liquidity's version to 0.3.0+git to get the SemVer checks to pass, as it's an API-breaking change.

joostjager · 2026-01-15T18:42:15Z

Is the Logger a candidate too for this?

valentinewallace · 2026-01-15T18:49:01Z

Is the Logger a candidate too for this?

Yes, I will un-draft the PR once all the traits are complete :)

ldk-reviews-bot · 2026-01-15T19:18:08Z

🔔 1st Reminder

Hey @TheBlueMatt! 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.

joostjager · 2026-01-15T22:26:38Z

 	fn message_received(&self);
 }

+impl<T: ChannelMessageHandler + ?Sized, C: Deref<Target = T>> ChannelMessageHandler for C {


Is this really better than using Arc instead of Deref, and accepting that for no-std the API might look slightly different?
There aren't that many no-std projects.

Yeah maybe we should resolve this here #4309 (comment) before moving forward with this direction? Is it still difficult to add new trait params now that we have Claude?

Ask Claude to add a logger to ChannelMonitor, and then report back 😂

valentinewallace · 2026-01-20T17:26:20Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

TheBlueMatt · 2026-01-20T19:18:34Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.

It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

valentinewallace · 2026-01-20T19:24:26Z

@tnull do you have any idea if the LDK Node API CI failure is easy to fix on the LDK Node end? Otherwise I can drop the KVStore update commit.
It is now the responsibility of rust-lightning PR authors to go fix ldk-node if your PR breaks it :p

I'm aware, but I'm not sure if it's something that should be fixed or whether the new rust-lightning API isn't good. Thought he might know off the top of his head :p

TheBlueMatt · 2026-01-20T19:31:20Z

Fair enough. It does look like its just a conflict cause there's a deref-bounded auto-impl, which shouldn't be crazy to fix. Would have to go actually try to be sure though.

tnull

Seems this needs yet another rebase unfortunately!

Useful for upcoming commits where we otherwise break SemVer checks by changing the ALiquidityManager associated types.

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Unfortunately the same improvement can't be made for KVStoreSync and Persist, due to the blanket implementation where all KVStoreSync traits implement Persist resulting in conflicting implementations. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. This could be split into multiple commits (e.g. one for OnionMessenger message handler types, one for PeerManager message handler types) but it would require adding a new IgnoringOnionMessageHandler type for the messenger handlers, due to the IgnoringMessageHandler's Deref implementation conflicting otherwise. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

valentinewallace · 2026-01-30T15:23:28Z

Rebased

valentinewallace · 2026-01-30T22:11:20Z

Only change since @tnull's last ACK was a rebase, landing

valentinewallace requested a review from TheBlueMatt January 13, 2026 19:17

valentinewallace force-pushed the 2026-01-avoid-derefs branch from 1c6cf54 to 584fec7Compare January 13, 2026 22:34

valentinewallace commented Jan 13, 2026
View reviewed changes

Comment threadlightning/src/chain/chaininterface.rs

tnull reviewed Jan 14, 2026
View reviewed changes

valentinewallace force-pushed the 2026-01-avoid-derefs branch from 584fec7 to ad7aaa5Compare January 15, 2026 00:18

valentinewallace added this to Weekly Goals Jan 15, 2026

valentinewallace self-assigned this Jan 15, 2026

valentinewallace removed the request for review from TheBlueMatt January 15, 2026 19:26

valentinewallace force-pushed the 2026-01-avoid-derefs branch from ad7aaa5 to 028f1fbCompare January 15, 2026 21:49

joostjager reviewed Jan 15, 2026
View reviewed changes

valentinewallace force-pushed the 2026-01-avoid-derefs branch from 028f1fb to 3630b91Compare January 20, 2026 17:18

valentinewallace changed the title ~~Drop Deref indirection for ChannelManager, etc~~Drop Deref indirection for most trait parametersJan 20, 2026

valentinewallace force-pushed the 2026-01-avoid-derefs branch from 3630b91 to 2ceb510Compare January 20, 2026 17:22

valentinewallace force-pushed the 2026-01-avoid-derefs branch from 2ceb510 to db87b32Compare January 20, 2026 18:47

valentinewallace marked this pull request as ready for review January 20, 2026 18:48

ldk-reviews-bot requested a review from wpaulino January 20, 2026 18:49

valentinewallace requested review from jkczyz and tnull January 29, 2026 22:33

jkczyz previously approved these changes Jan 29, 2026
View reviewed changes

tnull reviewed Jan 30, 2026
View reviewed changes

valentinewallaceand others added 16 commits January 30, 2026 10:11

Bump lightning-liquidity version
26f6cbb
Useful for upcoming commits where we otherwise break SemVer checks by changing the ALiquidityManager associated types.

Drop Deref indirection for BroadcasterInterface
aa9feac
Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Drop Deref indirection for EntropySource
32e6e10
Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Drop Deref indirection for NodeSigner
fb2759e
Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Drop Deref indirection for FeeEstimator
b6f3670
Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Drop Deref indirection for Router
3f8f1ba
Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Drop Deref indirection for MessageRouter
dcb81f9
Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Drop Deref indirection for Logger
ac8074e
Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Drop Deref indirection for SignerProvider
9432adb
Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Drop Deref indirection for chain::Watch
54a8858
Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Drop Deref indirection for NodeIdLookup
9e81ce9
Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Drop Deref indirection for chain::Filter
f60a33f
Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Drop Deref indirection for OutputSpender
644ca0c
Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

Drop Deref indirection for UtxoLookup
101d206
Reduces generics and verbosity across the codebase, should provide equivalent behavior. Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>

valentinewallace dismissed jkczyz’s stale review via 101d206January 30, 2026 15:21

valentinewallace force-pushed the 2026-01-avoid-derefs branch from 4c0875a to 101d206Compare January 30, 2026 15:21

valentinewallace requested review from jkczyz and tnull January 30, 2026 16:32

jkczyz approved these changes Jan 30, 2026
View reviewed changes

valentinewallace merged commit 44b9529 into lightningdevkit:mainJan 30, 2026
20 of 21 checks passed

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

wpaulino mentioned this pull request Feb 5, 2026
Support async signing of interactive-tx initial commitment signatures #4355
Merged