draft: Upfront Fees to Mitigate Channel Jamming #1052

carlaKC · 2023-01-18T19:56:53Z

This PR is an early stage draft of the upfront fees portion of the jamming mitigations proposed in Unjamming Lightning: A Systemic Approach.

It describes the minimal set of changes for the simplest iteration of upfront fees:

Channels advertise an upfront fee policy, which is charged on the outgoing edge for any routed htlcs
Upfront fees are simply assigned to the to_remote balance, with no on-chain output or secret that proves the htlc was actually forwarded
Recipients advertise upfront fees in bolt 11 invoices, and pad this value to hide their position in the route (route hints TBD)
The final hop's upfront fees contribute to the total_amt paid for a htlc set, so senders don't need to pay for recipient privacy

It is not ready for rigorous review yet, but has been opened here to assist discussion of various approaches to mitigating jamming in the lightning network.

Proof of concept code for LND is available here.

This commit adds a proposal summarizing the problem of channel jamming in lightning and proposing a combined approach using upfront fees and local reputation tracking. The details of local reputation tracking will be covered in a follow up PR. Co-authored-by: Clara Shikhelman <clara.shikhelman@gmail.com>

Upfront fees will require feature bit signaling because nodes need to know that their peers understand how to update their channel state machine with this new protocol feature.

Add the ability for nodes to advertise custom fee policies. A default value of 1% (for nodes that advertise that they understand the feature bit) is used to save the network the resources consumed relaying defaults. The TLV extension is odd to ensure that old nodes can still parse the extended gossip.

TODO: routing hints will also need updating

joostjager · 2023-01-18T20:33:45Z

proposals/channel-jamming-mitigation.md

+
+To save the network the bandwidth and storage required to transmit and save
+defaults, nodes that advertise `option_upfront_fee` in their node announcement
+should be assumed to have a base and proportional fee that is 1% of its success


It's a magic value, but if it is just a hard-coded default to potentially save bytes, it hardly hurts. If it turns out that nobody wants 1% and every channel update contains explicit upfront fees, then the only cost is the code to support the not-used default.

joostjager · 2023-01-18T20:35:36Z

proposals/channel-jamming-mitigation.md

+defaults, nodes that advertise `option_upfront_fee` in their node announcement
+should be assumed to have a base and proportional fee that is 1% of its success
+case fees. Nodes also will not relay and senders will not utilize channels with
+a `channel_update` messages where upfront fees are > 10% of their success-case


I am wondering if this does rule out certain use cases of upfront fees. As in very low success fees under the condition that you only request forwards that succeed. Otherwise you're penalized with a disproportionately high upfront fee.

This looks like it creates an incentive for failing, but maybe not because the sender will penalize nodes that fail.

joostjager · 2023-01-18T20:36:24Z

proposals/channel-jamming-mitigation.md

+The upfront fee amount should simply be assigned to the receiving party's 
+balance when an incoming HTLC is added. These amounts are not expected to be
+enforceable on-chain (as they are likely to be dust), so there is no need to 
+include an output for them in the channel's commitment transactions.


Suppose they wouldn't be dust, would you then create a separate output for it? I'd think that in that case it's still sufficient to just add to the receiver's balance?

Like @joostjager mentioned, wouldn't these amounts be directly embedded to the to_local & to_remote balances of the commitment txs?

joostjager · 2023-01-18T20:38:48Z

proposals/channel-jamming-mitigation.md

