Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a bLIP for backwards-compatible inbound fees #22

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
86 changes: 86 additions & 0 deletions blip-0019.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,86 @@
```
bLIP: 19
Title: Inbound Routing Fees
Status: Active
Author: Matt Corallo <[email protected]>
Created: 2023-01-08
License: CC0
```

## Abstract

This bLIP describes a mechanism whereby a node can charge either a positive or a negative amount in fees for an HTLC based on the channel on which the HTLC came in to said node. It does not modify existing `channel_update` messages, avoiding issues where temporary negative fees cause nodes to spam the gossip network (see "Rate Cards" for a proposal which adds negative fees without this issue). Instead, it relies on informing peers that a fee will be charged, and having them incrase their corresponding outbound fees.
TheBlueMatt marked this conversation as resolved.
Show resolved Hide resolved

## Copyright

This bLIP is licensed under the CC0 license.

## Specification

One new message is defined, `inbound_fees_update`:

1. type: 34242 (`inbound_fees_update`)
2. data:
* [`32*byte`:`channel_id`]
* [`i32`:`inbound_forwarding_fee_proportional_millionths`]
* [`i32`:`inbound_forwarding_fee_base_msat`]

Additionally, one new feature flag is defined:

| Bits | Name | Description | Context | Dependencies |
|---------|----------------|--------------------------------------------------------|---------|--------------|
| 282/283 | `inbound_fees` | Supports receiving and enforcing `inbound_fees_update` | IN | None |

### Requirements

A node receiving `inbound_fees_update`:
* MUST ensure it's next `channel_update` message for the corresponding channel
has its `fee_proportional_millionths` and `fee_base_msat` fields incremented
by the `inbound_forwarding_fee_proportional_millionths` and
`inbound_forwarding_fee_base_msat` fields, respectively. Fields which fall
below zero MUST be set to zero.
* SHOULD ensure that it's next `channel_update` goes out in a timely manner,
subject to relevant rate-limits.
TheBlueMatt marked this conversation as resolved.
Show resolved Hide resolved
* MUST increase the amount forwarded in an HTLC by the advertised inbound fees.
TheBlueMatt marked this conversation as resolved.
Show resolved Hide resolved

A node sending `inbound_fees_update`:
* SHOULD NOT send such a message more often than it anticipates
`channel_update` messages may be accepted by the gossip network.
* MUST verify that inbound fees corresponding with the provided settings are
paid on all HTLCs, noting that the inbound fees are calculated against the
inbound HTLC amount *before* the inbound fees are subtracted.
TheBlueMatt marked this conversation as resolved.
Show resolved Hide resolved

## Rationale

Because a node cannot set the fee fields in its `channel_update` below zero,
only a node's immediate peer may utilize negative inbound fees in excess of
its outbound fees. This is useful for private channels.
t-bast marked this conversation as resolved.
Show resolved Hide resolved

Because senders calculate fees based on the amount as they think it will be
forwarded, inbound fees must be checked by adding required fees back up from
the `amt_to_forward` value. i.e. in order to check the total fee on an HTLC, a
node must calculate the total expected fee based on it's announced forwarding
parameters, subtract that from the `amt_to_forward` to get the amount the
sending node (likely) expected the processing node to receive. From there, the
processing node can calculate the inbound fee it expected and check that it was
included in the forwarded HTLC.

## Motivation

Many lightning node operators have expressed a desire for "inbound routing fees," i.e. fees which a sender must pay when forwarding *inbound* through a channel, rather than outbound. There is some debate as to whether such fees make sense in the general case - ultimately it's not the fee-charging node's liquidity which is being used here, so why can they charge a fee for it?

However, ignoring whether this feature makes sense for routing nodes, routing nodes may which to use this to provide fee discounts for peers with which they have a commercial relationship with. For example LSP's may wish to use this to provide explicit fee discounts to their paying clients.

Having a standard, interoperable way for such relationships to be implemented allows LSP's to provide such a service without vendor lockin.

## Universality

This bLIP describes a mechanism for inbound fees which is completely transparent to the broader lightning network. Only the two nodes involved in the channel are aware of the inbound fees. More importantly, due to the above concerns expressed over the general applicability of inbound routing fees, it is anticipated that not all lightning implementations will support this. Users wishing to charge inbound fees may seek out peers which support it, and LSP clients may wish to use this when working with an LSP to receive a fee discount.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This means that a routing node can only charge an inbound fee if its peer cooperates and may cause existing peering relationships to change. Especially if a node wants to charge inbound fees across the board in order to reduce outbound fees, all of its peers need to support this.

With #18, you can charge inbound fees as you like independent of your peers. Of course the limitation there is that senders need to support it.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not really sure I get this - a user may want to charge an inbound fee today, but they don't. Sure, once you have an implementation you may also ask your peer to support it, but it doesn't mean your relationship changes with your peer, unless of course they also support this feature. You may choose to prefer peers which do support this feature, sure, but isn't that true for any feature? Even for #18 you may prefer to use peers that use negative fees to give a discount in line with the second suggested motivation here.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just saying that there is a difference between requiring your peer to support a feature vs requiring the sender of a payment to support a feature.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, one is local and one is global :)


## Backwards Compatibility

The new messages described in the bLIP are gated by a new feature bit, which nodes MAY set to odd to ensure backwards compatibility.

## Reference Implementations

* LDK: https://github.com/lightningdevkit/rust-lightning/pull/1942