Bitcoin Stack Exchange is a question and answer site for Bitcoin crypto-currency enthusiasts. It only takes a minute to sign up.
Sign up to join this community
Anybody can ask a question
Anybody can answer
The best answers are voted up and rise to the top
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.
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
According to the protocol specification at BOLT 2 the open_channel messages suggest [u16:to_self_delay]
it further says
to_self_delayis the number of blocks that the other node's to-self outputs must be delayed, usingOP_CHECKSEQUENCEVERIFYdelays; 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_delayis 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.
You can get bonuses upto $100 FREE BONUS when you:
💰 Install these recommended apps:
💲 SocialGood - 100% Crypto Back on Everyday Shopping
💲 xPortal - The DeFi For The Next Billion
💲 CryptoTab Browser - Lightweight, fast, and ready to mine!
💰 Register on these recommended exchanges:
🟡 Binance🟡 Bitfinex🟡 Bitmart🟡 Bittrex🟡 Bitget
🟡 CoinEx🟡 Crypto.com🟡 Gate.io🟡 Huobi🟡 Kucoin.
Comments