Actually you can lose bitcoin:

Somewhere in the link:

A lightning node allows HTLCs forwarding (in bolt3's parlance accepted

> HTLC on incoming link and offered HTLC on outgoing link) should settle the

> outgoing state with either a success or timeout before the incoming state

> timelock becomes final and an asymmetric defavorable settlement might

> happen (cf "Flood & Loot: A Systematic Attack on The Lightning Network"

> section 2.3 for a classical exposition of this lightning security property).

>

> Failure to satisfy this settlement requirement exposes a forwarding hop to

> a loss of fund risk where the offered HTLC is spent by the outgoing link

> counterparty's HTLC-preimage and the accepted HTLC is spent by the incoming

> link counterparty's HTLC-timeout.

>

> The specification mandates the incoming HTLC expiration timelock to be

> spaced out by an interval of `cltv_expiry_delta` from the outgoing HTLC

> expiration timelock, this exact interval value being an implementation and

> node policy setting. As a minimal value, the specification recommends 34

> blocks of interval. If the timelock expiration I of the inbound HTLC is

> equal to 100 from chain tip, the timelock expiration O of the outbound HTLC

> must be equal to 66 blocks from chain tip, giving a reasonable buffer of

> reaction to the lightning forwarding node.

>

> In the lack of cooperative off-chain settlement of the HTLC on the

> outgoing link negotiated with the counterparty (either

> `update_fulfill_htlc` or `update_fail_htlc`) when O is reached, the

> lightning node should broadcast its commitment transaction. Once the

> commitment is confirmed (if anchor and the 1 CSV encumbrance is present),

> the lightning node broadcasts and confirms its HTLC-timeout before I height

> is reached.

>

> Here enter a replacement cycling attack. A malicious channel counterparty

> can broadcast its HTLC-preimage transaction with a higher absolute fee and

> higher feerate than the honest HTLC-timeout of the victim lightning node

> and triggers a replacement. Both for legacy and anchor output channels, a

> HTLC-preimage on a counterparty commitment transaction is malleable, i.e

> additional inputs or outputs can be added. The HTLC-preimage spends an

> unconfirmed and unrelated to the channel parent transaction M and conflicts

> its child.

>

> As the HTLC-preimage spends an unconfirmed input that was already included

> in the unconfirmed and unrelated child transaction (rule 2), pays an

> absolute higher fee of at least the sum paid by the HTLC-timeout and child

> transaction (rule 3) and the HTLC-preimage feerate is greater than all

> directly conflicting transactions (rule 6), the replacement is accepted.

> The honest HTLC-timeout is evicted out of the mempool.

>

> In an ulterior move, the malicious counterparty can replace the parent

> transaction itself with another candidate N satisfying the replacement

> rules, triggering the eviction of the malicious HTLC-preimage from the

> mempool as it was a child of the parent T.

>

> There is no spending candidate of the offered HTLC output for the current

> block laying in network mempools.

>

> This replacement cycling tricks can be repeated for each rebroadcast

> attempt of the HTLC-timeout by the honest lightning node until expiration

> of the inbound HTLC timelock I. Once this height is reached a HTLC-timeout

> is broadcast by the counterparty's on the incoming link in collusion with

> the one on the outgoing link broadcasting its own HTLC-preimage.

>

> The honest Lightning node has been "double-spent" in its HTLC forwarding.

>

> As a notable factor impacting the success of the attack, a lightning

> node's honest HTLC-timeout might be included in the block template of the

> miner winning the block race and therefore realizes a spent of the offered

> output. In practice, a replacement cycling attack might over-connect to

> miners' mempools and public reachable nodes to succeed in a fast eviction

> of the HTLC-timeout by its HTLC-preimage. As this latter transaction can

> come with a better ancestor-score, it should be picked up on the flight by

> economically competitive miners.

>

> A functional test exercising a simple replacement cycling of a HTLC

> transaction on bitcoin core mempool is available:

> https://github.com/ariard/bitcoin/commits/2023-test-mempool

>

> ## Deployed LN mitigations

>

> Aggressive rebroadcasting: As the replacement cycling attacker benefits

> from the HTLC-timeout being usually broadcast by lightning nodes only once

> every block, or less the replacement cycling malicious transactions paid

> only equal the sum of the absolute fees paid by the HTLC, adjusted with the

> replacement penalty. Rebroadcasting randomly and multiple times before the

> next block increases the absolute fee cost for the attacker.

>

> Implemented and deployed by Eclair, Core-Lightning, LND and LDK .

>

> Local-mempool preimage monitoring: As the replacement cycling attacker in

> a simple setup broadcast the HTLC-preimage to all the network mempools, the

> honest lightning node is able to catch on the flight the unconfirmed

> HTLC-preimage, before its subsequent mempool replacement. The preimage can

> be extracted from the second-stage HTLC-preimage and used to fetch the

> off-chain inbound HTLC with a cooperative message or go on-chain with it to

> claim the accepted HTLC output.

>

> Implemented and deployed by Eclair and LND.

>

> CLTV Expiry Delta: With every jammed block comes an absolute fee cost paid

> by the attacker, a risk of the HTLC-preimage being detected or discovered

> by the honest lightning node, or the HTLC-timeout to slip in a winning

> block template. Bumping the default CLTV delta hardens the odds of success

> of a simple replacement cycling attack.

>

> Default setting: Eclair 144, Core-Lightning 34, LND 80 and LDK 72.

>

> ## Affected Bitcoin Protocols and Applications