The attack involves three nodes, A, B, and C, connected by channels. The time locks are set such that node A routes the transaction A->B->C. Node B needs to have a cltv_expiry_delta of 44 or lower to satisfy the LN BOLT requirements.

In the attack scenario, after node B forwards the HTLC (Hashed Time Lock Contract) B->C, node C goes offline, causing all the signed transactions (commitment transaction and HTLC-timeout transactions) to be "stuck" at the feerate at that time. At block height 100, node B notices that the B->C HTLC timelock has expired without node C claiming it. As a result, node B forces the B====C channel on-chain. However, due to rising on-chain feerates, the commitment transaction and HTLC-timeout transaction do not confirm.

Meanwhile, node A is still online with node B and updates the on-chain fees of the A====B channel's pre-signed transactions (commitment tx and HTLC-timeout tx) to the latest fees. At block height 144, node B is still unable to claim the A->B HTLC, so node A drops the A====B channel on-chain, which confirms immediately as the fees are up-to-date, allowing node A to recover the HTLC funds. However, the pre-signed transactions for the B====C channel remain at the old, uncompetitive feerates.

At this point, node C broadcasts an HTLC-success transaction with high feerates, using Child Pays For Parent (CPFP) to push the commitment transaction. This HTLC-success transaction replaces the HTLC-timeout transaction, which is at the old, low feerate. Node C is able to claim the value of the HTLC, but node B can no longer use the knowledge of the preimage since its incoming HTLC was already confirmed as claimed by node A.

The email also explains why the HTLC-timeout transaction is pre-signed and why node B cannot feebump it. In the Poon-Dryja mechanism, the HTLCs are "infected" by the Poon-Dryja penalty case, making them not plain HTLCs. The commitment transaction held by node B is infected by adding a revocation branch (C && revocation) and including node C in the branch claimable by node B in the "plain" HTLC (B && OP_CLTV). These changes are necessary to prevent cheating by node B on old, revoked transactions.

To change the feerate of the HTLC-timeout transaction, both nodes B and C have to agree to re-sign it at a higher feerate. However, the HTLC-success transaction spends the plain (C && OP_HASH160) branch, which only involves node C. This allows node C to feebump the HTLC-success transaction arbitrarily, even without cooperation from node B. Node C has an advantage in fee negotiation because it can RBF (Replace By Fee) the HTLC-timeout transaction out of the way with just one transaction, while node B needs both the HTLC-timeout and a CPFP-RBF of the anchor output of the HTLC-timeout transaction, requiring two transactions.

In conclusion, this attack scenario exploits the timing of channel closures and the difference in feerates between pre-signed transactions to benefit node C at the expense of node B.