Support async fetching of commitment point during channel reestablish #4197
Conversation
|
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4197 +/- ##
========================================
Coverage 88.85% 88.86%
========================================
Files 180 180
Lines 137901 138038 +137
Branches 137901 138038 +137
========================================
+ Hits 122533 122666 +133
- Misses 12553 12563 +10
+ Partials 2815 2809 -6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
🔔 1st Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
lightning/src/ln/channel.rs
Outdated
| .ok(); | ||
| if expected_point.is_none() { | ||
| self.context.signer_pending_stale_state_verification = Some((commitment_number, given_secret)); | ||
| return Err(ChannelError::Ignore("Waiting on async signer to verify stale state proof".to_owned())); |
There was a problem hiding this comment.
In practice I think this means we'll often never panic - the peer will reconnect, we'll ignore the message, then they'll send some other message which will cause us to, for example, ChannelError::close("Got commitment signed message when channel was not in an operational state"). We'll either have to have logic in ~every message handler to ignore the message if signer_pending_stale_state_verification is set or we can just disconnect them here and let them be in a reconnect loop until the signer resolves (which I think is fine?).
There was a problem hiding this comment.
Good point, ended up disconnecting. Is there any reason for us to close in those cases though? We could just make those ChannelError::close a WarnAndDisconnect instead.
There was a problem hiding this comment.
No, those cases could definitely move to a warn-and-disconnect. Historically we've been pretty happy to just close if the peer does something dumb, and in 95% of the cases we've never seen peers do anything so dumb, so we've never really had a motivation to change it. Not crazy to do though.
|
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
|
fwiw |
wpaulino
force-pushed
the
async-get-per-commitment-point-channel-reestablish
branch
from
7c25f35 to
6b8123d
Compare
|
|
`HolderCommitmentPoint` currently tracks the current and next point used on counterparty commitments, which are unrevoked. When we reestablish a channel, the counterparty sends us the commitment height, along with the corresponding secret, for the state they believe to be the latest. We compare said secret to the derived point we fetch from the signer to know if the peer is being honest. Since the protocol does not allow peers (assuming no data loss) to be behind the current state by more than one update, we can cache the two latest revoked commitment points alongside `HolderCommitmentPoint`, such that we no longer need to reach the signer asynchronously when handling `channel_reestablish` messages throughout the happy path. By doing so, we avoid complexity in needing to pause the state machine (which may also result in needing to stash any update messages from the counterparty) while the signer response is pending. The only remaining case left to handle is when the counterparty presents a `channel_reestablish` with a state later than what we know. This can only result in two terminal cases: either they provided a valid commitment secret proving we are behind and we need to panic, or they lied and we force close the channel. This is the only case we choose to handle asynchronously as it's relatively trivial to handle.
wpaulino
force-pushed
the
async-get-per-commitment-point-channel-reestablish
branch
from
6b8123d to
fa13381
Compare
3 participants
HolderCommitmentPointcurrently tracks the current and next point used on counterparty commitments, which are unrevoked. When we reestablish a channel, the counterparty sends us the commitment height, along with the corresponding secret, for the state they believe to be the latest. We compare said secret to the derived point we fetch from the signer to know if the peer is being honest.Since the protocol does not allow peers (assuming no data loss) to be behind the current state by more than one update, we can cache the two latest revoked commitment points alongside
HolderCommitmentPoint, such that we no longer need to reach the signer asynchronously when handlingchannel_reestablishmessages throughout the happy path. By doing so, we avoid complexity in needing to pause the state machine (which may also result in needing to stash any update messages from the counterparty) while the signer response is pending.The only remaining case left to handle is when the counterparty presents a
channel_reestablishwith a state later than what we know. This can only result in two terminal cases: either they provided a valid commitment secret proving we are behind and we need to panic, or they lied and we force close the channel. This is the only case we choose to handle asynchronously as it's relatively trivial to handle.