Deprecate dust-threshold config value #9182
Conversation
saubyk
changed the title
ziggie1984
force-pushed
the
fix-feebuffer
branch
2 times, most recently
from
f8ce024
to
c0f0f04
Compare
ziggie1984
changed the title
ziggie1984
changed the title
ziggie1984
force-pushed
the
fix-feebuffer
branch
from
c0f0f04
to
e31c4d8
Compare
ziggie1984
force-pushed
the
fix-feebuffer
branch
2 times, most recently
from
7514a69
to
4c395e8
Compare
ziggie1984
force-pushed
the
fix-feebuffer
branch
from
4c395e8
to
7ff237e
Compare
sample-lnd.conf
Outdated
| ; Setting this value too low might cause force closes because the lightning | ||
| ; protocol has no way to roll back a channel state when your peer proposes a | ||
| ; channel update which exceeds this limit there are only two options to resolve | ||
| ; the situation. You can either increase the limit and the channel should be |
There was a problem hiding this comment.
I am a bit confused here about how the sequence of events can transpire here for the user to address the situation.
- Peer proposes an update which exceeds the limit
- Would the channel become inactive?
- User inspects the log statement and realizes that exposure limit needs to be increased
- After increasing the limit, LND needs to be restarted for new config setting to become effective
- LND is restarted and the channel is active again?
What I am also unsure about is, can the channel be really "saved" by prompt user action or is the channel's fate sealed after the peer proposes an update exceeding the threshold value?
There was a problem hiding this comment.
I kept it short to not explain the whole lightning state protocol here but regarding your questions:
- Yes the channel would become inactive because the channel partner which exceeds the fee here will fail the channel with an internal error, depending on the lightning implementations some might already force close the channel if they receive an internal state maschine error from us, LND does not and there is a chance to bring this channel up again, if the limit is increased and the node restarted.
There was a problem hiding this comment.
This is not something we can address here:
But there is a UX problem in discovering that the channel has become inactive and then inspecting the log to find out what might have happened. Log might get cycled if the user is too late in inspecting and may lose this critical piece of info.
I was wondering if we can create a TODO or an issue to persist the reason for channel becoming inactive in the DB, so that discoverability of the issue is easier
There was a problem hiding this comment.
I think you are making a very good point here, we should at least record a channel state failure when reporting the channel to the user, will create an issue.
ziggie1984
force-pushed
the
fix-feebuffer
branch
from
7ff237e
to
7454f12
Compare
Replace ambigious config value "dust-treshold" with a more clear "channel-max-fee-exposure" exposure value. The old value is deprecated and will be removed in the near future.
ziggie1984
force-pushed
the
fix-feebuffer
branch
from
7454f12
to
17e9bd0
Compare
Introduced a more clear config value and deprecated the old
dust-thresholdvalue. The new setting is calledchannel-max-fee-exposure. Nothing has changed code wise, the new value behaves as the old one but is way clearer and removes the ambiguity