resource manager trait and impl by elnosh · Pull Request #4409 · lightningdevkit/rust-lightning

elnosh · 2026-02-10T22:44:23Z

Part of #4384

This PR introduces a ResourceManager trait and DefaultResourceManager implementation of that trait which is based on the proposed mitigation in lightning/bolts#1280.

It only covers the standalone implementation of the mitigation. I have done some testing with integrating it into the ChannelManager but that can be done separately. As mentioned in the issue, the resource manager trait defines these 4 methods to be called from the channel manager:

add_channel
remove_channel
add_htlc
resolve_htlc

Integrating into the `ChannelManager`

The ResourceManager is intended to be internal to the ChannelManager rather than users instantiating their own and passing it to a ChannelManager constructor.
add/remove_channel should be called when channels are opened/closed.
add_htlc: When processing HTLCs, the channel manager would call add_htlc which returns a ForwardingOutcome telling it whether to forward or fail the HTLC along with the accountable signal to use in case that it should be forwarded. For the initial "read-only" mode, the channel manager would log the results but not actually fail the HTLC if it was told to do so. A bit more specific on where it would be called: I think it will be when processing the forward_htlcs before we queue the add_htlc to the outgoing channel

rust-lightning/lightning/src/ln/channelmanager.rs

Line 7650 in caf0aac

if let Err((reason, msg)) = optimal_channel.queue_add_htlc(
resolve_htlc: Used to tell back the ResourceManager the resolution of an HTLC. It will be used to release bucket resources and update reputation/revenue values internally.

This could have more tests but opening early to get thoughts on design if possible

cc @carlaKC

ldk-reviews-bot · 2026-02-10T22:44:26Z

👋 Thanks for assigning @carlaKC 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 · 2026-02-11T01:27:46Z

Codecov Report

❌ Patch coverage is 93.77028% with 96 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.29%. Comparing base (94d1e5e) to head (41d3ba9).
⚠️ Report is 315 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/resource_manager.rs	93.77%	65 Missing and 31 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4409      +/-   ##
==========================================
+ Coverage   86.03%   86.29%   +0.26%     
==========================================
  Files         156      161       +5     
  Lines      103091   109078    +5987     
  Branches   103091   109078    +5987     
==========================================
+ Hits        88690    94134    +5444     
- Misses      11891    12286     +395     
- Partials     2510     2658     +148

Flag	Coverage Δ
tests	`86.29% <93.77%> (+0.26%)`	⬆️

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.

carlaKC

Really great job on this! Done an overly-specific first review round for something that's in draft because I've taken a look at previous versions of this code before when we wrote simulations. Also haven't looked at the tests in detail yet, but coverage is looking ✨ great ✨ .

I think that taking a look at tracking slot usage in GeneralBucket with a single source of truth is worth taking a look at, seems like it could clean up a few places where we need to two hashmap lookups one after the other.

In the interest of one day fuzzing this, I think it could also use some validation that enforces our protocol assumptions (eg, number of slots <= 483).

lightning/src/ln/resource_manager.rs

ldk-reviews-bot · 2026-02-13T14:07:40Z

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

elnosh · 2026-02-16T22:43:21Z

think I have addressed most of the comments code-wise. Still need to add some requested comments/docs changes.

elnosh · 2026-02-17T18:33:51Z

pushed more fixups addressing requests for adding docs/comments, lmk if those look good

carlaKC · 2026-02-20T06:39:35Z

lightning/src/ln/resource_manager.rs

+	/// Tracks the occupancy of HTLC slots in the bucket.
+	slots_occupied: Vec<bool>,
+
+	/// SCID -> (slots assigned, salt)
+	/// Maps short channel IDs to an array of tuples with the slots that the channel is allowed
+	/// to use and the current usage state for each slot. It also stores the salt used to
+	/// generate the slots for the channel. This is used to deterministically generate the
+	/// slots for each channel on restarts.
+	channels_slots: HashMap<u64, (Vec<(u16, bool)>, [u8; 32])>,


this shouldn't accidentally double-assign them.

Yeah it shouldn't (provided we don't have bugs), but tracking the same information (whether a slot is occupied) in multiple places is a design that allows for inconsistency / the possibility of bugs. If we have a single source of truth, we move from "shouldn't double assign" to "can't double assign".

