Time out incoming HTLCs when we reach cltv_expiry (+ test)#252
Time out incoming HTLCs when we reach cltv_expiry (+ test)#252TheBlueMatt wants to merge 1 commit intolightningdevkit:masterfrom
Conversation
We only do this for incoming HTLCs directly as we rely on channel closure and HTLC-Timeout broadcast to fail any HTLCs which we relayed onwards where our next-hop doesn't update_fail in time.
| }); | ||
| channel_state.claimable_htlcs.retain(|payment_hash, htlcs| { | ||
| htlcs.retain(|htlc| { | ||
| if htlc.cltv_expiry <= height { // XXX: Or <? |
There was a problem hiding this comment.
Sorry what means "XXX: or <?" ? You want to substract a safe delay to height ?
There was a problem hiding this comment.
Oops, lol, ffs, I really need to double-check my own commits before opening PRs, I blame sleep deprivation after 16 hours of being in a plane, thanks for reviewing...That was a note to myself that I'm not sure if the comparison was supposed to be <= or <, I'll double check and fix the PR.
|
utACK, will handle the second part after #198, get done, same kind of problems |
|
As mentionned in #215, we need also to fail AwatingRemoteRAA::AddHTLC if they timed out, so implemented there ariard@56d72cf need to add test and fix the height comparison as for yours (maybe we want to subtract a safe delay to height?) On the last point, don't get you on "failing of inbound HTLCs which we forwarded based on the confirming of downstream HTLC-Timeout transactions" ? If we detect an onchain channel closure why send back UpdateFail to downstream remote peer ? |
2 participants
We only do this for incoming HTLCs directly as we rely on channel
closure and HTLC-Timeout broadcast to fail any HTLCs which we
relayed onwards where our next-hop doesn't update_fail in time.
Partially addresses #215. Note that the failing of inbound HTLCs which we forwarded based on the confirming of downstream HTLC-Timeout transactions is not yet implemented, but that will be the rest of #215.