Refund stuck fees when ics29 is downgraded in an upgrade (edge case scenario) #5738
Labels
29-fee
channel-upgradability
Channel upgradability feature
help wanted
Issues for which we would appreciate help/support from the community
nice-to-have
Summary
There is an edge case scenario where a user incentivizes the next packet to be sent, but before the packet is sent, the channel undergoes an upgrade which removes ics29 from the channel version. This will result in packet fees being left in escrow for a packet that can never be incentivized. We may optionally refund any packet fees leftover in state when downgrading. Because all in-flight packets are flushed, only the next packet to be sent should be capable of having fees in escrow.
It might be possible to reuse the logic in
RefundFeeOnChannelClosure
For now we have decided to leave the behaviour as is.
Discussed during our internal security audit
For Admin Use
The text was updated successfully, but these errors were encountered: