The attack involves three nodes, labeled A, B, and C, connected by channels. ZmnSCPxj describes the timelocks set for routing transactions between the nodes. According to the Lightning Network BOLT requirements, node B must have a cltv_expiry_delta value of 44 or lower.

The attack scenario begins when node C suddenly goes offline after node B forwards an HTLC (Hash Time-Locked Contract) transaction to it. This causes all the signed transactions, including commitment transactions and HTLC-timeout transactions, to be "stuck" at the feerate at the time. At block height 100, node B realizes that the HTLC timelock has expired without node C claiming it. As a result, node B forces the B====C channel to be settled on-chain.

However, due to the rise in on-chain feerates, the commitment transaction and HTLC-timeout transaction do not confirm. Meanwhile, node A, which is still online with node B, 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 decides to settle the A====B channel on-chain. Since the fees are up-to-date, this settlement confirms immediately, 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 that Child-Pays-for-Parent (CPFPs) the commitment transaction. By replacing the HTLC-timeout transaction, which has a low feerate, node C successfully claims the value of the HTLC. Unfortunately, node B is no longer able to use the knowledge of the preimage, as its own incoming HTLC has already been confirmed as claimed by node A.

In addition to explaining the attack, ZmnSCPxj clarifies why the HTLC-timeout transaction is presigned and why node B cannot feebump it. In the Poon-Dryja mechanism used in the Lightning Network, the HTLCs are "infected" by the Poon-Dryja penalty case, making them different from plain HTLCs. ZmnSCPxj provides a comparison between a plain HTLC offered by node B to node C and the infected version of it on the commitment transaction. The infected version includes a revocation branch and includes node C in the branch claimable by node B. These additions are necessary to prevent cheating by node B on an old, revoked transaction.

To handle the timelock issue, an HTLC-timeout transaction is introduced, which spends the branch involving node B and node C and has a relative timelock. Unfortunately, this means that the HTLC-timeout transaction must be presigned with a specific feerate. Changing the feerate requires both node B and node C to agree to re-sign the transaction at a higher feerate. On the other hand, the HTLC-success transaction spends the plain (C && OP_HASH160) branch, involving only node C. This allows node C to feebump the HTLC-success transaction arbitrarily, even if node B does not cooperate.

ZmnSCPxj points out that node C has a greater advantage in this scenario because it can Replace-By-Fee (RBF) the HTLC-timeout transaction with just one transaction, while node B needs to perform both CPFP-RBF for the HTLC-timeout and anchor output transactions, requiring two transactions. As a result, node C can achieve a particular feerate with a smaller fee compared to node B.

In conclusion, ZmnSCPxj provides a detailed explanation of an attack on the Lightning Network that takes advantage of specific conditions and transaction structures within the network.