# Disclosure: LND Excessive Failback Exploit

**URL:** <https://delvingbitcoin.org/t/disclosure-lnd-excessive-failback-exploit/1493>\
**Category:** Implementation\
**Tags:** lightning, announcement\
**Created:** [March 4, 2025, 3:58pm UTC](https://delvingbitcoin.org/t/disclosure-lnd-excessive-failback-exploit/1493 "2025-03-04T15:58:58Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![ariard](https://delvingbitcoin.org/letter_avatar_proxy/v4/letter/a/c67d28/32.png) [@ariard](https://delvingbitcoin.org/u/ariard)\
**Post date:** [March 4, 2025, 7:59pm UTC](https://delvingbitcoin.org/t/disclosure-lnd-excessive-failback-exploit/1493/2 "2025-03-04T19:59:03Z")

</div>

> [@morehouse](#):
>
> ```auto
> ## HTLC Output Handling: Remote Commitment, Local Offers
> 
> ### Requirements
> 
> A local node:
> - for any committed HTLC that does NOT have an output in this commitment transaction:
> - once the commitment transaction has reached reasonable depth:
> - MUST fail the corresponding incoming HTLC (if any).
> 
> ```

While the on-chain logic of a LN state machine is notoriously hard to implement correctly and BOLT5 is infamously known to **not** be exhaustive, there is one remark to be made on the proposed specification patch.

If I’m understanding correctly, the new requirement would apply to the situation where a local node has offered an HTLC output, said output included in a remote commitment transaction. If this _offered_ HTLC is not included in the latest commitment transaction, it is proposed to fail the corresponding _received_ HTLC on the incoming pair of commitment transactions.

If my memory is correct, this new mechanism has been already discussed in the past with few LN maintainers and devs in considering some other class of attacks. However, implementing this mechanism comes with the effect that now a LN node force-closes of the incoming channel, even if there is an _economic disproportion_ between the HTLC at risk and the on-chain fee cost to force-close the channel. There is no guarantee on the _interactivity_ of the backward peer. E.g the HTLC might be worth 1000 sats and the force-close absolute fee cost might be 10\_000 sats. As far as I remember, there was no convergence among the LN maintainers of each implementation at the time, what should be the best in this situation and if the fall-back shouldn’t be an _implementation policy_ or a _node settings_ detail.

That it can be still worthy to have a description in BOLT5 of what can be a correct behavior, that I don’t disagree.

---

_[View the full topic](https://delvingbitcoin.org/t/disclosure-lnd-excessive-failback-exploit/1493)._