Gave it a shot here, lmk what you think!

lightning/src/ln/resource_manager.rs

TheBlueMatt · 2026-02-22T23:23:33Z

First of all not sure why all your commit messages are line-wrapped at 40 chars, but you can use like 60 or 70 lol.

TheBlueMatt

A few comments, I think the design is fine, but startup resync may be annoying.

TheBlueMatt · 2026-02-22T23:33:21Z

lightning/src/ln/resource_manager.rs

+	}
+}
+
+/// Tracks an average value over multiple rolling windows to smooth out volatility.


I'm kinda confused by this struct. First of all, the docs here are wrong - we aren't tracking "multiple windows" we're tracking a rolling average over one window of window * window_count. The only difference between this and DecayingAverage is it tries to compensate for if we don't have enough data to actually go back window_count * window. Why shouldn't we just have DecayingAverage do that instead of having a separate struct here?

I think it makes sense to keep separate because the use of DecayingAverage for reputation differs from AggregatedWindowAverage when tracking revenue. For reputation, we want the DecayingAverage over the full window (24 weeks). For revenue, using AggregatedWindowAverage, we track the decaying average over the same window (24 weeks) but divide by window_count because we want the revenue for 2 weeks.

I agree that we want to track two different things here:

Reputation (as DecayingAverage): we want shocks to reflect, so that we can quickly react to a change in attacker behavior

Revenue (as AggregatedWindowAverage): we want to smooth shocks to track our peer's average revenue in two weeks over a window_count periods.

But ran some numbers and it does look like we're penalizing old data a bit too much with this approach, as mentioned below.

TheBlueMatt · 2026-02-22T23:35:03Z

lightning/src/ln/resource_manager.rs

