-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Deprecate dust-threshold config value #9182
base: master
Are you sure you want to change the base?
Conversation
f8ce024
to
c0f0f04
Compare
c0f0f04
to
e31c4d8
Compare
7514a69
to
4c395e8
Compare
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
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.
7454f12
to
17e9bd0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🎚️
Introduced a more clear config value and deprecated the old
dust-threshold
value. 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