Commits on May 25, 2023

1. Allow HTLC receiver to dip into channel reserve …

   When an HTLC is added, the size of the commitment transaction increases
   while that HTLC is pending, which also increases the on-chain fee that
   the channel initiator must deduce from its main output.
   
   Before sending an HTLC, when we're not the channel initiator, we thus
   must ensure that our peer has enough balance to pay for the increased
   commitment transaction fee. We previously went further than that, and
   also required that our peer stayed above their channel reserve.
   
   That additional requirement was unnecessary, and there was no matching
   receiver-side requirement, so it should be safe to delete.
   
   It makes a lot of sense to allow the HTLC receiver to dip into its
   channel reserve to pay the fee for an HTLC they're receiving, because
   this HTLC will either:
   
   - be failed, in which case the balance goes back above channel reserve
   - be fulfilled, in which case the balance increases which also helps
     meet the channel reserve
   
   This also prevents channels from being stuck if the reserve becomes
   dynamic (which will be the case with splicing). Without that change,
   we can end up in a situation where most of the channel funds are on
   the non-initiator side, but they cannot send HTLCs because that would
   make the initiator dip into their reserve to pay the increased fee.
   
   Since this effectively shrinks the channel initiator's reserve, the
   sender must ensure that the resulting reserve is still large enough
   to incentivize the initiator to behave honestly (for example by
   allowing only X% of the channel reserve to be used for fees).

   

   t-bast committed May 25, 2023
   Configuration menu

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

   Copy the full SHA

   cc232a8 View commit details

   Browse the repository at this point in the history