Commissions for channels, where funds run out

[Perlover]

Hello,

What's the point of setting low commissions for channels where your balance is depleted? Thus, you stimulate payments through such channels, but there is no liquidity in them for sending. It is bad for routing (payments through them are more likely will be FAIL but third-party wallets/senders will try to choose these channels as there are low commissions).

It would be quite logical to increase the commission for its part where your local balance is low.

P.S. Honestly, I do not understand - why use here the distribution of Gauss?

[prusnak]

I wanted to motivate the other peer to use the channel to push the balance to my side by having a low fee, but maybe that was a misunderstanding of how things work.

I need to implement new strategy, maybe the one in #4 ?

Or do you have any other ideas about what strategies could be implemented?

[Perlover]

Your settings from your side (fee_base / fee_rate in your LND) only work for outgoing payments
The remote settings (fee_base/fee_rate of remote channel tip) - these commissions cannot be monitored by you and you are not going - they are received by a remote side that sends the payment to you (you do not receive anything for the incoming payment).

When you forward payment REMOTE_NODE --> YOUR NODE --> NEXT_REMOTE_NODE you will get fee only from the channel YOUR NODE --> NEXT_REMOTE_NODE ("fee_base/fee_rate" of this channel) but not from REMOTE_NODE --> YOUR NODE.

[Perlover]

I would like to suggest to raise your fees for those channels where your balance is greatly declining - in this way you will give to understand other nodes that through this channel should not carry out an outgoing payment from you, and if someone will do it - you will earn more. Lowering the fees for such channels you do not improve because a lot part of balance on the other side and a sending of satoshis from a remote node to your node are not controlled by your fee settings - ideally, in this case, the remote side should reduce the fees and promote the network to send to your side.

[prusnak]

I updated the fee-sigma logic in 6606d15

For channels with local balance >= capacity the fee rate is set to fee-rate. For channels with smaller local balance the fee is getting exponentially higher. See 6606d15 for more details

[Perlover]

suez/suez.py

Line 20 in 6606d15

ratio = channel.local_balance / (channel.local_balance + channel.remote_balance)

- channel.local_balance + channel.remote_balance - most likely it is not that you want to do. Better to take capacity - commit_fee (LND API) because when there is a processed HTLC your local_balance is temporarily reduced by this amount (or remote_balance). It turns out, the numbers will constantly jump in the processing moments of HTLC (forwarding payments) but capacity - commit_fee will be what you want.

I did not look in detail all logic, but if the local_balance will be 20% from channel volume the ratio will be -0.6, the coef will be 1 (fee_sigma by default in your code is 0). How will fee change in this case?

I would suggest changing fee by step by step because in your case with each a forwarded payment the fees will be changed in the channel, this will issue a new update (ChannelUpdate) on the network with new commissions and those LN senders who will not have time to get new commissions from you - can receive FAIL answer (with fee_insufficient error) when will sending, for example, just because your commissions slightly rose.

[prusnak]

How will fee change in this case?

You need to set fee_sigma > 0 in order to not have flat fee everywhere.

I pushed one more fix in 5ee8d83

After the fix is applied, channels with local_balance < 1/2 of capacity will get higher fees.

[Perlover]

What about to replace channel.local_balance + channel.remote_balance to channel.capacity - channel.commit_fee ? :)

If in the channel there no HTLCs then the channel.local_balance + channel.remote_balance === channel.capacity - channel.commit_fee. But if the channel has HTLCs (for example the one 1K sats for example) then there will be:

channel.local_balance + channel.remote_balance < channel.capacity - channel.commit_fee and (channel.capacity - channel.commit_fee) - (channel.local_balance + channel.remote_balance) === 1000

The LND will reduce the HTLC amount from local_balance (outgoing payment and at that time the remote_balance will be not changed) or from 'remote_balance' (incoming payment and at that time the local_balance will be not changed) during forwarding.

[prusnak]

What about to replace channel.local_balance + channel.remote_balance to channel.capacity - channel.commit_fee ? :)

Done in 84e3ff3