|
| 1 | +``` |
| 2 | +bLIP: 14 |
| 3 | +Title: Inbound routing fee discount |
| 4 | +Status: Draft |
| 5 | +Author: Joost Jager <[email protected]> |
| 6 | +Created: 2022-08-29 |
| 7 | +License: CC0 |
| 8 | +``` |
| 9 | + |
| 10 | +## Abstract |
| 11 | + |
| 12 | +The Lightning BOLTs define a routing fee that is based on the policy of the |
| 13 | +_outgoing_ channel. This makes it impossible for routing node operators to |
| 14 | +differentiate in fees between incoming channels. |
| 15 | + |
| 16 | +Incoming traffic from some peers may be more desired than from others, for |
| 17 | +example because it balances out traffic in the opposite direction. |
| 18 | + |
| 19 | +This bLIP defines an optional `channel_update` message field to express an |
| 20 | +inbound fee discount. Senders who are able to read this field can benefit from |
| 21 | +lower routing fees using those channels. |
| 22 | + |
| 23 | +## Copyright |
| 24 | + |
| 25 | +This bLIP is licensed under the CC0 license. |
| 26 | + |
| 27 | +## Specification |
| 28 | + |
| 29 | +Origin node: |
| 30 | + |
| 31 | +* MAY include a `channel_update` optional TLV record keyed by type `32769` with |
| 32 | + the following value: |
| 33 | + |
| 34 | + * [i32:inbound_fee_base_msat] |
| 35 | + * [i32:inbound_fee_proportional_millionths] |
| 36 | + |
| 37 | + These fields SHOULD be negative numbers that define the inbound discount for |
| 38 | + that channel. |
| 39 | + |
| 40 | +Receiving node: |
| 41 | + |
| 42 | +* MAY pay each routing node the sum of its advertised inbound and outbound fee |
| 43 | +for the incoming and outgoing channel that is used. This should amount to a |
| 44 | +lower value than just the outbound fee. |
| 45 | + |
| 46 | + `outbound_fee(amt_to_fwd) + inbound_fee(amt_to_fwd + outbound_fee(amt_to_fwd))` |
| 47 | + |
| 48 | +Note that the inbound fee is calculated over the total balance shift of the |
| 49 | +incoming channel. This includes the outbound fee. |
| 50 | + |
| 51 | +* For the final node, the inbound discount does not apply. |
| 52 | + |
| 53 | +## Universality |
| 54 | + |
| 55 | +This feature is defined as a BLIP because it's optional. |
| 56 | + |
| 57 | +## Backwards Compatibility |
| 58 | + |
| 59 | +By defining the inbound fee as a negative number, senders who don't understand |
| 60 | +the new field will still be able to make payments. Routing nodes will accept |
| 61 | +overpayment on fees. |
0 commit comments