From 7667f03d2234f0ea92ef56a0ac9c912621a61e40 Mon Sep 17 00:00:00 2001
From: Joost Jager <joost.jager@gmail.com>
Date: Mon, 29 Aug 2022 16:42:03 +0200
Subject: [PATCH] Inbound routing fees

---
 blip-0002.md |  8 +++++
 blip-0018.md | 90 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 98 insertions(+)
 create mode 100644 blip-0018.md

diff --git a/blip-0002.md b/blip-0002.md
index c8e8a48..65b9978 100644
--- a/blip-0002.md
+++ b/blip-0002.md
@@ -97,6 +97,14 @@ The following table contains extension tlv fields for the `ping` message:
 |-------|-----------------------------|--------------------------------|
 | 65536 | `tlv_field_name`            | Link to the corresponding bLIP |
 
+#### `channel_update`
+
+The following table contains extension tlv fields for the `channel_update` message:
+
+| Type       | Name                        | Link                           |
+|------------|-----------------------------|--------------------------------|
+| 55555      | `inbound_discount`          | [bLIP 18](./blip-0018.md)      |
+
 ## Copyright
 
 This bLIP is licensed under the CC0 license.
diff --git a/blip-0018.md b/blip-0018.md
new file mode 100644
index 0000000..b286ef6
--- /dev/null
+++ b/blip-0018.md
@@ -0,0 +1,90 @@
+```
+bLIP: 14
+Title: Inbound routing fees
+Status: Draft
+Author: Joost Jager <joost.jager@gmail.com>
+Created: 2022-08-29
+License: CC0
+```
+
+## Abstract
+
+The Lightning BOLTs define a routing fee that is based on the policy of the
+_outgoing_ channel. This makes it impossible for routing node operators to
+differentiate in fees between incoming channels.
+
+Incoming traffic from some peers may be more desired than from others, for
+example because it balances out traffic in the opposite direction.
+
+This bLIP defines an optional `channel_update` message field `inbound_fee` to
+express an inbound fee.
+
+## Copyright
+
+This bLIP is licensed under the CC0 license.
+
+## Specification
+
+Routing node:
+
+* MAY include a `channel_update` optional TLV record `inbound_fee` keyed by type
+  `55555` with the following value:
+
+  * [i32:base_msat]
+  * [i32:proportional_millionths]
+
+* MAY choose to advertize a negative inbound fee to keep servicing senders who
+  don't understand inbound fees.
+  
+  The given discount can be balanced with an increase of the outgoing fees to
+  effectively have a positive inbound fee.
+
+*  The inbound fee is calculated over the amount to forward plus the outbound
+   fee. This amount is called the net amount received (`net_received_amt`).
+
+    `net_received_amt = amt_to_fwd + outbound_fee(amt_to_fwd)`
+
+    `inbound_fee(net_received_amt) = inbound_fee.base_msat + inbound_fee.proportional_millionths * net_received_amt / 1e6`
+
+    Example: 
+    
+    `inbound fee = 1 + 10%, outbound fee = 7 + 3%, outgoing htlc amount = 100`
+
+    `--- 122 ---> (in fee: 12) (net_received_amt: 110) (out fee: 10) --- 100 --->`
+
+* MUST accept a routing fee equal to or greater than the sum of inbound and
+  outbound fee. No attempt should be made to calculate the total fee in one go,
+  because rounding may cause the end result to be higher.
+
+* The inbound fee does not apply to final hops.
+
+* For `fee_insufficient` failures, the routing node SHOULD, in addition to the
+  outgoing channel policy, also return the incoming channel policy as a TLV
+  extension. But only if the sender signaled support for extended failure
+  messages.
+  
+  TBD: allocate type for this and describe.
+
+* MUST NOT set inbound fees on private channels. Inbound fees can't be
+  communicated through bolt11 invoices yet and senders will not be aware of
+  them.
+
+Sender node:
+
+* MUST pay each routing node at least the sum of its advertised inbound and
+outbound fee for the incoming and outgoing channel that is used (formula above).
+  
+* SHOULD signal to each node along the route that they can interpret [extended failure messages](https://github.com/lightning/bolts/pull/1021).
+
+* SHOULD apply all channels updates that accompany a `fee_insufficent` failure.
+  The update for the incoming channel may be present in the TLV extension.
+
+## Universality
+
+This feature is defined as a BLIP because it's experimental.
+
+## Backwards Compatibility
+
+By defining the inbound fee as a negative number, senders who don't understand
+the new field will still be able to make payments. Routing nodes will accept
+overpayment on fees.
\ No newline at end of file