Set holder_commitment_point
to Available
on upgrade
#3365
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When we upgrade from LDK 0.0.123 or prior, we need to intialize
holder_commitment_point
with commitment point(s). In 1f7f3a3 we changed the point(s) which we fetch from both the current and next per-commitment-point (setting the value toHolderCommitmentPoint::Available
on upgrade) to only fetching the current per-commitment-point (setting the value toHolderCommitmentPoint::PendingNext
on upgrade).In
commitment_signed
handling, we expect the next per-commitment-point to be available (allowing us toadvance()
theholder_commitment_point
), as it was included in therevoke_and_ack
we most recently sent to our peer, so must've been available at that time.Sadly, these two interact negatively with each other - on upgrade, assuming the channel is at a steady state and there are no pending updates, we'll not make the next per-commitment-point available but if we receive a
commitment_signed
from our peer we'll assume it is. As a result, in debug mode, we'll hit an assertion failure, and in production mode we'll force-close the channel.Instead, here, we fix the upgrade logic to always upgrade directly to
HolderCommitmentPoint::Available
, making the next per-commitment-point available immediately.We also attempt to resolve the next per-commitment-point in
get_channel_reestablish
, allowing any channels which were upgraded to LDK 0.0.124 and are in this broken state to avoid the force-closure, as long as they don't receive acommitment_signed
in the interim.This was included in the 0.0.125 release.