2

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:

  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.

Improve this question

2 Answers 2

Reset to default
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:

Improve this answer
2
  • 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
    Commented Jun 10, 2021 at 9:34
  • 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
    Commented Jun 10, 2021 at 12:37
0

According to the protocol specification at BOLT 2 the open_channel messages suggest [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.

Improve this answer
2
  • 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
    Commented Jun 10, 2021 at 9:12
  • 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
    Commented Jun 10, 2021 at 13:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.