Quote from: ndalliard on Today at 07:05:24 AM

the wording here is a little bit off imo. i guess you are not talking about the lightning technology used on another network than bitcoin. that means the lightning network it is clearly dependent on the bitcoin network and also i would say, that both networks have an impact on each other. i agree with the last part, that no one is force to use neither networks (some say people in el salvador are now force to use it, but that is another topic)

I get your point. I should mention there is a possible risk of flooding the network if a large number of channels is closed at once. Uncooperative channel close results in 2 on-chain transactions, so that's how someone could do even more damage.

A few moments ago, I answered ndalliard's question about timelocks in the commitment transactions. I ended up explaining in detail how uncooperative channel close is performed. Some of you might find it interesting.

Quote from: Rath_ on Today at 01:00:54 PM

Quote from: ndalliard on Today at 09:42:11 AM

is the period of that timelock every time a new commitment is broadcastet updated? so it is a moving timeframe? and that timeframe will be set in stone with the opening transaction on the base layer, is that correct?

I might have phrased that slightly wrong, so let me explain it in more detail. If you are closing a channel uncooperatively, there are actually two on-chain transactions involved instead of just one.

First of all, the timelock is decided before the channel is established. By default, most nodes force the other peer to wait 144 blocks (~1 day). The maximum acceptable value by default is 2016 blocks (~2 weeks). I configured my node to create channels with their_to_self_delay = 432 blocks (~3 days), so if someone decides to close the channel opened to my node uncooperatively, they will have to wait 432 blocks (after the commitment transaction has been included in a block) before they can spend the output belonging to them. Those timelocks are relative which means that you do not have to sign a new commitment transaction whenever a new block is mined. New commitment transactions are signed periodically because their fees need to match the current state of the mempool. There is no point in paying 60 sat/vbyte when 1 sat/vbyte transactions are getting confirmed in just a few minutes. It also applies the other way around.

The first transaction is the commitment transaction. Let's say there's node A(lice) and node B(ob), and node A broadcasts the commitment transaction. That commitment transaction includes two outputs:

- output #0: 3 BTC (spendable by node B's private key) - reflecting node B balance
- output #1: 6 BTC (RSMC) - reflecting node A balance

There is one more important detail before we go any further. Whenever a new commitment transaction is signed, both parties exchange revocation keys for the previous commitment transaction so that they can both be sure that the other party is very unlikely to broadcast an old state of the channel.

RSMC is short for Revocable Sequence Maturing Contract. Such an output contains a relative timelock. This means that you can't spend this output until a certain amount of blocks have been mined since the transaction which includes that output was mined.

Let's say node B didn't change the default value of 144 blocks and the commitment transaction has been confirmed. There are two possible scenarios.

1) Node A attempts to cheat and broadcast an old commitment transaction. Node B has 144 blocks to spend the RSMC output using his and node A's revocation key which he got while they were working on a new commitment transaction.

2) Node A broadcasts the latest commitment transaction. In such a case, node B never got node A's revocation key for that commitment transaction, so he cannot spend that RSMC. Node A can broadcast another transaction spending that output after 144 blocks have been mined.

I know it sounds complicated. I am working on a thread which will explain it in a more understandable way.