RFC: Node Fee Policy

[kilrau]

Is your feature request related to a problem? Please describe.
Currently the indra node doesn't ask for any sort of fees, but sponsors quite some things. Mainly:

• collateralization fee: paying gas for collateralizations (should be paid by sender)
• routing fee: for the effort of forwarding a transfer (should be paid by sender)
• capital fee: for locking a specific amount of capital for a specific amount of time outbound to the client. Will only really be relevant in a multi-hop future where the node needs to decide which channel brings the most return on locked capital. And that will be channels to other nodes (for routing fees) and not to clients. So that's where clients will need to start paying for capital locked in channels with them, if they want to avoid collateralizations and high fees for such. (tbd paid by sender or receiver)

Describe the solution you'd like
A "fee policy" concept for the the node.

• collateralization fee: paying gas for collateralizations if they are needed (client needs a way to verify they are and ideally can pay for gas directly herself (Allow client to pay for gas #1120)
• routing fee should cover these two basics for sender: 1. base fee (fixed nominal amount) 2. percentage of raw amount
• fees should be in separate fields to keep the "send"/"receive" amounts clean (raw)
• apart from gas fee, fee's should not be charged if the payment fails

TBD:

• is it better to gossip fee policy to client or client pull (startup vs. on-demand for every payment)?
• who pays for node's locked outbound liquidity - sender or receiver? In LN it's the receiver.
• how does the client ensure: collateralization was actually needed? Paid gas costs was the actual gas costs paid? Receiver receives actual send amount and node only keeps the fees.

A "fee management" concept for the node.

• sane default fee policy, client can't do payments without a fee policy in place
• modify fee policy, inform clients about it
• payment and fee overview on node backend

[ArjunBhuptani]

Will need to spend some time on this but some initial thoughts:

Generally, the way that we can implement fees within Connext is to have the node propose an app with a receiver for a lower balance than the sender's app. This way the node can keep the difference between the two.

The node can of course implement the fee based on some internal policy. The receiver can also choose to "accept" the fee by explicitly not unlocking the transfer in the event that the node attempts to collect more fees than expected. However, one thing I'm not certain about is how the receiver can know how much the sender originally sent -- the only data that is actually persisted across apps in the htlc application is the actual hashed preimage. Therefore, unless the sender and receiver agree upon a payment amount out-of-protocol, there's no way for the receiver to be certain that the "amount paid by sender" that the node reports is actually accurate.

I believe that lightning handles this currently with an invoicing protocol which "pulls" payments by including all of the recipient's payment details in information that is sent out-of-band to the sender. In Connext, we "push" payments (which IMO has much better availability tradeoffs). Note that we can always include the amount as part of the hash for other connext payments so it's not as big of an issue there.

Perhaps what we can do in the HTLC case is to include the amount (and potentiallly assetId) as part of the out-of-band message that happens between sender/receiver to exchange preimage? That would probably make the most sense.

[ArjunBhuptani]

P.s. In the case of XUD this isn't actually a huge issue. Say Alice is creating a BTC transfer to Bob in exchange for an ETH transfer from Bob. Alice is only incentivized to unlock Bob's ETH transfer if she agrees with the "rate" (which would bake fee into it)

[kilrau]

P.s. In the case of XUD this isn't actually a huge issue. Say Alice is creating a BTC transfer to Bob in exchange for an ETH transfer from Bob. Alice is only incentivized to unlock Bob's ETH transfer if she agrees with the "rate" (which would bake fee into it)

That is true, in our case the xud layer is the out-of-band communication layer that ensures received amounts have to be .. exact otherwise trades will fail and payments won't execute. We don't ensure values for forwarding/routing fees though, we believe the lower payment channel protocol should do that.

I believe that lightning handles this currently with an invoicing protocol which "pulls" payments by including all of the recipient's payment details in information that is sent out-of-band to the sender. In Connext, we "push" payments (which IMO has much better availability tradeoffs).

Lightning can do both in the meanwhile (push & pull). To put it short: for push, the receiver does not know how much to expect and what fees were involved and default is to accept whatever payment comes in. It does need out-of-band communication to configure a lightning node to reject a push payment e.g. below a certain amount from a certain peer. Pull or invoicing, doesn't have this problem and the receiver only accepts final amounts of minimum the invoiced amount (and actually up to twice the amount of the invoice (reason).

But all that is not really related to how fees get communicated and how the sender know how much more to add to the raw send amount. In LN, fees get broadcasted ("gossiped") P2P as fee policy and the sender knows how to construct the first HTLC because it knows how much each hop in the route will deduct before it sends the payment.

In a push-payment (which is still somewhat experimental) it would need to tell the receiver beforehand via a p2p message "heads-up, payment with hash abc for assetID d coming in, reject payments below amount e, because that means one node on the route deducted more than it said it would. To my knowledge there is no such mechanism for push payments in LN yet, but thinking about it that's the simplest way and no need to integrate anything into the hash.

Reference:

• LN Routing Fee Calcuation
• LN Fee Update Message