From 2600b6f6822e643703d35c14d83b8cef6a8c36f3 Mon Sep 17 00:00:00 2001 From: Carla Kirk-Cohen Date: Fri, 26 May 2023 13:52:09 -0400 Subject: [PATCH] f Include incoming in-flight HLTCs in reputation calculations --- 04-onion-routing.md | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/04-onion-routing.md b/04-onion-routing.md index 68a6ecccf..53a0468ec 100644 --- a/04-onion-routing.md +++ b/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