[...]
What you describe is called channel reserve. It's the reserve both partners agree to keep as long as the channel will last. It exists to insure disincentive. If you're forced to keep 1% of your channel (for example) you will never publish an older state, even if you only have that one reserve on your side, because you'll lose it. If there was no such reserve, you'd have nothing to discourage you from publishing an older state if you had no receiving capacity, because you'd have nothing to lose.
I have not ever come across with the term "dust limit" on lightning, but I believe it has to do with the prevention of unimportant transactions (e.g, 1 sat). It only exists on-chain as far as I'm concerned.
Hum, ok. I think I understand the
channel reserve.
And I've been reading through Bitcoin mailing list and
dust limit seems to be only related to on-chain transactions and to avoid spammy/empty UTXOs into blocks. But if you, in Core Lightning, run
lightning-cli listpeers , there will be a field in the output with the dust limit. This then should be related to the dust limit of the funding TxID that opened the channel?
BTW, the only thing really useful that I found about
dust limit was this:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/019310.htmlEdited;
And following my other post, can we forward payments of a value lower than the
channel_reserve? Because I remember when I started with LN, of a problem (not sure if it was opening/closing a channel or forwarding payments) that was related to a bug with the dust limit calculation in Core Lightning!
Edited 1;
The issue was with opening a channel back in 2020. I found the issue that I discovered (I think by accident) back then and fixed by niftynei:
https://github.com/ElementsProject/lightning/issues/4140