Skip to content

Commit

Permalink
bLIP-0025: Allow forwarding HTLCs that underpay the onion encoded value
Browse files Browse the repository at this point in the history
  • Loading branch information
valentinewallace committed May 22, 2023
1 parent de30d99 commit d17353d
Showing 1 changed file with 50 additions and 0 deletions.
50 changes: 50 additions & 0 deletions blip-0024.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
```
bLIP: 25
Title: Allow forwarding HTLCs with less value than the onion claims to pay
Status: Draft
Author: Valentine Wallace <[email protected]>
Created: 2023-05-22
License: CC0
```

## Abstract

Penultimate hops in lightning payment paths may want to take an extra fee from the payee's final
received value. To do so, they can simply forward less than the amount encoded in the onion by the
sender, and specify the exact fee they took in a new `update_add_htlc` TLV for the receiver to
verify.

## Copyright

This bLIP is licensed under the CC0 license.

## Specification

Penultimate hop on the path:
* In their outbound `update_add_htlc` message, MUST include a TLV record keyed by type XXX with a
TLV value containing the amount of extra fee they took from the receiver's final received value,
in millisatoshis

Receiver:
* MUST check TLV XXX from the inbound `update_add_htlc` to ensure the fee taken by the previous hop
makes sense
* MUST fail back the HTLC if TLV XXX is missing or its value is unexpected

## Motivation

For context, it is expected that many lightning users will be connected to the lightning network via
LSPs (Lightning Service Providers), who will be responsible for managing channel liquidity on end
users' behalf.

Often, users are onboarded to these services via a just-in-time inbound channel when they first
receive a payment. However, this channel open costs money, and so liquidity providers may want to
take an extra fee so that users can help bear the cost of this initial on-chain fee.

## Rationale

While it would be possible to avoid the extra TLV record if receivers could be trusted to calculate
that the fee taken by the penultimate hop is as-expected, in practice this may be tricky to get
right. If there were a bug in this logic, a sender could exploit it by forwarding less than than the
invoice's expected value, and receive proof-of-payment that they paid the full value.

## Reference Implementations

0 comments on commit d17353d

Please sign in to comment.