draft: outgoing reputation writup #5

carlaKC · 2025-05-02T15:34:53Z

No description provided.

elnosh · 2025-05-14T21:20:07Z

recommendations/local-resource-conservation.md

+We define the `opportunity_cost` of the time a HTLC takes to resolve:
+`opportunity_cost`: `ceil ( (resolution_time - resolution_period) / resolution_period) - fees`


this should be * fees instead of - fees

elnosh · 2025-05-14T21:29:13Z

recommendations/local-resource-conservation.md

+    - Otherwise:
+      - The HTLC is dropped to protect its upstream resources from being 
+        saturated by the downstream peer.
+- If any forwarding node receives an `update_add_htlc` with `accountable` set,
+  but the outgoing channel does not have sufficient reputation:
+  - The HTLC is dropped to protect its upstream reputation from the downstream
+    peer.


I'm not quite clear what is the difference between these 2 points where they seem to be for the same. Which is to drop the HTLC if the outgoing channel does not have sufficient reputation.

Indeed, I'll reorder this a bit to clean it up.

elnosh · 2025-05-14T21:31:30Z

recommendations/local-resource-conservation.md

+- MUST NOT allocate more liquidity than their `capacity_msat` across buckets.
+
+Recommended Defaults:
+- General: 40% of `max_accepted_htlcs` and `capacity_msat`.
+- Congestion: 20% of `max_accepted_htlcs` and `capacity_msat`.
+- Protected: 40% of `max_accepted_htlcs` and `capacity_msat`.


I think these should be max_htlc_value_in_flight_msat instead of capacity_msat?

elnosh · 2025-05-14T21:33:13Z

recommendations/local-resource-conservation.md

