[0.2] Backport of #4580#4686
Conversation
This was a drive-by fix in a4bf94a
In 0FC channels, capping the reserve to the total value of the channel allowed a splice initiator to withdraw past their reserve in case the acceptor had no balance in the channel. This is because the post-splice value of the channel was equal to the initiator's post splice balance. Hence, this post splice balance always matched the reserve, even though the reserve was below the dust limit. The only thing that prevented the initiator from withdrawing all their balance was the script dust limit check in `interactivetxs::NegotiationContext::receive_tx_add_output`. In case the splice acceptor had any balance in the channel, or there were HTLCs in the channel, or the channel was not 0FC, the splice initiator's post-splice balance was always below the full channel value. Hence when the reserve was capped at the channel value, the post-splice balance was always below the reserve, and the splice was rejected. Also, in `validate_splice_contributions`, to determine the `counterparty_selected_channel_reserve`, we now read the holder's dust limit from the context, instead of the current global constant. Backport of 3835f84
We made the same change to the calculation of the v2 reserve in the previous commit. Backport of 53e156a Here their `dust_limit_satoshis` can never be greater than `MIN_THEIR_CHAN_RESERVE_SATOSHIS`, so by making sure that `channel_value_satoshis` is greater than `MIN_THEIR_CHAN_RESERVE_SATOSHIS`, we also make sure that `channel_value_satoshis` is greater than their `dust_limit_satoshis`.
|
👋 Thanks for assigning @TheBlueMatt as a reviewer! |
|
I reviewed all changes thoroughly. The reserve helper refactor ( No issues found. |
3 participants
No description provided.