Disclosure: LND Excessive Failback Exploit

In the discussion regarding BOLT5, it is highlighted that terminology such as "downstream" or "upstream" is not utilized, emphasizing that lightning channels maintain bidirectional functionality at all times unless specifically configured otherwise, for example, by setting announce_for_forwarding=false in rust-lightning. This detail underlines the inherent flexibility and adaptability of lightning channels in managing transaction directions and conditions.

A noteworthy point raised concerns the handling of HTLCs (Hashed Time-Locked Contracts), particularly in scenarios where there are both 'offered' and 'received' HTLCs pending. This situation introduces a potential for nodes to manipulate the feerate cost of a commitment transaction. Nonetheless, it was clarified that, in the discussed scenario, HTLCs were intended to flow from Mallory to Mallet, correcting a previous statement.

Furthermore, the conversation touches on the procedural aspects dictated by BOLTs (Basis of Lightning Technology specifications) regarding the relay of preimages. It specifies that once a preimage is obtained (downstream), it must be relayed upstream immediately. This procedure involves extracting preimages downstream and sending update_fulfill_htlc upstream without altering the requirements for a node to force-close upstream if its update_fulfill_htlc is not acknowledged.

The dialogue also addresses a pre-existing issue, which predates the changes in BOLTs, related to the mandate that nodes must fulfill the corresponding incoming HTLC as soon as the preimage is known. This is required without awaiting a final revoke_and_ack from the peer or confirmation that a local or remote commitment transaction has been sufficiently confirmed in the blockchain. This adjustment aims to streamline and secure the process of HTLC fulfillment, ensuring timely and efficient transaction confirmations within the lightning network framework.