draft: Upfront Fees to Mitigate Channel Jamming #1052
Conversation
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
|
|
||
| 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 |
There was a problem hiding this comment.
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.
| 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 |
There was a problem hiding this comment.
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.
| 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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Like @joostjager mentioned, wouldn't these amounts be directly embedded to the to_local & to_remote balances of the commitment txs?
| 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: |
There was a problem hiding this comment.
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
| 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: |
There was a problem hiding this comment.
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.
| 2. data: | ||
| * [`u64`:`upfront_fee`] | ||
| * [`u16`:`len`] | ||
| * [`len*byte`:`channel_update`] |
There was a problem hiding this comment.
We do have tlv failures now, so could make use of that. #1021
| - 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, |
There was a problem hiding this comment.
If the sender is the channel initiation and as such encumbering the responsibility for fees, I don't know if you have too sum up the upfront_fee_msat to the offered amount_msat to determinate you're still in the bounds of the "fee spike buffer".
| - if it is not the final node: | ||
| - MUST return an error if: | ||
| - `short_channel_id` is not present, | ||
| - 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)) |
There was a problem hiding this comment.
I think this is where the spec is unclear to me.
upfront_fee_msat is unconditionally pushed on the to_remote balance from the viewpoint of the HTLC sender. At the same time, for this equality to hold incoming upfront_fee_msat must accumulate all the downstream upfront_fee to fulfil this equality. Otherwise you might have routing failures just due to hops setting their upfront_fee_base_sat and upfront_fee_proportional_ppm in an unequilibrated fashion.
E.g, you have Alice <-> Bob <-> Caroll <-> Dave. Let's say you have Bob requests 100 sat, Caroll requests 2000 sats and Dave requests 150 sats. The HTLC forward should fail at Bob, as 100 sat < 2000 sat, unless Alice sent an upfront_fee_msat= 2250 sats. However it also means Bob's balance is credited of 2250 sats, if understand the proposal correctly on this mechanism.
|
|
||
| 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 |
There was a problem hiding this comment.
I think the number holds as long as the simulation parameters hold. From my understanding of the paper model, some parameters are quite arbitrary (e.g the jam delay of 7 second), and beyond I think there is some assumption of periodicity of jamming and honest payment. Where the 1% unconditional fee doesn't make sense to me is in face of a jamming adversary perpetually succeeding to occupy the HTLC slots, in a way than never the success fees are paid. In that case, there is no equal compensation at all, I would say.
Additionally, I don't know about the methodological issue of substituting our own evaluation of the routing node liquidity opportunity cost, and if unconditional fees should not be floating to suit one's own evaluation of opportunity cost.
|
|
||
| The sender can trivially solve for Y: | ||
| ``` | ||
| X = Y + b + aY |
There was a problem hiding this comment.
shouldn't this equation be X = Y + a + bY?
| 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. |
There was a problem hiding this comment.
Like @joostjager mentioned, wouldn't these amounts be directly embedded to the to_local & to_remote balances of the commitment txs?
| 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 |
There was a problem hiding this comment.
nit: typo upfront_fee_to_forwad -> upfront_fee_to_forward
| ``` | ||
|
|
||
| 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 |
There was a problem hiding this comment.
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)
|
|
||
| The sender can trivially solve for Y: | ||
| ``` | ||
| X = Y + b + aY |
There was a problem hiding this comment.
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.
| 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 |
There was a problem hiding this comment.
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
Asends toDB,CandDask for an upfront fee of100sateach
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?
|
Closing this for now as we're focusing on endorsement first. |
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:
to_remotebalance, with no on-chain output or secret that proves the htlc was actually forwardedtotal_amtpaid for a htlc set, so senders don't need to pay for recipient privacyIt 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.