The attack involves three nodes, A, B, and C, connected through channels. ZmnSCPxj explains that as long as node B has a cltv_expiry_delta of 44 or lower, the attack satisfies the LN BOLT requirements.

The attack begins when node C goes offline after node B forwards an HTLC (Hashed Time-Lock Contract) from B to C. As a result, all the signed transactions, including the commitment transaction and HTLC-timeout transactions, are stuck at the feerate at that time.

At block height 100, node B realizes that the HTLC timelock from B to C has expired without C claiming it. Consequently, B forces the B-C channel onchain. However, due to increased onchain feerates, the commitment transaction and HTLC-timeout transaction do not confirm.

Meanwhile, node A is still online with B and updates the onchain fees of the A-B channel's pre-signed transactions (commitment tx and HTLC-timeout tx) to the latest fees.

At block height 144, B is still unable to claim the A-B HTLC, so A drops the A-B channel onchain. Since the fees are up-to-date, this confirmation happens immediately, allowing A to recover the HTLC funds. However, the feerates of the B-C pre-signed transactions remain at the old, uncompetitive rates.

At this point, C broadcasts an HTLC-success transaction with high feerates that Child-Pays-For-Parent (CPFPs) the commitment transaction. This action replaces the HTLC-timeout transaction, which has a low feerate. Consequently, C successfully receives the value of the HTLC, but B can no longer use the knowledge of the preimage since its incoming HTLC was already confirmed as claimed by A.

ZmnSCPxj seeks confirmation if the restatement of the attack scenario is accurate. Additionally, they explain why the HTLC-timeout is pre-signed and why B cannot feebump it.

In the Poon-Dryja mechanism, HTLCs are "infected" by the Poon-Dryja penalty case, making them not plain HTLCs. A plain HTLC offered by B to C follows the format: (B && OP_CLTV) || (C && OP_HASH160). However, on the commitment transaction held by B, the HTLC is infected by the penalty case in the following way: (B && C && OP_CLTV) || (C && OP_HASH160) || (C && revocation).

This mechanism introduces two changes: the addition of a revocation branch (C && revocation), and the inclusion of C in the branch claimable by B in the "plain" HTLC (B && OP_CLTV). These changes are necessary to prevent cheating by B when the HTLC is on an old, revoked transaction.

To further secure against cheating attempts, an HTLC-timeout transaction is introduced. It spends the (B && C && OP_CLTV) branch and outputs to: (B && OP_CSV) || (C && revocation). This ensures that even if B holds onto a very old revoked commitment transaction and attempts to spend the timelock branch, it still has to contend with a new output with a relative timelock.

Unfortunately, the HTLC-timeout transaction needs to be pre-signed and has a specific feerate. To change the feerate, both B and C must agree to re-sign the HTLC-timeout transaction at a higher feerate. However, the HTLC-success transaction spends the plain (C && OP_HASH160) branch, involving only C. This allows C to feebump the HTLC-success transaction arbitrarily, even if B does not cooperate.

ZmnSCPxj concludes by highlighting that C has a greater advantage in this scenario because they can Replace-By-Fee (RBF) the HTLC-timeout out of the way with just one transaction. On the other hand, B needs both an HTLC-timeout CPFP-RBF and an anchor output CPFP-RBF, requiring two transactions. This advantage allows C to achieve a particular feerate with a smaller fee due to pushing a smaller number of bytes compared to B.