In the scenario outlined, the focus is on the potential issues that arise when a revoked commitment transaction gets confirmed. Bob, portrayed as the attacker, broadcasts such a transaction. While Bob's motivations or outcomes are not of concern since he is the attacker, the implications for Alice, the honest participant, are considered.

Alice's strategy involves attempting to spend the HTLC outputs by utilizing the revocation path of the commitment transaction. She has the advantage of choosing a low feerate for her transaction because, at this juncture, Bob cannot sweep the funds immediately due to the revoked transaction. Bob may attempt to disrupt Alice's transactions by using his HTLC-x transactions, aiming to create a pinning vector against Alice. However, this maneuver does not present a significant threat to Alice as she is not under time pressure for her transactions to confirm.

If Bob's HTLC-x transaction does confirm, he encounters a to_self_delay CSV, meaning he must wait before he can sweep the output from his own HTLC-x transaction. This delay serves as a security mechanism. Moreover, Bob incurs the cost of transaction fees to mine his transaction, which is an additional disadvantage for him.

On the flip side, Alice benefits regardless of Bob's actions. Even if Bob's transaction confirms, Alice retains the ability to sweep the output from Bob's HTLC-x transaction via the revocation path. This process ensures that she can eventually secure what she is owed. Consequently, the system is designed in such a way that even if an attacker like Bob were to confirm a revoked commitment transaction, honest participants like Alice have mechanisms in place to protect their interests and recover their funds.