f Include incoming in-flight HLTCs in reputation calculations

04-onion-routing.md

@@ -1454,10 +1454,10 @@ forward unendorsed HTLCs that they are not certain about.
 HTLC resolution time is assessed relative to a threshold that the node 
 considers to be a reasonable amount of time for a HTLC to resolve: 
 - `resolution_period`: the amount of time a HTLC is allowed to resolve in that 
-  is classified as "good" behavior (default: 10 seconds).
+  is classified as "good" behavior, expressed in seconds (default: 10 seconds).
 - `resolution_time`: the time elapsed between `update_add_htlc` and its 
   resolution (`update_fulfill_hltc` / `update_fail_hltc` / 
-  `update_fail_malformed_htlc`).
+  `update_fail_malformed_htlc`), expressed in seconds.
 
 Each HTLC's contribution to reputation is expressed by its `effective_fees` 
 which capture the fees that it paid and the opportunity cost that holding it 
@@ -1473,8 +1473,8 @@ for the slot and liquidity that could have otherwise been paid for by
 successful, fast resolving HTLCs during the `resolution_time` the HTLC was 
 locked in the channel.
 
-For every incoming HLTC a peer has forwarded through a node, its `effective_fees` 
-are calculated as follows:
+For every resolved incoming HLTC a peer has forwarded through a node, its 
+`effective_fees` are calculated as follows:
 - if `endorsed` = 1 in `update_add_htlc`:
   - `effective_fees` = `fees` - `opportunity_cost` 
 - otherwise: 
@@ -1483,6 +1483,14 @@ are calculated as follows:
   - otherwise: 
     - `effective_fees` = 0
 
+Incoming in-flight HTLCs have a negative impact on reputation, as their 
+influence is unknown until time of resolution. The `outstanding_risk` of each 
+in flight HTLC is calculated as follows: 
+- if `endorsed` = 1 in `update_add_htlc`:
+  - `outstanding_risk` = `fees` * ( `cltv_expiry` - `height_added` * 10 * 60), 
+    where `height_added` is the block height at which the HLTC was irrevocably
+    committed to by the receiving node.
+
 The `effective_fees` that a peer has paid our node are compared to our total 
 routing revenue to classify a peer's reputation as "good" or "neutral". This
 relates the fees that must be paid to earn "good" reputation to the damage that 
@@ -1497,7 +1505,8 @@ recent routing patterns, and longer windows aggregating trends over time.
   assessed (default: 10 minutes * the maximum number of blocks a HTLC may be
   held before the node will send `expiry_too_far`, as outlined in [Failure Messages](#failure-messages)).
 - `routing_revenue`: the sum of all fees paid to the node to forward HTLCs
-  over the interval [ `now` - `routing_window` ; `now` ].
+  over the interval [ `now` - `routing_window` ; `now` ] less the sum of 
+  `outstanding_risk` for all incoming, in-flight HLTCs.
 
 The total `effective_fees` that an individual peer has generated are assessed
 over a longer period of time to relate its reputation classification to the 
@@ -1533,6 +1542,13 @@ allows new, unendorsed entrants to slowly build reputation over time. The fee
 contribution of unendorsed HTLCs is discounted by 50% to incentivise nodes to 
 endorse HTLCs.
 
+In flight HLTCs are included in reputation scoring to account for sudden changes
+in a peer's behavior. Even when good reputation is obtained, each HTLC choosing 
+to take advantage of that good reputation is treated as if it will be used to 
+inflict maximum damage. The expiry height of each incoming in flight HLTC is 
+considered so that risk is directly related to the amount of time the HTLC 
+could be held in the channel, and 10 minute blocks are assumed for simplicity.
+
 # Test Vector
 
 ## Returning Errors