|
| 1 | +``` |
| 2 | +bLIP: 25 |
| 3 | +Title: Allow forwarding HTLCs with less value than the onion claims to pay |
| 4 | +Status: Draft |
| 5 | +Author: Valentine Wallace <[email protected]> |
| 6 | +Created: 2023-05-22 |
| 7 | +License: CC0 |
| 8 | +``` |
| 9 | + |
| 10 | +## Abstract |
| 11 | + |
| 12 | +Penultimate hops in lightning payment paths may want to take an extra fee from the payee's final |
| 13 | +received value. To do so, they can simply forward less than the amount encoded in the onion by the |
| 14 | +sender, and specify the exact fee they took in a new `update_add_htlc` TLV for the receiver to |
| 15 | +verify. |
| 16 | + |
| 17 | +## Copyright |
| 18 | + |
| 19 | +This bLIP is licensed under the CC0 license. |
| 20 | + |
| 21 | +## Specification |
| 22 | + |
| 23 | +We define a TLV field for `update_add_htlc` that allows a relaying node to |
| 24 | +relay a smaller amount than the amount encoded in the onion: |
| 25 | + |
| 26 | +1. `tlv_stream`: `update_add_htlc_tlvs` |
| 27 | +2. types: |
| 28 | + 1. type: 65537 (`extra_fee`) |
| 29 | + 2. data: |
| 30 | + - [`u64`:`amount_msat`] |
| 31 | + |
| 32 | +The writer: |
| 33 | +* MUST set `extra_fee` to the amount of extra fee they took from the receiver's final value |
| 34 | + |
| 35 | +The receiver: |
| 36 | +* MUST fail the HTLC if they did not expect an extra fee to be taken or if the extra fee taken is |
| 37 | + too high |
| 38 | +* MUST either accept or reject the HTLC as if it had received `htlc_value + extra_fee` |
| 39 | + |
| 40 | +## Motivation |
| 41 | + |
| 42 | +For context, it is expected that many lightning users will be connected to the lightning network via |
| 43 | +Lightning Service Providers (LSPs), who are responsible for managing channel liquidity on end users' |
| 44 | +behalf. |
| 45 | + |
| 46 | +Often, users are onboarded to these services via a just-in-time inbound channel when they first |
| 47 | +receive a payment. However, this channel open costs money, and so liquidity providers may want to |
| 48 | +take an extra fee so that users can help bear the cost of this initial on-chain fee. |
| 49 | + |
| 50 | +## Rationale |
| 51 | + |
| 52 | +While it would be possible to avoid the extra TLV record if receivers could be trusted to calculate |
| 53 | +that the fee taken by the penultimate hop is as-expected, in practice this may be tricky to get |
| 54 | +right. If there were a bug in this logic, a sender could exploit it by forwarding less than the |
| 55 | +invoice's expected value, and receive proof-of-payment that they paid the full value. |
| 56 | + |
| 57 | +## Implementation Notes |
| 58 | +See |
| 59 | +<https://github.com/BitcoinAndLightningLayerSpecs/lsp/tree/main/LSPS2#3--invoice-generation> |
| 60 | +for invoice requirements if this feature is being used in the JIT channel context. |
| 61 | + |
| 62 | +## Reference Implementations |
| 63 | +LDK: <https://github.com/lightningdevkit/rust-lightning/pull/2319> |
0 commit comments