Eltoo uses the no-penalty submission mechanism, where the cost for an adversary to submit an old state is the transaction fee. This action seems unprofitable, but if we add HTLC to Eltoo, things seem different.

One effect of submitting the old state is delaying the channel settlement. For example, Alice and Bob have an Eltoo channel and the challenge period is 10 blocks. Then, they both intend to close the channel at the block height 100. The difference is that Alice commits the latest state while Bob commits an old one. Suppose Bob's transaction is included in the latest block. Then, Bob continues to compete with Alice for the right to submission and Alice failed to commit the latest state until the block height is 120. At this point, the channel settlement time is delayed from 100 + 10 = 110 to 120 + 10 = 130. If there is an HTLC in the channel with an expiration time of 120, then the adversary's delay changes the attribution of this HTLC. I'm curious if Eltoo will be exploited by the above actions?

  • I am not sure I understand your question. Why is the blockheight suddenly 120? If Bob gets his old update tx in Alice can immediately prevent Bob from getting his settlement in by getting a newer update tx in (already in block 101) May 5, 2022 at 7:58
  • Sorry for the misleading, I need to clarify two points 1. Assuming the latest status is 10, then Bob will start committing from 2. If his transaction is successful, then he will submit 3 next (challenging himself). 2. I'm not sure it's a reasonable assumption that Alice would be able to submit the update tx immediately, I think in a worse case scenario maybe she would need two to three blocks to submit her transaction? (correct me if I'm wrong). A delay of 20 blocks may be an exaggeration, but I'm just curious if this malicious delay affects the correct settlement of HTLC?
    – sphpmp
    May 5, 2022 at 8:13

1 Answer 1


Let's say Alice and Bob have an active eltoo channel. They have transacted 10 times, so there's a history of 10 update txs (as well as 10 accompanying settlement txs, each spending their respective update tx's output).

We're at block 100, and for some reason they're not happy with their channel. Alice tries to close fairly, by publishing update_tx_10. But Bob tries to cheat by publishing update_tx_02 which had an associated settlement_tx_02 that distributes more funds to him.

Cheating scenarios

  • Scenario A: update_tx_10 gets confirmed in block 101, making settlement_tx_02 invalid (its input has already been spent by update_tx_10). After update_tx_10's confirmation, Alice and Bob have to wait for n blocks (a value they negotiated) before settlement_tx_10 can be confirmed, which distributes the funds fairly and in accordance with the final channel balance. Let's say that in this example n = 10. The delay is implemented with a relative timelock in the settlement path of update_tx_10's output.

  • Scenario B: update_tx_02 gets confirmed in block 101. Bob thinks "YES I'm gonna steal some of Alice's money!". However, settlement_tx_02 can only spend update_tx_02's output after 10 blocks so he has to wait.

    • Scenario B-1: Alice publishes a new version of update_tx_10, which now binds to update_tx_02 (instead of to the original funding tx). Since Alice knows she is under attack, she includes a decent (slightly overpaid) fee in this new version of update_tx_10. Bob wanted to wait for the timelock on update_tx_02's output to expire, but he's out of luck. Miners will not ignore the nice fee that Alice included in update_tx_10 and will simply try to mine it in block 102.

      • Scenario B-1.a: Bob takes the loss. He wasn't able to cheat Alice and he accepts that update_tx_10 and subsequently settlement_tx_10 will be confirmed shortly. The cost of his cheating attempt is the tx fee he paid on update_tx_02.

      • Scenario B-1.b: Bob is furious and wants revenge. He publishes update_tx_03 which, similarly to update_tx_10, binds to update_tx_02, but with a much higher fee, in the hope of beating Alice to the punch and getting update_tx_03 confirmed in block 102.

        • Scenario B-1.b1: update_tx_10 gets confirmed and the channel is closed fairly.

        • Scenario B-1.b2: update_tx_03 gets confirmed and Alice repeats the process started in B-1.

    • Scenario B-2: Alice's node crashes and she did not set up any watchtower services for her channel. 5 hours later she got the node working again, but it's too late. The relative timelock on update_tx_02 expired, and Bob has gotten settlement_tx_02 confirmed as well.

Bob can stall the settlement of an eltoo channel, but there is a cost associated to this. Also, Alice has a say in setting the cost, since by increasing the fee on her (final) update transaction, Bob has to follow and increase the fee on his intermediate update transactions to have a chance of winning the confirmation race.

What about the HTLCs?

In all of this, there is no 'problem' for HTLC outputs. A key characteristic of lightning payments is that in case of dispute, you simply put the tx containing the HTLCs on-chain. So, if there are still HTLCs in Alice and Bob's settlement tx, these can simply be resolved on-chain, by spending the HTLC outputs along their redemption or refund paths.

  • Suppose Bob offers Alice an HTLC which expires at block height 120 and Alice knows the preimage. If the channel is settled at block height 100. Then Alice has enough time to unlock the HTLC, and Bob cannot redeem it since the time lock. However, if Bob stalls the settlement to block height 121. Bob can redeem the HTLC since it expires. At this point, even if Alice knows the preimage, she may not be able to get paid. In summary, Bob can redeem the funds he could not have redeemed by stalling channel settlement.
    – sphpmp
    Aug 22, 2022 at 4:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.