Add missing pending FundingScope checks
#3811
Conversation
|
👋 I see @wpaulino was un-assigned. |
|
👋 The first review has been submitted! Do you think this PR is ready for a second reviewer? If so, click here to assign a second reviewer. |
jkczyz
force-pushed
the
2025-05-missed-funding-checks
branch
from
bc3ede2 to
30ac751
Compare
|
Good to squash |
jkczyz
force-pushed
the
2025-05-missed-funding-checks
branch
from
30ac751 to
c6b2d01
Compare
|
Oops, sorry more fixups to address lint checks. |
|
@wpaulino Any thoughts on moving the helpers to |
|
Hm yeah I guess we could, let's do the move in its own commit then. Feel free to squash also. |
If there are any pending splices when an update_add_htlc message is received, it must be validated against each pending FundingScope. Otherwise, the HTLC could be invalid once the splice is locked.
If there are any pending splices when a revoke_and_ack message is received, FundingScope::value_to_self_msat needs to be updated for each. Otherwise, the promoted FundingScope will be invalid when the splice is locked.
If there are any pending splices when an update_fee message is received, it must be validated against each pending FundingScope. Otherwise, it may be invalid once the splice is locked.
If there are any pending splices when an sending an update_fee message, the new fee rate must be validated against each pending FundingScope. Otherwise, it may be invalid once the splice is locked.
If there are any pending splices when an accepting an incoming HTLC, the HTLC needs to be validated against each pending FundingScope. Otherwise, once the splice is locked, the HTLC could have been failed when it should have been forwarded / claimed, or vice versa, under the promoted FundingScope.
If there are any pending splices when an sending an update_add_htlc message, the HTLC amount must be validated against each pending FundingScope. Otherwise, it may be invalid once the splice is locked.
Previous commits refactored validation checks in FundedChannel to work on a specific FundingScope. However, keeping these helpers in FundedChannel doesn't prevent them from using self.funding inadvertently instead of the passed in FundingScope. Move these helpers to ChannelContext to avoid this problem, as we done with similar helpers.
jkczyz
force-pushed
the
2025-05-missed-funding-checks
branch
from
c6b2d01 to
b6a92da
Compare
Made a separate commit. Squashed fixups except for the last one in case the second reviewer disagrees on dropping that check. |
|
🔔 1st Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
|
🔔 2nd Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
|
🔔 3rd Reminder Hey @TheBlueMatt! This PR has been waiting for your review. |
|
|
||
| for funding in core::iter::once(&mut self.funding).chain(self.pending_funding.iter_mut()) { | ||
| funding.value_to_self_msat = (funding.value_to_self_msat as i64 + value_to_self_msat_diff) as u64; | ||
| } | ||
|
|
||
| if let Some((feerate, update_state)) = self.context.pending_update_fee { | ||
| match update_state { |
There was a problem hiding this comment.
Can't comment there, but a few lines down funding.is_outbound() is asserted around the pending fee update. I presume is_outbound should move out of funding as its something that now must remain static across splices (and it being in funding implies that we can change that).
| @@ -8080,70 +8207,10 @@ impl<SP: Deref> FundedChannel<SP> where | |||
| } | |||
|
|
|||
| let dust_exposure_limiting_feerate = self.context.get_dust_exposure_limiting_feerate(&fee_estimator); | |||
There was a problem hiding this comment.
nit: seems somewhat wasteful to to pass this in to can_accept_incoming_htlc_for_funding instead of just fetching it from context there?
When sending or receiving
update_add_htlc,update_fee, orrevoke_and_ackmessages, check that the messages (or amount or fee rates, as is appropriate) are valid for any pendingFundingScope. Otherwise, the promotedFundingScopewill be invalid when the splice is locked.This assumes
FundingScope::is_outboundis the same across allFundingScopes. This PR does not fix similar issues for funding negotiation and funding confirmation, which should be handled in #3736 and #3741, respectively.