onchaind might fail to time out an HTLC: maybe fees spiked, or maybe * it decided it wasn't worthwhile. This risks cascading failure if * it was routed: the incoming peer will get upset with us, too. * * So, if we're within 3 blocks of this happening, we fail upstream. * It's weird to do this by looking at hout, rather than hin, but * there's a pointer from hout->hin and not vice versa (we
| 2883 | * there's a pointer from hout->hin and not vice versa (we don't |
| 2884 | * normally need it). */ |
| 2885 | static void consider_failing_incoming(struct lightningd *ld, |
| 2886 | u32 height, |
| 2887 | struct htlc_out *hout) |
| 2888 | { |
| 2889 | /* Already failed or succeeded? */ |
| 2890 | if (hout->failmsg || hout->failonion || hout->preimage) |
| 2891 | return; |
| 2892 | |
| 2893 | /* Has no corresponding input we should be stressed about? */ |
| 2894 | if (!hout->in) |
| 2895 | return; |
| 2896 | |
| 2897 | /* Already done it once? */ |
| 2898 | if (hout->in->failonion) |
| 2899 | return; |
| 2900 | |
| 2901 | /* OK, if we're within 3 blocks of upstream getting upset, force it |
| 2902 | * to fail without waiting for onchaind. */ |
| 2903 | if (height + 3 < hout->in->cltv_expiry) |
| 2904 | return; |
| 2905 | |
| 2906 | /* Unless incoming is already onchain, then it can't get worse! */ |
| 2907 | if (!channel_state_can_remove_htlc(hout->in->key.channel->state)) |
| 2908 | return; |
| 2909 | |
| 2910 | log_unusual(hout->key.channel->log, |
| 2911 | "Abandoning unresolved onchain HTLC at block %u" |
| 2912 | " (expired at %u) to avoid peer closing incoming HTLC at block %u", |
| 2913 | height, hout->cltv_expiry, hout->in->cltv_expiry); |
| 2914 | |
| 2915 | local_fail_in_htlc(hout->in, take(towire_permanent_channel_failure(NULL))); |
| 2916 | } |
| 2917 | |
| 2918 | void htlcs_notify_new_block(struct lightningd *ld) |
| 2919 | { |
no test coverage detected