user101033: 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?

user52819: 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.

101033: <p>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.</p>
<p>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?</p>
 52819: <p>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).</p>
<p>We're at block 100, and for some reason they're not happy with their channel. Alice tries to close fairly, by publishing <em>update_tx_10</em>. But Bob tries to cheat by publishing <em>update_tx_02</em> which had an associated <em>settlement_tx_02</em> that distributes more funds to him.</p>
<h3>Cheating scenarios</h3>
<ul>
<li><p><strong>Scenario A</strong>: <em>update_tx_10</em> gets confirmed in block 101, making <em>settlement_tx_02</em> invalid (its input has already been spent by <em>update_tx_10</em>). After <em>update_tx_10</em>'s confirmation, Alice and Bob have to wait for n blocks (a value they negotiated) before <em>settlement_tx_10</em> 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 <em>update_tx_10</em>'s output.</p>
</li>
<li><p><strong>Scenario B</strong>: <em>update_tx_02</em> gets confirmed in block 101. Bob thinks &quot;YES I'm gonna steal some of Alice's money!&quot;. However, <em>settlement_tx_02</em> can only spend <em>update_tx_02</em>'s output after 10 blocks so he has to wait.</p>
<ul>
<li><p><strong>Scenario B-1</strong>: Alice publishes a new version of <em>update_tx_10</em>, which now binds to <em>update_tx_02</em> (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 <em>update_tx_10</em>. Bob wanted to wait for the timelock on <em>update_tx_02</em>'s output to expire, but he's out of luck. Miners will not ignore the nice fee that Alice included in <em>update_tx_10</em> and will simply try to mine it in block 102.</p>
<ul>
<li><p><strong>Scenario B-1.a</strong>: Bob takes the loss. He wasn't able to cheat Alice and he accepts that <em>update_tx_10</em> and subsequently <em>settlement_tx_10</em> will be confirmed shortly. The cost of his cheating attempt is the tx fee he paid on <em>update_tx_02</em>.</p>
</li>
<li><p><strong>Scenario B-1.b</strong>: Bob is furious and wants revenge. He publishes <em>update_tx_03</em> which, similarly to <em>update_tx_10</em>, binds to <em>update_tx_02</em>, but with a much higher fee, in the hope of beating Alice to the punch and getting <em>update_tx_03</em> confirmed in block 102.</p>
<ul>
<li><p><strong>Scenario B-1.b1</strong>: <em>update_tx_10</em> gets confirmed and the channel is closed fairly.</p>
</li>
<li><p><strong>Scenario B-1.b2</strong>: <em>update_tx_03</em> gets confirmed and Alice repeats the process started in B-1.</p>
</li>
</ul>
</li>
</ul>
</li>
<li><p><strong>Scenario B-2</strong>: 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 <em>update_tx_02</em> expired, and Bob has gotten <em>settlement_tx_02</em> confirmed as well.</p>
</li>
</ul>
</li>
</ul>
<p>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.</p>
<h3>What about the HTLCs?</h3>
<p>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.</p>