+nodes to advertise the upfront fees that it will accept for the final hop 
+(since there is no outgoing link for the sender to obtain a policy from). 
+```
+`u` (17) `data_length` 26:


For inbound fees, I also ran into the problem that multi-hop route hints aren't extensible: https://github.com/lightning/blips/pull/18/files#r988892046

joostjager · 2023-01-18T20:42:40Z

proposals/channel-jamming-mitigation.md

+received the total of 30,000 msat from the sender (29,700 paid via HTLCs in the
+set and 300 msat through upfront fees).
+
+Sending nodes can factor this upfront fee into the total amount they dispatch:


One thing is that with htlcs in-flight, the sender doesn't know yet whether the htlc will reach the final destination or not. If it does, the upfront fee counts towards the total amount. If it doesn't they just pay intermediate nodes do not increase the total amount at the receiver. Maybe this complicates implementation.

joostjager · 2023-01-18T20:50:03Z

04-onion-routing.md

+2. data:
+   * [`u64`:`upfront_fee`]
+   * [`u16`:`len`]
+   * [`len*byte`:`channel_update`]


We do have tlv failures now, so could make use of that. #1021

02-peer-protocol.md

+    - if `upfront_fee_msat` is included in the HTLC
+      - MUST be able to additionally pay for the `upfront_fee_msat` above its
+        reserve.
+      - MUST push the `upfront_fee_msat` amount to the remote party's balance,


04-onion-routing.md

      - it cannot forward the HTLC to the peer indicated by the channel `short_channel_id`.
      - incoming `amount_msat` - `fee` < `amt_to_forward` (where `fee` is the advertised fee as described in [BOLT #7](07-routing-gossip.md#htlc-fees))
      - `cltv_expiry` - `cltv_expiry_delta` < `outgoing_cltv_value`
+      - incoming `upfront_fee_msat` - `upfront_fee` < `upfront_fee_to_forward` (where `upfront_fee` is the advertised fee as described in [BOLT #7](07-routing-gossip.md#upfront-fees))


proposals/channel-jamming-mitigation.md

+
+An upfront fee, paid regardless of the outcome of a payment attempt, is proposed
+to economically compensate nodes for providing traffic with access to liquidity
+and slots. Simulations in [2] show that a fee of as little as 1% of the success


saubyk · 2023-02-04T00:01:02Z

proposals/channel-jamming-mitigation.md

+
+The sender can trivially solve for Y: 
+```
+X = Y + b + aY


shouldn't this equation be X = Y + a + bY?

GeorgeTsagk · 2023-02-07T20:59:54Z

proposals/channel-jamming-mitigation.md

+The upfront fee amount should simply be assigned to the receiving party's 
+balance when an incoming HTLC is added. These amounts are not expected to be
+enforceable on-chain (as they are likely to be dust), so there is no need to 
+include an output for them in the channel's commitment transactions.


Like @joostjager mentioned, wouldn't these amounts be directly embedded to the to_local & to_remote balances of the commitment txs?

GeorgeTsagk · 2023-02-07T21:01:20Z

proposals/channel-jamming-mitigation.md

+The upfront fee that should be sent to the next peer in the route is provided
+in the onion's payload. As is currently the case with htlc forwarding amounts, 
+the difference between the incoming `upfront_fee_msat` amount in 
+`update_add_htlc_tlvs` and the outgoing `upfront_fee_to_forwad` is used to 


nit: typo upfront_fee_to_forwad -> upfront_fee_to_forward

GeorgeTsagk · 2023-02-07T21:04:20Z

proposals/channel-jamming-mitigation.md

+```
+
+An upfront fee policy field is added to bolt-11 invoices to allow receiving 
+nodes to advertise the upfront fees that it will accept for the final hop 


to advertise the upfront fees that it will accept for the final hop

So IIUC: the receiver will also take an upfront fee, for the case where a failure occurs because e.g. they are not aware of the preimage that satisfies the proposed HTLC over that last hop

Can this also be introduced as a measure to prevent spam from direct peers that you have channels with? (apart from being a privacy measure)

GeorgeTsagk · 2023-02-07T21:17:02Z

proposals/channel-jamming-mitigation.md

+
+The sender can trivially solve for Y: 
+```
+X = Y + b + aY


Shouldn't we flip X and Y

Let X be the total amount due to be paid.

Let Y be the payment amount that the sender should dispatch.

The way I understand this: X is amount the receiver should get and Y is the inflated amount (with all kinds of fees included) that leaves the sender. Perhaps my interpretation of the above bullets is just not right.

GeorgeTsagk · 2023-02-07T21:55:26Z

proposals/channel-jamming-mitigation.md

+sake of their upfront fees. 
+
+The upfront fee amount should simply be assigned to the receiving party's 
+balance when an incoming HTLC is added. These amounts are not expected to be


What I fail to understand is what exactly is added to the receiving end's balance directly when an HTLC with upfront fees is proposed.

Say we got this route A --> B --> C --> D

A sends to D

B,C and D ask for an upfront fee of 100sat each

When A forwards the HTLC to B isn't the total sum of the upfront fees (300sat) forwarded to B?

So B gets 300sat upfront fees from A, then B pays 200sat upfront fees to C and C pays 100sat upfront fees to the (receiver) D? Effectively, everybody gets their part of the 100sat upfront fees, and this works as expected.

Can't B induce a failure and grab the full upfront fee amount (300sat) that would otherwise be delivered to the next hops?

carlaKC · 2023-07-25T17:40:23Z

Closing this for now as we're focusing on endorsement first.

