<p>Thanks for the feedback! I replaced &quot;Update: 0&quot; with a &quot;Funding: 0&quot; which is put on-chain when the channel is opened and the channel parties have both signed the first off-chain &quot;Update: 1&quot;. Note that &quot;Funding: 0&quot; does not have  a settlement path, but can be spent by any of the updates (or cooperatively closed).</p>
<p>This diagram does not yet show all of the features of the current design, but hopefully still helps give the general idea.</p>
<p><a href="https://i.sstatic.net/hKFkA.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/hKFkA.png" alt="Updated Diagram" /></a></p>

CC BY-SA 4.0
2023-04-13T14:30:07.140Z
2023-04-13T14:30:07.140Z
Richard Myers
<p>Current thinking is (I believe) just to have a funding utxo on chain (&quot;Setup_0&quot;) which is always spent by some update transaction (&quot;Update_1&quot; etc; there is no &quot;Settle_0&quot;) which in turn can be spent either by a later update transaction, or, after a relative timelock, by a settlement transaction (&quot;Settle_1&quot; etc). (In this model the update transaction is acting as the trigger step)</p>
<p>See
<a href="https://github.com/instagibbs/bolts/blob/505ab7997bd72708266689a97dcdce9a8f727045/XX-eltoo-transactions.md" rel="nofollow noreferrer">https://github.com/instagibbs/bolts/blob/505ab7997bd72708266689a97dcdce9a8f727045/XX-eltoo-transactions.md</a>
eg.</p>

CC BY-SA 4.0
2023-04-13T14:06:26.867Z
2023-04-13T14:06:26.867Z
Anthony Towns
<p>Yes, you’re reading it right. The construction presented here has a limited lifetime since the <code>Settle_0</code> transaction becomes valid at some point. However, later in the paper, the authors introduce an additional <em>trigger step</em>.</p>
<p>From section “4.2 Settling a contract”:</p>
<blockquote>
<p>In its current form the off-chain protocol has a limited lifetime since the shared output script has a settlement branch that becomes active after a timeout.
[…]
In order to avoid having to refresh the contract on-chain simply to keep the timeouts from expiring, we introduce an additional step in-between the setup phase and the settlement phase: the <em>trigger step</em>.</p>
</blockquote>
<p>The time-lock for the <code>Settle_0</code> is then defined relative to the confirmation of the <code>Trigger</code> transaction. Both <code>Settle_0</code> and the <code>Update</code> transactions then spend the output of the <code>Trigger</code> transaction rather than the output of the <code>Setup</code> transaction. That way channels no longer have a limited lifespan, but an additional transaction is required to close channels unilaterally.</p>

CC BY-SA 4.0
2023-03-07T08:59:33.897Z
Thanks! So with the above construction, you could then just choose an extra long delay for the first state, right? It's unlikely the channel partner "disappears" right after opening a channel anyway.
sutterseba
CC BY-SA 4.0
2023-03-07T11:47:28.977Z
Yes, but you don't want to give too much time, since a malicious counterparty can lock up your funds at whim.
Murch
CC BY-SA 4.0
2023-03-06T16:50:33.770Z
2023-03-06T16:50:33.770Z
Murch
<p>When we open a lightning channel using eltoo / LN symmetry (standard 2/2 multisig), the setup/funding transaction must be recorded on-chain in order to prevent a &quot;double spend&quot; of the funding inputs (and effectively stealing the channel balance).</p>
<p>However, what I do not understand is why that UTXO, now recorded on-chain, cannot be spent via the settlement transaction after the relative timelock has expired. This timelock would otherwise, the way I (miss-)understand it, define the ultimate lifetime of the channel which would be very inconvenient.</p>
<p>What am I missing here?</p>
<p>Including the (great) <a href="https://yakshaver.org/assets/APO_APOAS_eltoo_transaction_diagram.png" rel="noreferrer">graphic from Richard Myers</a> to illustrate what I mean:</p>
<p><a href="https://i.sstatic.net/ddeqF.png" rel="noreferrer"><img src="https://i.sstatic.net/ddeqF.png" alt="enter image description here" /></a></p>

<lightning-network><ln-closing-channels><eltoo>
Eltoo: Does the relative locktime on the first UTXO set the lifetime of the channel?
sutterseba
# Eltoo: Does the relative locktime on the first UTXO set the lifetime of the channel?

(Asked by: username_0 on 2023-03-05)

When we open a lightning channel using eltoo / LN symmetry (standard 2/2 multisig), the setup/funding transaction must be recorded on-chain in order to prevent a "double spend" of the funding inputs (and effectively stealing the channel balance).

However, what I do not understand is why that UTXO, now recorded on-chain, cannot be spent via the settlement transaction after the relative timelock has expired. This timelock would otherwise, the way I (miss-)understand it, define the ultimate lifetime of the channel which would be very inconvenient.

What am I missing here?

Including the (great) [graphic from username_1](https://yakshaver.org/assets/APO_APOAS_eltoo_transaction_diagram.png) to illustrate what I mean:

[![enter image description here](https://i.sstatic.net/ddeqF.png)](https://i.sstatic.net/ddeqF.png)

**Tags:** lightning-network, ln-closing-channels, eltoo


---

## 3 answers

### Answer by username_3 on 2023-03-06. Score: 7 | Accepted answer

Yes, you’re reading it right. The construction presented here has a limited lifetime since the `Settle_0` transaction becomes valid at some point. However, later in the paper, the authors introduce an additional *trigger step*.

From section “4.2 Settling a contract”:

> In its current form the off-chain protocol has a limited lifetime since the shared output script has a settlement branch that becomes active after a timeout.
> […]
> In order to avoid having to refresh the contract on-chain simply to keep the timeouts from expiring, we introduce an additional step in-between the setup phase and the settlement phase: the *trigger step*.

The time-lock for the `Settle_0` is then defined relative to the confirmation of the `Trigger` transaction. Both `Settle_0` and the `Update` transactions then spend the output of the `Trigger` transaction rather than the output of the `Setup` transaction. That way channels no longer have a limited lifespan, but an additional transaction is required to close channels unilaterally.

> **Comments:**
> **username_0**: Thanks! So with the above construction, you could then just choose an extra long delay for the first state, right? It's unlikely the channel partner "disappears" right after opening a channel anyway.  
> **username_3**: Yes, but you don't want to give too much time, since a malicious counterparty can lock up your funds at whim.  

---

### Answer by username_1 on 2023-04-13. Score: 4

Thanks for the feedback! I replaced "Update: 0" with a "Funding: 0" which is put on-chain when the channel is opened and the channel parties have both signed the first off-chain "Update: 1". Note that "Funding: 0" does not have a settlement path, but can be spent by any of the updates (or cooperatively closed).

This diagram does not yet show all of the features of the current design, but hopefully still helps give the general idea.

[![Updated Diagram](https://i.sstatic.net/hKFkA.png)](https://i.sstatic.net/hKFkA.png)


---

### Answer by username_2 on 2023-04-13. Score: 3

Current thinking is (I believe) just to have a funding utxo on chain ("Setup\_0") which is always spent by some update transaction ("Update\_1" etc; there is no "Settle\_0") which in turn can be spent either by a later update transaction, or, after a relative timelock, by a settlement transaction ("Settle\_1" etc). (In this model the update transaction is acting as the trigger step)

See
<https://github.com/instagibbs/bolts/blob/505ab7997bd72708266689a97dcdce9a8f727045/XX-eltoo-transactions.md>
eg.


---

