<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>

CC BY-SA 4.0
2022-08-22T04:38:06.517Z
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
CC BY-SA 4.0
2022-08-18T11:54:16.287Z
2022-08-18T11:54:16.287Z
smizzlov
<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>

CC BY-SA 4.0
2022-05-05T07:58:06.017Z
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)
Rene Pickhardt
CC BY-SA 4.0
2022-05-05T08:13:01.273Z
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
<lightning-network><hash-time-locked-contract><eltoo>
Can eltoo's no-penalty design be exploited by malicious submissions of old state?
sphpmp
# Can eltoo's no-penalty design be exploited by malicious submissions of old state?

(Asked by: username_0 on 2022-05-05)

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?

**Tags:** lightning-network, hash-time-locked-contract, eltoo

> **Comments:**
> **username_1**: 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)  
> **username_0**: 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?  

---

## 1 answers

### Answer by username_2 on 2022-08-18. Score: 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.

> **Comments:**
> **username_0**: 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.  

---