carlaKC and others added 9 commits January 18, 2023 14:50

features: add option upfront fee

8109e87

Upfront fees will require feature bit signaling because nodes need to know that their peers understand how to update their channel state machine with this new protocol feature.

bolt11: add upfront fee policy for final hop to invoice

8ff01b2

TODO: routing hints will also need updating

bolt2: add upfront_fee to update_add_htlc TLVs

ff2394b

bolt03: include upfront fees in to_local and to_remote balances

57be678

bolt04: add upfront fee to onion routing payload

c400cae

bolt04: add error for insufficient upfront fee for forwarding nodes

6890e60

bolt04: add final incorrect upfront fee for last hop

dc31129

carlaKC mentioned this pull request Jan 18, 2023

POC: Upfront Fees to Mitigate Channel Jamming lightningnetwork/lnd#7339

Closed

ClaraShk mentioned this pull request Jan 18, 2023

2023-01-23: Jamming mitigation meeting ClaraShk/LNJamming#1

Closed

joostjager reviewed Jan 18, 2023

View reviewed changes

ariard reviewed Jan 23, 2023

View reviewed changes

t-bast mentioned this pull request Jan 27, 2023

Lightning Specification Meeting 2023/01/30 #1053

Closed

28 tasks

saubyk reviewed Feb 4, 2023

View reviewed changes

GeorgeTsagk reviewed Feb 7, 2023

View reviewed changes

t-bast mentioned this pull request Feb 10, 2023

Lightning Specification Meeting 2023/02/13 #1055

Closed

26 tasks

t-bast mentioned this pull request Feb 27, 2023

Lightning Specification Meeting 2023/02/27 #1057

Closed

26 tasks

t-bast mentioned this pull request Mar 13, 2023

Lightning Specification Meeting 2023/03/13 #1058

Closed

25 tasks

t-bast mentioned this pull request Mar 27, 2023

Lightning Specification Meeting 2023/03/27 #1060

Closed

26 tasks

t-bast mentioned this pull request Apr 7, 2023

Lightning Specification Meeting 2023/04/10 #1065

Closed

28 tasks

Roasbeef mentioned this pull request Apr 24, 2023

Lightning Specification Meeting 2023/04/24 #1067

Closed

26 tasks

t-bast mentioned this pull request May 5, 2023

Lightning Specification Meeting 2023/05/08 #1076

Closed

28 tasks

t-bast mentioned this pull request May 17, 2023

Lightning Specification Meeting 2023/05/22 #1082

Closed

28 tasks

t-bast mentioned this pull request Jun 2, 2023

Lightning Specification Meeting 2023/06/05 #1085

Closed

29 tasks

t-bast mentioned this pull request Jun 14, 2023

Lightning Specification Meeting 2023/06/19 #1088

Closed

28 tasks

t-bast mentioned this pull request Jul 12, 2023

Lightning Specification Meeting 2023/07/17 #1094

Closed

30 tasks

carlaKC closed this Jul 25, 2023

t-bast mentioned this pull request Jul 27, 2023

Lightning Specification Meeting 2023/07/31 #1098

Closed

27 tasks

t-bast mentioned this pull request Aug 10, 2023

Lightning Specification Meeting 2023/08/14 #1101

Closed

25 tasks

t-bast mentioned this pull request Aug 23, 2023

Lightning Specification Meeting 2023/08/28 #1103

Closed

23 tasks

draft: Upfront Fees to Mitigate Channel Jamming #1052

draft: Upfront Fees to Mitigate Channel Jamming #1052

Uh oh!

Conversation

carlaKC commented Jan 18, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

joostjager Jan 18, 2023 • 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!

Choose a reason for hiding this comment

Uh oh!

joostjager Jan 18, 2023 • 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!

This comment was marked as abuse.

Uh oh!

This comment was marked as abuse.

Uh oh!

This comment was marked as abuse.

Uh oh!

saubyk Feb 4, 2023 • 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!

GeorgeTsagk Feb 7, 2023 • 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!

GeorgeTsagk Feb 7, 2023 • 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!

carlaKC commented Jul 25, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

carlaKC commented Jan 18, 2023 •

edited

Loading

joostjager Jan 18, 2023 •

edited

Loading

joostjager Jan 18, 2023 •

edited

Loading

saubyk Feb 4, 2023 •

edited

Loading

GeorgeTsagk Feb 7, 2023 •

edited

Loading

GeorgeTsagk Feb 7, 2023 •

edited

Loading