-
Notifications
You must be signed in to change notification settings - Fork 20
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
Commissions for channels, where funds run out #6
Comments
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? |
Your settings from your side (fee_base / fee_rate in your LND) only work for outgoing payments 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. |
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. |
Line 20 in 6606d15
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 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. |
You need to set I pushed one more fix in 5ee8d83 After the fix is applied, channels with local_balance < 1/2 of capacity will get higher fees. |
What about to replace If in the channel there no HTLCs then the
The LND will reduce the HTLC amount from |
Done in 84e3ff3 |
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?
The text was updated successfully, but these errors were encountered: