Commissions for channels, where funds run out about suez

[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.

[prusnak]

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

Done in 84e3ff3

[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.

[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.