+- [Local Reputation](#local-reputation)
+  - [Recommendations for Reputation Scoring](#recommendations-for-reputation-scoring)
+    - [Effective HTLC Fees](#effective-htlc-fees)
+    - [Outgoing Channel Revenue](#outgoing-channel-revenue)


*outgoing-channel-reputation

recommendations/local-resource-conservation.md

carlaKC · 2025-05-27T16:56:11Z

recommendations/local-resource-conservation.md

+HTLC forwards are assigned resources as follows:
+- If `accountable` is set in the received `update_add_htlc`:
+  - If the outgoing peer has sufficient reputation:
+    - SHOULD forward the HTLC, assigning usage to the protected bucket.


The protected bucket section says that you can use general/congested if requied.

Is it clear that you should try use protected and fall back if necessary?

Don't want it to be interpreted as:

Try protected bucket

End up using general

Still count towards protected bucket count

I think it could also be interpreted as "fail the HTLC if protected is full" (without the fall back on other buckets).

lightning-rfc/recommendations/local-resource-conservation.md

Lines 327 to 328 in 458fa0a

If a HTLC is assigned a bucket that does not have sufficient resources, it

SHOULD be failed back with `temporary_channel_failure`.

In the Resource Bucketing section says If a HTLC is assigned a bucket that does not have sufficient resources, it SHOULD be failed back which could be contradicting this part.

Hm yeah indeed, I'll think about a better way to describe this.

carlaKC · 2025-06-03T15:24:20Z

recommendations/local-resource-conservation.md

+reputation can operate as usual during periods of attack. If this bucket is
+full, HTLCs that were eligible to use it may utilize any other available 
+resources in general or congestion buckets.


One thing that's unfortunate about this approach is that previously we didn't need to track the protected bucket, we could just forward HTLCs if they were protected and rely on our channel tracking its own balance to allow payments through (or not).

Don't think there's much we can do about this, just noticed it on implementation.

ClaraShk · 2025-06-17T15:24:26Z

recommendations/local-resource-conservation.md

+
+Channel jamming is a known denial-of-service attack against the Lightning 
+Network. An attacker can disrupt regular usage of the network by spamming it
+with doomed-to-fail payments, or simply delaying resolution of (their own or


"doomed-to-fail" is a bit strange, maybe with "payments they intend to fail"?

ClaraShk · 2025-06-17T15:28:14Z

recommendations/local-resource-conservation.md

+  for the fast resolution of the HTLC. This signal is originally provided by 
+  the recipient, and is propagated along the route.
+- [Resource Bucketing](#resource-bucketing): restrictions on the HTLCs that 
+  will be forwarded to outgoing nodes with insufficient reputation that may


nodes with good reputation will also have some restrictions in general and congestion

ClaraShk · 2025-06-17T17:15:48Z

recommendations/local-resource-conservation.md

+slow resolving payments (regardless of successful resolution).
+
+We define the following parameters: 
+- `resolution_period`: the amount of time a HTLC is allowed to resolve in that 


add "," to resolve in, that

ClaraShk · 2025-06-17T17:19:03Z

recommendations/local-resource-conservation.md

+`opportunity_cost = ceil ( (resolution_time - resolution_period) / resolution_period) * fees`
+`
+Given that `resolution_time` will be > 0 in practice, `opportunity_cost` is 0 
+for HTLCs that resolve within `resolution_period`, and charges the `fees` that 


confusing choice of words "and charges the fees that
the HTLC would have earned per period it is held thereafter."

ClaraShk · 2025-06-17T17:22:11Z

recommendations/local-resource-conservation.md

+
+We define the `outgoing_channel_reputation`: 
+- for each `update_add_htlc` offered on the outgoing channel over 
+  the rolling window [`now` - `revenue_window` -  `reputation_multiplier`; `now`]: 


revenue_window - reputation_multiplier -> revenue_window * reputation_multiplier

ClaraShk · 2025-06-17T17:25:15Z

recommendations/local-resource-conservation.md

+The outstanding risk of an `update_add_htlc` is defined as follows:
+- `height_added`: the block height at which the HTLC was irrevocably committed 
+  to by the local node.
+- `maximum_hold_blocks` = `cltv_expiry` - `height_added`


maybe "+" and not "-"?

This is correct - if the HTLC expires at height 150 and it's currently height 100, it can be held for 50 blocks max before we force close.

ClaraShk · 2025-06-17T17:25:56Z

recommendations/local-resource-conservation.md

+- `height_added`: the block height at which the HTLC was irrevocably committed 
+  to by the local node.
+- `maximum_hold_blocks` = `cltv_expiry` - `height_added`
+- `outstanding_risk` = `fees * ( maximum_hold_blocks * 10 * 60) / resolution_period`


say that 10*60 is the 10 min. per block?

ClaraShk · 2025-06-17T17:27:11Z

recommendations/local-resource-conservation.md

+We define the `in_flight_htlc_risk` for an outgoing channel as:
+- for each `update_add_htlc` offered to the outgoing channel:
+  - if `accountable` is present:
+    - if there is a corresponding incoming `update_add_htlc`


not sure what this means if there is update_add_htlc offered

"offered" is spec-speak for when we send our peer a HTLC we want them to add

ClaraShk · 2025-06-17T17:29:09Z

recommendations/local-resource-conservation.md

+accrue on the channel, it is pairwise valuable to the local node. In flight 
+HTLCs have no impact on incoming channel revenue, as their fee contribution is 
+unknown.
+##### Rationale


do we need to paragraphs with this title?

ClaraShk · 2025-06-17T17:36:19Z

recommendations/local-resource-conservation.md

+- The onion packet has `upgrade_accountability` set.
+- The incoming `update_add_htlc` does not have `accountable` set.
+- The `amount_msat` < `bucket_capacity_msat` / `bucket_slots`.
+


No #### Rationale for congestion

The recipient of a payment is ultimately responsible for the fast resolution of a payment (though intermediate node can, of course, slow it down). We add a signal from the final recipient that the sender can use to reason about the amount of time it should take to resolve.

Once we have a signal from the recipient, we need a way to propagate this information throughout the route. Including a signal in the onion provides an uncorruptable way for the sender to propagate this signal. If the sender is dishonest, this will eventually be detected by the final recipient. In the commits that follow we'll add reputation and resource management that will allow nodes to use this signal to protect against jamming attacks.

carlaKC force-pushed the dev-jamming-endorsement-specification branch from d81c1f1 to 4eac67f Compare May 2, 2025 15:38

carlaKC mentioned this pull request May 13, 2025

Implement Current Proposal Draft carlaKC/jam-ln#56

Closed

elnosh reviewed May 14, 2025

View reviewed changes

elnosh reviewed May 19, 2025

View reviewed changes

recommendations/local-resource-conservation.md Outdated Show resolved Hide resolved

carlaKC force-pushed the dev-jamming-endorsement-specification branch 2 times, most recently from a158157 to 33f6af2 Compare May 27, 2025 14:44

carlaKC commented May 27, 2025

View reviewed changes

carlaKC commented Jun 3, 2025

View reviewed changes

ClaraShk reviewed Jun 17, 2025

View reviewed changes

carlaKC mentioned this pull request Jul 16, 2025

Project Updates: Hybrid Channel Jamming Mitigation lightning/bolts#1218

Open

23 tasks

carlaKC added 2 commits August 12, 2025 10:46

carlaKC force-pushed the dev-jamming-endorsement-specification branch 2 times, most recently from 3440b32 to 34d469c Compare August 13, 2025 13:39

recommendations: write up full system of reputation

4c35777

carlaKC force-pushed the dev-jamming-endorsement-specification branch from 34d469c to 4c35777 Compare August 13, 2025 14:06

carlaKC closed this Sep 15, 2025

		We define the `opportunity_cost` of the time a HTLC takes to resolve:
		`opportunity_cost`: `ceil ( (resolution_time - resolution_period) / resolution_period) - fees`

	If a HTLC is assigned a bucket that does not have sufficient resources, it
	SHOULD be failed back with `temporary_channel_failure`.

draft: outgoing reputation writup #5

draft: outgoing reputation writup #5

Uh oh!

Conversation

carlaKC commented May 2, 2025

Uh oh!

elnosh May 14, 2025 • 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!

elnosh May 14, 2025 • 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!

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!

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!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

elnosh May 14, 2025 •

edited

Loading

elnosh May 14, 2025 •

edited

Loading