<p>The <code>to_self_delay</code> is a parameter set by the funder of a channel when initiating its creation. The fundee may or may not like it and as a consequence accept or refuse the opening request.</p>
<p>As currently specified, the Lightning Network does not permit the update of this parameter once the channel is opened. It presents some engineering challenges (mainly because of the asynchronous addition of HTLCs) but is conceptually absolutely possible to do so.</p>
<p>Your question is very timely as there has been a lot of discussions around the way to include this feature (dynamic commitment transactions upgrades) in the specs lately. See for example:</p>
<ul>
<li><a href="https://github.com/lightningnetwork/lightning-rfc/pull/868" rel="nofollow noreferrer">https://github.com/lightningnetwork/lightning-rfc/pull/868</a> by Rusty Russell, which relies on the quiescence proposal</li>
<li><a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html" rel="nofollow noreferrer">https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html</a> by Olaoluwa Osuntokun</li>
</ul>

CC BY-SA 4.0
2021-06-10T09:34:45.333Z
Thanks for the response and the material. I don't understand the challenge with HLTCs. BOLT #3 says "The reason for the separate transaction stage for HTLC outputs is so that HTLCs can timeout or be fulfilled even though they are within the to_self_delay delay. Otherwise, the required minimum timeout on HTLCs is lengthened by this delay, causing longer timeouts for HTLCs traversing the network." As I understand, this means HTLC timeouts and `to_self_delay` do not depend on each other. How would a dynamic `to_self_delay` impact HTLCs?
Gabriel Rebello
CC BY-SA 4.0
2021-06-10T12:37:54.510Z
What i meant by "asynchronous addition of HTLCs" is the asynchronous modification of commitment transactions by the peers (conditional addition of outputs) that creates a complex state machine and may result in peers going out of sync and disagreeing on a state. Nothing to do with timelocks conceptually. Only the more dynamic updates (complexity) you add the higher this risk is of synchronization failure (this was the reason for Rusty's quiescence proposal).
Antoine Poinsot
CC BY-SA 4.0
2021-06-09T15:28:22.333Z
2021-06-09T15:28:22.333Z
Antoine Poinsot
<p>According to the <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#the-open_channel-message" rel="nofollow noreferrer">protocol specification at BOLT 2 the <code>open_channel</code> messages suggest</a> <code>[u16:to_self_delay]</code></p>
<p>it further says</p>
<blockquote>
<p><code>to_self_delay</code> is the number of blocks that the other node's to-self outputs must be delayed, using <code>OP_CHECKSEQUENCEVERIFY</code> delays; this is how long it will have to wait in case of breakdown before redeeming its own funds.</p>
</blockquote>
<p>and</p>
<blockquote>
<p>The sending node SHOULD [...] set to_self_delay sufficient to ensure the sender can irreversibly spend a commitment transaction output, in case of misbehavior by the receiver.</p>
</blockquote>
<p>and</p>
<blockquote>
<p>The receiving node MUST fail the channel if [...] the <code>to_self_delay</code> is unreasonably large.</p>
</blockquote>
<p>Similarly without the specifications about size is the <code>accept_channel</code> message.</p>
<p>In practice your lightning implementation should have a config value that lets you choose what blocktime you will find comfortable and if someone tries to open a channel and one party is not comfortable with the value of the others the channel will not be opened in the first place.</p>

CC BY-SA 4.0
2021-06-10T09:12:25.057Z
Thanks for the response, Rene. So this means there is no recommended value, right? Maybe a default value? As I understand, "sufficient" and "unreasonably large" are subjective concepts based on the opinion of each party. It would be nice if we could analyze how many times the parties miscalculate these values and lose money.
Gabriel Rebello
CC BY-SA 4.0
2021-06-10T13:41:09.027Z
as said the values are set on channel opening and I think ever implementation has a config file where you can set them. I believe some use values as large as 2016 blocks. As darosior mentioned they will stay fix through the live time of the channel. I think analyzing how often they have been too low is impossible because once the force close is conducted without penalty we have no way of knowing that this might have been an older state but to little time to execute the penalty.
Rene Pickhardt
CC BY-SA 4.0
2021-06-09T13:32:11.367Z
2021-06-09T13:32:11.367Z
Rene Pickhardt
<p>The <a href="https://lightning.network/lightning-network-paper.pdf" rel="nofollow noreferrer">Lightning Network Whitepaper</a> describes the concept of Revocable Sequence Maturity Contracts (RSMC), which allows a commitment transaction to be revoked during a predefined delay after the channel gets closed unilaterally. As I understand, this means the channel closer (aka the node who published the transaction) must wait for the delay before claiming his/her invested money and, in the meantime, the counterparty can verify the blockchain to see if the closer published the most recent commitment transaction. If the closer published an old transaction, the counterparty can punish him/her by taking all the money in the channel. <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#commitment-transaction" rel="nofollow noreferrer">BOLT#3</a> defines this delay as the <code>to_self_delay</code> variable in a commitment transaction output. However, some aspects about the RSMC implementation remain unclear to me:</p>
<ol>
<li>Who defines <code>to_self_delay</code>? How does the LN ensure the delay is enough for the counterparty to punish a malicious user?</li>
<li>Can the delay change for each commitment transaction? E.g. can two parties decide to decrease the delay if they trust each other more after some transactions?</li>
</ol>
<p>Thanks in advance.</p>

<blockchain><lightning-network><lightning-network-daemon><core-lightning><lightning-rfc>
Delay of a revocable transaction in the Lightning Network
Gabriel Rebello
# Delay of a revocable transaction in the Lightning Network

(Asked by: username_0 on 2021-06-09)

The [Lightning Network Whitepaper](https://lightning.network/lightning-network-paper.pdf) describes the concept of Revocable Sequence Maturity Contracts (RSMC), which allows a commitment transaction to be revoked during a predefined delay after the channel gets closed unilaterally. As I understand, this means the channel closer (aka the node who published the transaction) must wait for the delay before claiming his/her invested money and, in the meantime, the counterparty can verify the blockchain to see if the closer published the most recent commitment transaction. If the closer published an old transaction, the counterparty can punish him/her by taking all the money in the channel. [BOLT#3](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#commitment-transaction) defines this delay as the `to_self_delay` variable in a commitment transaction output. However, some aspects about the RSMC implementation remain unclear to me:

1. Who defines `to_self_delay`? How does the LN ensure the delay is enough for the counterparty to punish a malicious user?
2. Can the delay change for each commitment transaction? E.g. can two parties decide to decrease the delay if they trust each other more after some transactions?

Thanks in advance.

**Tags:** blockchain, lightning-network, lightning-network-daemon, core-lightning, lightning-rfc


---

## 2 answers

### Answer by username_1 on 2021-06-09. Score: 1

The `to_self_delay` is a parameter set by the funder of a channel when initiating its creation. The fundee may or may not like it and as a consequence accept or refuse the opening request.

As currently specified, the Lightning Network does not permit the update of this parameter once the channel is opened. It presents some engineering challenges (mainly because of the asynchronous addition of HTLCs) but is conceptually absolutely possible to do so.

Your question is very timely as there has been a lot of discussions around the way to include this feature (dynamic commitment transactions upgrades) in the specs lately. See for example:

* <https://github.com/lightningnetwork/lightning-rfc/pull/868> by Rusty Russell, which relies on the quiescence proposal
* <https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-July/002763.html> by Olaoluwa Osuntokun

> **Comments:**
> **username_0**: Thanks for the response and the material. I don't understand the challenge with HLTCs. BOLT #3 says "The reason for the separate transaction stage for HTLC outputs is so that HTLCs can timeout or be fulfilled even though they are within the to_self_delay delay. Otherwise, the required minimum timeout on HTLCs is lengthened by this delay, causing longer timeouts for HTLCs traversing the network." As I understand, this means HTLC timeouts and `to_self_delay` do not depend on each other. How would a dynamic `to_self_delay` impact HTLCs?  
> **username_1**: What i meant by "asynchronous addition of HTLCs" is the asynchronous modification of commitment transactions by the peers (conditional addition of outputs) that creates a complex state machine and may result in peers going out of sync and disagreeing on a state. Nothing to do with timelocks conceptually. Only the more dynamic updates (complexity) you add the higher this risk is of synchronization failure (this was the reason for Rusty's quiescence proposal).  

---

### Answer by username_2 on 2021-06-09. Score: 0

According to the [protocol specification at BOLT 2 the `open_channel` messages suggest](https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#the-open_channel-message) `[u16:to_self_delay]`

it further says

> `to_self_delay` is the number of blocks that the other node's to-self outputs must be delayed, using `OP_CHECKSEQUENCEVERIFY` delays; this is how long it will have to wait in case of breakdown before redeeming its own funds.

and

> The sending node SHOULD [...] set to\_self\_delay sufficient to ensure the sender can irreversibly spend a commitment transaction output, in case of misbehavior by the receiver.

and

> The receiving node MUST fail the channel if [...] the `to_self_delay` is unreasonably large.

Similarly without the specifications about size is the `accept_channel` message.

In practice your lightning implementation should have a config value that lets you choose what blocktime you will find comfortable and if someone tries to open a channel and one party is not comfortable with the value of the others the channel will not be opened in the first place.

> **Comments:**
> **username_0**: Thanks for the response, username_2. So this means there is no recommended value, right? Maybe a default value? As I understand, "sufficient" and "unreasonably large" are subjective concepts based on the opinion of each party. It would be nice if we could analyze how many times the parties miscalculate these values and lose money.  
> **username_2**: as said the values are set on channel opening and I think ever implementation has a config file where you can set them. I believe some use values as large as 2016 blocks. As darosior mentioned they will stay fix through the live time of the channel. I think analyzing how often they have been too low is impossible because once the force close is conducted without penalty we have no way of knowing that this might have been an older state but to little time to execute the penalty.  

---