+struct DecayingAverage {
+	value: i64,
+	last_updated_unix_secs: u64,
+	window: Duration,


You don't actually use window (only decay_rate) so we can drop it here.

yeah, I was keeping window for the decay_rate when reading back here https://github.com/elnosh/rust-lightning/blob/90943195bee498f34247f65a68a8511d57997aae/lightning/src/ln/resource_manager.rs#L1042-L1045

Seems okay to me to just write the decay_rate directly. We'd only need the window if we wanted to change the way that we calculate it, and that seems unlikely?

TheBlueMatt · 2026-02-22T23:50:05Z

lightning/src/ln/resource_manager.rs

+		// We are not concerned with the rounding precision loss for this value because it is
+		// negligible when dealing with a long rolling average.
+		Ok((self.aggregated_revenue_decaying.value_at_timestamp(timestamp_unix_secs)? as f64
+			/ window_divisor)


I don't buy this? Let's say our windows_tracked is 4 and we have some data for the last 3 windows. On average, those 3 windows worth of data data will have been multiplied by 0.62175 (https://www.wolframalpha.com/input?i=%28integral+from+0+to+3+%280.5+%5E+0.5%29+%5E+x%29+%2F+3) but then we divide it by three. Whereas if we only have data for a single-window, that data will multiplied by, on average, 0.845111 (https://www.wolframalpha.com/input?i=%28integral+from+0+to+1+%280.5+%5E+0.5%29+%5E+x%29+%2F+1), and then we'll divide by one. We have to factor in the decrease in the data from the decay as well as just the increased amount of data here.

lightning/src/ln/resource_manager.rs

TheBlueMatt · 2026-02-23T00:05:32Z

lightning/src/ln/resource_manager.rs

+	/// Tracks the occupancy of HTLC slots in the bucket.
+	slots_occupied: Vec<bool>,
+
+	/// SCID -> (slots assigned, salt)
+	/// Maps short channel IDs to an array of tuples with the slots that the channel is allowed
+	/// to use and the current usage state for each slot. It also stores the salt used to
+	/// generate the slots for the channel. This is used to deterministically generate the
+	/// slots for each channel on restarts.
+	channels_slots: HashMap<u64, (Vec<(u16, bool)>, [u8; 32])>,


Does the protection algorithm break if slots are allocated probabilistically? We could reduce implementation complexity a good bit if we just drop channel_slots entirely and generate the list of slots the channel can occupy any time we need it and allow two channels to occupy the same slot (presumably leading to some extra HTLC failures in that case?). This feels very much like a bloom filter problem where we should be able to reduce FPs somehow, though maybe it isn't quite the same because we actually do want conflicts to be "common".

TheBlueMatt · 2026-02-23T00:45:13Z

lightning/src/ln/resource_manager.rs

+	}
+}
+
+impl Readable for DefaultResourceManager {


Hmmmmmmmmmmmmmmmmmmm. Reconciliation on startup is gonna be tricky here. What happens if we accept an HTLC then restart and actually it never made it to disk in the ChannelMonitor? Theoretically this can be persisted as a part of ChannelManager and it should be consistent-ish, but Val is hard at work making it so that we don't have to persist ChannelManager at all.

Instead, I wonder how easy we can make it to rebuild this from HTLC information. It would require some additional integration into "LDK core" but hopefully not much. If we have some HTLCSlotUsage struct that we return from add_htlc in the ForwardingOutcome::Forward case, we could presumably shove that into the HTLCSource (as the lots are "on" the inbound channel) and rebuild the resource manager very cheaply.

What happens if we accept an HTLC then restart and actually it never made it to disk in the ChannelMonitor? Theoretically this can be persisted as a part of ChannelManager and it should be consistent-ish, but Val is hard at work making it so that we don't have to persist ChannelManager at all.

hmmmm yeah I thought about that but was operating under the assumption that by persisting along with the ChannelManager it should stay consistent.

In a world where we don't persist the ChannelManager I was exploring your suggestion to rebuild the resource manager from HTLC data we have on startup and came up with the approach here: elnosh@cdd0bf8 With some caveats, I think we can replay HTLCs by calling add_htlc on the ResourceManager so we would only need general HTLC information and no need to shove bucket/resourcemanager specific information into HTLCSource. We would basically need this HTLC info on startup. I added 2 helper methods in channel.rs and the replay on the ChannelManager could look like this https://github.com/elnosh/rust-lightning/blob/cdd0bf80cb200d370995c4f859645c0a54b3a798/lightning/src/ln/channelmanager.rs#L19303-L19366

With this, I was able to restart a node with pending HTLCs and replayed them fine in the resource manager using Channel data. The only field I would need to add to HTLCSource is incoming_accountable

The caveat is that reputation and in-flight-risk when replaying the HTLCs might be somewhat (slightly) different if the shutdown time was long because the current timestamp is different.

Another approach would be to store the specific bucket usage in the HTLCSource so we replay HTLCs and add them directly to the bucket they were before shutdown. I went with previous approach mentioned since I think that will be less intrusive in the channel manager and would require less resourcemanager-specific information to leak into the channel manager. Let me know what you think

My only question there is what the performance cost is. If we have 500 channels and have to replay a hundred HTLCs per channel how bad does it get?

I'd have to run it but, indeed, it is not optimal because for each outbound HTLC in each channel it needs to lookup the inbound htlc on the incoming channel. It could store the missing fields in the HTLCSource as well to avoid the inbound htlc lookup.

did alternative approach in 9094319

elnosh · 2026-03-03T14:02:20Z

I have pushed changes for majority of comments from last round - diff here.

The most notable things are:

added a PendingHTLCReplay to be passed from upstream by the ChannelManager to replay pending HTLCs on startup instead of writing them in the ResourceManager
Do not double-track HTLC slot occupancy in general bucket and only track them in slots_occupied.
Use ChaCha instead of sha256 for slot generation in general bucket
Added more test cases

ldk-reviews-bot · 2026-03-05T14:41:06Z

🔔 1st Reminder

Hey @carlaKC! 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 · 2026-03-07T14:41:45Z

🔔 2nd Reminder

Hey @carlaKC! 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 · 2026-03-09T14:42:45Z

🔔 3rd Reminder

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

carlaKC

Didn't review tests yet, main comment is about how we handle replays on restart (+ saving needing to persist a few things).

carlaKC · 2026-03-09T12:58:12Z

lightning/src/ln/resource_manager.rs

+struct DecayingAverage {
+	value: i64,
+	last_updated_unix_secs: u64,
+	window: Duration,


Seems okay to me to just write the decay_rate directly. We'd only need the window if we wanted to change the way that we calculate it, and that seems unlikely?

carlaKC · 2026-03-09T14:13:02Z

lightning/src/ln/resource_manager.rs

+	}
+}
+
+/// Tracks an average value over multiple rolling windows to smooth out volatility.


I agree that we want to track two different things here:

Reputation (as DecayingAverage): we want shocks to reflect, so that we can quickly react to a change in attacker behavior

Revenue (as AggregatedWindowAverage): we want to smooth shocks to track our peer's average revenue in two weeks over a window_count periods.

But ran some numbers and it does look like we're penalizing old data a bit too much with this approach, as mentioned below.

carlaKC · 2026-03-09T14:55:11Z

lightning/src/ln/resource_manager.rs

+			// TODO: could return the slots already assigned instead of erroring.
+			Entry::Occupied(_) => Err(()),


Meant that assign_slots_for_channel doesn't need &self at all - we can just pass in our_scid + per_channel_slots, return the slots/salt we're adding and then have the caller be responsible for adding these values to self.channel_slots.

Saves us a double lookup because we're looking up the entry in the caller (to see if we need to assign_slots_for_channel and looking up again here).

carlaKC · 2026-03-10T12:15:32Z

lightning/src/ln/resource_manager.rs

+		self.slots_used += 1;
+		self.liquidity_used += htlc_amount_msat;


nit: debug_assert that we never go over our _allocated values?

isn't that caught by the resources_available check above this?

Fair - it's just very cheap to do and a pretty fundamental part of the impl so figured why not?

lightning/src/ln/resource_manager.rs

elnosh · 2026-03-23T17:59:12Z

pushed changes addressing comments from last review. Changes to point out are to DecayingAverage and AggregatedWindowAverage addressing this comment #4409 (comment) I have added the test test_aggregated_window_average showing how the aggregate average approximates the real value.

lightning/src/ln/resource_manager.rs

ldk-claude-review-bot · 2026-03-23T18:04:31Z

lightning/src/ln/resource_manager.rs

+	fn value_at_timestamp(&mut self, timestamp_unix_secs: u64) -> Result<i64, ()> {
+		if timestamp_unix_secs < self.last_updated_unix_secs {
+			return Err(());
+		}
+
+		let elapsed_secs = (timestamp_unix_secs - self.last_updated_unix_secs) as f64;
+		let decay_rate = 0.5_f64.powf(elapsed_secs / self.half_life);
+		self.value = (self.value as f64 * decay_rate).round() as i64;
+		self.last_updated_unix_secs = timestamp_unix_secs;


Issue: value_at_timestamp mutates last_updated_unix_secs on every call, making it a one-way ratchet. If any caller passes a timestamp slightly ahead of the current time (e.g., due to clock skew, NTP adjustment, or VM migration), all subsequent calls with the "correct" time will return Err(()) until the wall clock catches up.

In resolve_htlc, this manifests as: one call with resolved_at slightly in the future poisons the channel's outgoing_reputation.last_updated_unix_secs. All subsequent add_htlc calls fail (line 768 calls value_at_timestamp(added_at) which returns Err), effectively blocking all HTLC forwarding through this outgoing channel until the system clock reaches the poisoned timestamp.

Consider clamping to max(timestamp, last_updated) instead of returning Err, or using monotonic timestamps internally. Alternatively, at minimum, document that callers must guarantee strictly non-decreasing timestamps to avoid bricking a channel's forwarding.

Consider clamping to max(timestamp, last_updated)

This seems fine to me, it'll just mean that we think our HTLC is held for a second or two more than we expect which isn't critical.

Discussed offline: go with clamping because we need to be able to clear out HTLCs - if we happen to have clock drift on a HTLC remove, it'll get stuck so we can't actually error on the remove path at all or we risk "stuck resources".

lightning/src/ln/resource_manager.rs

carlaKC · 2026-03-25T12:39:20Z

lightning/src/ln/resource_manager.rs

+	fn value_at_timestamp(&mut self, timestamp_unix_secs: u64) -> Result<i64, ()> {
+		if timestamp_unix_secs < self.last_updated_unix_secs {
+			return Err(());
+		}
+
+		let elapsed_secs = (timestamp_unix_secs - self.last_updated_unix_secs) as f64;
+		let decay_rate = 0.5_f64.powf(elapsed_secs / self.half_life);
+		self.value = (self.value as f64 * decay_rate).round() as i64;
+		self.last_updated_unix_secs = timestamp_unix_secs;


Consider clamping to max(timestamp, last_updated)

This seems fine to me, it'll just mean that we think our HTLC is held for a second or two more than we expect which isn't critical.

lightning/src/ln/resource_manager.rs

Implements a decaying average over a rolling window. It will be used in upcoming commits by the resource manager to track reputation and revenue of channels.

The AggregatedWindowAverage implemented here will be used in upcoming commits to track the incoming revenue that channels have generated through HTLC forwards.

Resources available in the channel will be divided into general, congestion and protected resources. Here we implement the general bucket with basic denial of service protections. Co-authored-by: Carla Kirk-Cohen <kirkcohenc@gmail.com>

Resources available in the channel will be divided into general, congestion and protected resources. Here we implement the bucket resources that will be used for congestion and protected.

The Channel struct introduced here has the core information that will be used by the resource manager to make forwarding decisions on HTLCs: - Reputation that this channel has accrued as an outgoing link in HTLC forwards. - Revenue (forwarding fees) that the channel has earned us as an incoming link. - Pending HTLCs this channel is currently holding as an outgoing link. - Bucket resources that are currently in use in general, congestion and protected.

Introduces the DefaultResourceManager struct. The core of methods that will be used to inform the HTLC forward decisions are add/resolve_htlc. - add_htlc: Based on resource availability and reputation, it evaluates whehther to forward or fail the HTLC. - resolve_htlc: Releases the bucket resources used from a HTLC previously added and updates the channel's reputation based on HTLC fees and resolution times.

Adds write and read implementations to persist the DefaultResourceManager.

lightning/src/ln/resource_manager.rs

carlaKC

Discussed error handling offline in a bit more detail:

Error if we create a resource manager that has invalid configuration (we won't right now, because it's hardcoded but in general we shouldn't start if we're given a bad config).
debug_assert that we don't fail on add/remove_htlc in channelmanager
Failures on adding Channel::new means that the channel is too small to meaningfully protect, we return an error from add_channel and log in channelmanager

carlaKC · 2026-03-31T14:23:33Z

lightning/src/ln/resource_manager.rs

+}
+
+impl AggregatedWindowAverage {
+	fn new(avg_weeks: u8, window_multiplier: u8, start_timestamp_unix_secs: u64) -> Self {


We should fail if avg_weeks/window_multiplier are 0?

carlaKC · 2026-03-31T14:53:09Z

lightning/src/ln/resource_manager.rs

+		let general_slot_allocation =
+			u8::max(5, u8::try_from((slots_allocated * 5).div_ceil(100)).unwrap());
+
+		let general_liquidity_allocation =


nit: can be per_slot_msat so that we can use shorthand field init below

carlaKC · 2026-03-31T15:02:48Z

lightning/src/ln/resource_manager.rs

+		// General bucket will assign 5 slots of 500 per channel. Max 5 * 500 = 2500
+		// Adding an HTLC over the amount should return error.
+		let add_htlc_res = general_bucket.add_htlc(scid, htlc_amount_over_max, &entropy_source);


nit: in these tests, add asserts on the expectedper_channel_slots/per_slot_msat amounts so that we're certain we're testing the right thing

carlaKC · 2026-03-31T15:09:11Z

lightning/src/ln/resource_manager.rs

+		self.slots_used += 1;
+		self.liquidity_used += htlc_amount_msat;


Fair - it's just very cheap to do and a pretty fundamental part of the impl so figured why not?

carlaKC · 2026-03-31T16:55:07Z

lightning/src/ln/resource_manager.rs

+		debug_assert!(
+			general_bucket_slots_allocated >= 5,
+			"5 is the minimum we need for general bucket"
+		);


Eurgh sorry to do think but I think this should live in GeneralBucket - since the 5 consant isn't something that channel really knows about?

Likewise for liquidity, put the validation specific to the general bucket in its constructor and leave the rest out here.

carlaKC · 2026-03-31T17:49:11Z

lightning/src/ln/resource_manager.rs

+	fn read<R: Read>(
+		reader: &mut R, args: (u64, u16, &ResourceManagerConfig, &ES),
+	) -> Result<Self, DecodeError> {
+		let (max_htlc_value_in_flight_msat, max_accepted_htlcs, config, entropy_source) = args;


carlaKC · 2026-03-31T18:26:13Z

lightning/src/ln/resource_manager.rs

+	avg_weeks: u8,
+	window_weeks: u8,


avg_weeks -> average_duration
window_secs -> tracked_duration

+ use Duration (don't restrict to weeks granularity) + comments on vars

carlaKC · 2026-03-31T18:45:34Z

lightning/src/ln/resource_manager.rs

+impl GeneralBucket {
+	fn new(scid: u64, slots_allocated: u16, liquidity_allocated: u64) -> Self {
+		let general_slot_allocation =
+			u8::max(5, u8::try_from((slots_allocated * 5).div_ceil(100)).unwrap());


Pull 5 out into a constant, and validate slots_allocated >= 5, error if not.

Also have some sane check on liquidity_allocated to makes sure it doesn't round to 0.

carlaKC · 2026-03-31T18:56:25Z

lightning/src/ln/resource_manager.rs

+impl Channel {
+	fn new(
+		scid: u64, max_htlc_value_in_flight_msat: u64, max_accepted_htlcs: u16,
+		general_bucket_pct: u8, congestion_bucket_pct: u8, reputation_window: Duration,


Take BucketAllocations in rather than percentages and totals.

carlaKC · 2026-03-31T19:14:51Z

lightning/src/ln/resource_manager.rs

+		if resolved_at < pending_htlc.added_at_unix_seconds {
+			return Err(());
+		}


To look into: we don't want to get stuck in a scenario where we fail to remove a HTLC and it gets stuck using up resources even through it's been resolved.

We should optimistically remove the HTLC from the outgoing channel so that even if we fail we've still cleaned up our state.

If we know we're going to have several network roundtrips in here, I think it's safe to assume that our clock goes forward for an individual HTLC and keep this error. This is different for decaying averages (/clamping agreed on earlier) because they are dealing with different HTLCs which may happen in close proximity.

elnosh mentioned this pull request Feb 11, 2026

Proposed design for channel jamming mitigation #4384

Open

carlaKC self-requested a review February 11, 2026 07:04

carlaKC reviewed Feb 13, 2026

View reviewed changes

elnosh force-pushed the resource-mgr branch from 53a93ed to 056a65e Compare February 16, 2026 21:55

elnosh force-pushed the resource-mgr branch from 056a65e to 8fd724a Compare February 17, 2026 18:25

jkczyz assigned elnosh Feb 19, 2026

jkczyz added this to Weekly Goals Feb 19, 2026

carlaKC reviewed Feb 20, 2026

View reviewed changes

lightning/src/ln/resource_manager.rs Show resolved Hide resolved

carlaKC reviewed Feb 20, 2026

View reviewed changes

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

TheBlueMatt reviewed Feb 23, 2026

View reviewed changes

elnosh force-pushed the resource-mgr branch from 8fd724a to 9094319 Compare March 3, 2026 13:50

elnosh marked this pull request as ready for review March 3, 2026 14:38

ldk-reviews-bot requested a review from valentinewallace March 3, 2026 14:38

valentinewallace requested review from carlaKC and removed request for valentinewallace March 3, 2026 14:40

elnosh force-pushed the resource-mgr branch from 9094319 to 36a79b7 Compare March 6, 2026 18:30

elnosh mentioned this pull request Mar 6, 2026

Integrate resource manager into ChannelManager #4468

Draft

carlaKC reviewed Mar 10, 2026

View reviewed changes

elnosh force-pushed the resource-mgr branch from 36a79b7 to 34ecfd4 Compare March 23, 2026 17:28

elnosh force-pushed the resource-mgr branch from 34ecfd4 to 1b239db Compare March 23, 2026 17:45

ldk-claude-review-bot reviewed Mar 23, 2026

View reviewed changes

lightning/src/ln/resource_manager.rs Show resolved Hide resolved

ldk-claude-review-bot reviewed Mar 23, 2026

View reviewed changes

lightning/src/ln/resource_manager.rs Show resolved Hide resolved

elnosh force-pushed the resource-mgr branch from 1b239db to 41d3ba9 Compare March 23, 2026 17:55

ldk-claude-review-bot reviewed Mar 23, 2026

View reviewed changes

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

ldk-claude-review-bot reviewed Mar 23, 2026

View reviewed changes

lightning/src/ln/resource_manager.rs Show resolved Hide resolved

ldk-claude-review-bot reviewed Mar 23, 2026

View reviewed changes

carlaKC self-requested a review March 24, 2026 13:36

elnosh force-pushed the resource-mgr branch from 41d3ba9 to 6d68673 Compare March 24, 2026 16:45

ldk-claude-review-bot reviewed Mar 24, 2026

View reviewed changes

lightning/src/ln/resource_manager.rs Show resolved Hide resolved

ldk-claude-review-bot reviewed Mar 24, 2026

View reviewed changes

lightning/src/ln/resource_manager.rs Show resolved Hide resolved

carlaKC reviewed Mar 25, 2026

View reviewed changes

elnosh and others added 13 commits March 25, 2026 11:26

Add DecayingAverage to resource manager

8a394c9

Implements a decaying average over a rolling window. It will be used in upcoming commits by the resource manager to track reputation and revenue of channels.

f - test

88384e8

Add AggregatedWindowAverage to resource manager

3a78706

The AggregatedWindowAverage implemented here will be used in upcoming commits to track the incoming revenue that channels have generated through HTLC forwards.

f - change to take multiplier in AggregatedWindowAverage::new

c949142

Add GeneralBucket to resource manager

6311702

Resources available in the channel will be divided into general, congestion and protected resources. Here we implement the general bucket with basic denial of service protections. Co-authored-by: Carla Kirk-Cohen <kirkcohenc@gmail.com>

f - think it will be hard to hit this but added claude suggestion

49abbb4

Add BucketResources to resource manager

75c7d15

Resources available in the channel will be divided into general, congestion and protected resources. Here we implement the bucket resources that will be used for congestion and protected.

f - docs for consts used in error checks and added debug_asserts

8a8c05a

f - debug assert

5620033

impl write and read for resource manager

3a853cd

Adds write and read implementations to persist the DefaultResourceManager.

f - pass channel limits as readable args

1abc722

elnosh force-pushed the resource-mgr branch from 6d68673 to 1abc722 Compare March 31, 2026 13:21

ldk-claude-review-bot reviewed Mar 31, 2026

View reviewed changes

lightning/src/ln/resource_manager.rs Show resolved Hide resolved

elnosh mentioned this pull request Mar 31, 2026

fuzz resource manager #4527

Draft

carlaKC reviewed Mar 31, 2026

View reviewed changes

		// TODO: could return the slots already assigned instead of erroring.
		Entry::Occupied(_) => Err(()),

		self.slots_used += 1;
		self.liquidity_used += htlc_amount_msat;

Conversation

elnosh commented Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Integrating into the ChannelManager

Uh oh!

ldk-reviews-bot commented Feb 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented Feb 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

carlaKC left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ldk-reviews-bot commented Feb 13, 2026

Uh oh!

elnosh commented Feb 16, 2026

Uh oh!

elnosh commented Feb 17, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TheBlueMatt commented Feb 22, 2026

Uh oh!

TheBlueMatt left a comment

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!

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!

elnosh Feb 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

elnosh commented Mar 3, 2026

Uh oh!

ldk-reviews-bot commented Mar 5, 2026

Uh oh!

elnosh commented Feb 10, 2026 •

edited

Loading

Integrating into the `ChannelManager`

ldk-reviews-bot commented Feb 10, 2026 •

edited

Loading

codecov bot commented Feb 11, 2026 •

edited

Loading

elnosh Feb 25, 2026 •

edited

Loading