Commits on Oct 14, 2024

1. Set holder_commitment_point to Available on upgrade …

   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 to `HolderCommitmentPoint::Available` on
   upgrade) to only fetching the current per-commitment-point (setting
   the value to `HolderCommitmentPoint::PendingNext` on upgrade).
   
   In `commitment_signed` handling, we expect the next
   per-commitment-point to be available (allowing us to `advance()`
   the `holder_commitment_point`), as it was included in the
   `revoke_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 a `commitment_signed`
   in the interim.

   

   TheBlueMatt committed Oct 14, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 1486b1b
   • Browse repository at this point

   Copy the full SHA

   1486b1b View commit details

   Browse the repository at this point in the history