-
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
lnwallet+htlcswitch: make Switch dust-aware #5770
lnwallet+htlcswitch: make Switch dust-aware #5770
Conversation
Visit https://dashboard.github.orijtech.com?back=0&pr=5770&remote=true&repo=Crypt-iQ%2Flnd to see benchmark details. |
0aaeb59
to
a4eb9d7
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.
Happy the drafted changes worked out so well! Great commits generally, completed an intial pass, nothing major blocking so far. Will continue to test this out and also do another pass afterwards
// Attempt to fetch the target link before creating a circuit so that | ||
// we don't leave dangling circuits. The getLocalLink method does not | ||
// require the circuit variable to be set on the *htlcPacket. | ||
link, linkErr := s.getLocalLink(packet, htlc) |
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.
Seems this actually also fixes a bug (that would occur rarely since the bandwidth hints would report 0 if the link wasn't online?), where we would possibly never clean up a circuit?
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 didn't look at the routing-level call-graph -- my reasoning was that SendHTLC
would be called and the link has died before/during with RemoveLink
being called and so the circuit would still exist. On start-up, we'd only clean non-hop.Source
circuits. I didn't want to make this problem worse by creating a circuit, and then potentially failing if the outbound link was dust-exposed.
2ee4dc6
to
05a14a2
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 💎
Same comment from the other one re the new release notes file
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.
first pass, just a few questions from me
@@ -2527,6 +2568,10 @@ func (l *channelLink) updateChannelFee(feePerKw chainfee.SatPerKWeight) error { | |||
return err | |||
} | |||
|
|||
// The fee passed the channel's validation checks, so we update the | |||
// mailbox feerate. | |||
l.mailBox.SetFeeRate(feePerKw) |
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.
Is it a problem if we set fee rate here but then fail to send the new fee rate through to our peer?
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.
The assumption I made here is that SendMessage
either sends the message or doesn't send the message. If it doesn't send the message, the connection died and the link is shutdown. This assumes that brontide.Noise
doesn't drop messages or get into some weird state. On restart the mailbox will be called with SetFeeRate(local commitment fee rate)
.
Typing this out, I realize that the mailbox could have an outdated feerate:
---update_fee--->
---commit_sig--->
- LHS dies
* AttachMailBox with LocalCommit feerate, which won't get immediately refreshed
Could add another method to LightningChannel
to retrieve the remote commitment tip feerate if we're initiator (which will always be the latest), but honestly don't think it's necessary as it should eventually get to the feerate after a link restart or another fee update.
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.
yeah, agree it's not worth the extra code, maybe just drop a comment on the mailbox feeRate
field that this can be briefly out of sync with the channel.
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.
comment added
2d551c4
to
e32ece6
Compare
lnwallet/channel_test.go
Outdated
// Settling the HTLC back from Alice to Bob should not change the dust | ||
// sum. |
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.
nit: add "because alice has not yet received the revocation commitment" to comment? had to think about it for a second.
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.
"because the HTLC is counted until it's removed from the update logs via compactLogs."?
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.
great work on the tests for this, very thorough!
I think release notes for this need to be 0.14 (could be wrong), then we're gg.
@@ -2527,6 +2568,10 @@ func (l *channelLink) updateChannelFee(feePerKw chainfee.SatPerKWeight) error { | |||
return err | |||
} | |||
|
|||
// The fee passed the channel's validation checks, so we update the | |||
// mailbox feerate. | |||
l.mailBox.SetFeeRate(feePerKw) |
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.
yeah, agree it's not worth the extra code, maybe just drop a comment on the mailbox feeRate
field that this can be briefly out of sync with the channel.
@@ -203,6 +203,7 @@ func TestLightningNetworkDaemon(t *testing.T) { | |||
// TODO(roasbeef): create master balanced channel with all the monies? | |||
aliceBobArgs := []string{ | |||
"--default-remote-max-htlcs=483", | |||
"--dust-threshold=5000000", |
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.
Reminder to drop before merge
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.
dropped commit but kept the change since o/w a flake occurs in async_bidi_payments
It over-estimates the local or remote commitment's dust sum by counting all updates in both updateLogs that are dust using the trimmed-to-dust mechanism if applicable. The over-estimation is done because ensuring an accurate counting is a trade-off between code simplicity and accuracy.
This commit extends the Mailbox interface with the SetDustClosure, SetFeeRate, and DustPackets methods. This enables the mailbox to report the dust exposure to the Switch when the Switch decides whether to forward a dust packet. The dust is counted from the time an Add is introduced via AddPacket until it is removed via AckPacket. This can lead to some packets being counted twice before they are signed for, but this is a trade-off between accuracy and simplicity.
This allows the Switch to determine the dust exposure of a certain channel and allows the link to set the feerate of the mailbox given a fee update.
This commit makes SendHTLC (we are the source) evaluate the dust threshold of the outgoing channel against the default threshold of 500K satoshis. If the threshold is exceeded by adding this HTLC, we fail backwards. It also makes handlePacketForward (we are forwarding) evaluate the dust threshold of the incoming channel and the outgoing channel and fails backwards if either channel's dust sum exceeds the default threshold.
e32ece6
to
25a0fe2
Compare
This is gonna be packaged up in a 0.13.3 release, which will drop before 0.14 |
Commit overview:
lnwallet: introduce GetDustSum method to calculate worst-case dust sum
adds a method onLightningChannel
to calculate worst-case dust on a commitment. It uses an over-estimation currently, but can be changed if somebody can figure out an exact method to count dust w/o under-counting.htlcswitch: extend Mailbox iface with dust, fee methods
allows the mailbox to be dust-aware. Dust is tracked from the time a packet is added (AddPacket
) to the time it's removed (AckPacket
).htlcswitch: extend ChannelLink iface with dustHandler iface
allows the link to callMailbox.SetDustLimits
and bubble up results fromLightningChannel.GetDustSum
.htlcswitch: call evaluateDustThreshold in SendHTLC, handlePacketForward
modifies the switch to be dust-aware so thatSendHTLC
orhandlePacketForward
may fail if dust sum exceeds the new default dust threshold of500000
satoshis.multi: introduce config-level DustThreshold for defining threshold
allows lnd to be started with a command-line option--dust-threshold=
that lets a user define their acceptable dust threshold.Questions:
htlcswitch/switch_test.go
test in this diff is quite slow due to a looping call toSendHTLC
which itself is mostly synchronous. Any way to speed it up? Is this test complete?GetDustSum
method because some HTLC's in the update logs may be removed after a call tocompactLogs
. Is there a way to fix this? There is a double-counting of mailbox dust since packets that are in the mailbox and not yet signed for will also be in the channel's update logs. This decreases the dust through-put of channels.SendHTLC
, should that be modified as well?Related:
max_balance_dust_htlc_msat
lightningdevkit/rust-lightning#1009