user96871: The Lightning Network Whitepaper 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 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:

Who defines to_self_delay? How does the LN ensure the delay is enough for the counterparty to punish a malicious user?
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.

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


96871: <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>
 101498: <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>
