Topic: The Lightning Network FAQ - page 36. (Read 32053 times)

I am pleased to announce that I and ndalliard are (probably) the first bitcointalk members to open a dual-funded channel

You guessed right, ser. Those altcoin “Lightning Networks” are their developers implementing it for themselves, probably truly as a computer science experiment/test, but to some of them, probably just for riding the bandwagon.

When you posted “impact”, I thought you believed that Lightning would truly have a strong influence on the consensus layer.

just because it is called "off-chain" doesn't mean it doesn't impact bitcoin the base layer, if you think about it, you have to do at least two transactions for every channel (okay maybe one if you count channels you will "never" close), but my point is: it impacts the base layer, cause lightning needs a base layer and using it means that there is an impact / influence, whatever you want to call it - or are we takling about two different things here?

I get your point. I should mention that 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.

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 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.

Lightning is an “off-chain” layer and doesn’t impact the Bitcoin blockchain/the base layer.

awesome faq, was a pleasure to read


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)

Is Lightning Network centralized? Is it more centralized than Bitcoin? Does it make Bitcoin more centralized?

This topic has been brought up many times. The Lightning Network is a second layer scaling solution which has no impact on the Bitcoin network. It works independently and no one is forced to use it.

Weren't you going to move your c-lightning node and keep it running?

Edit: you probably asked about https://lightning.network/lightning-network-paper.pdf point "8.1 Decrementing Timelocks" in LN whitepaper version 0.5.9.2.

I managed to get the node back up and broadcast the close channels.

You always have your channel closing transaction after depositing coins. And that means if someone is not cooperating, it does not matter if that node lost the keys or if is simply offline, you can always close the channel and then open another one with someone else.

Every time you deposit something, the closing transaction is constructed and signed upfront, in this way you are always protected when another party stops cooperating.

The Mk node fails. And then the confirmation does not go further.

In the event a party outright disconnects, the counterparty will be responsible for broadcasting the current Commitment Transaction state in the channel to the blockchain.  Only the failed non-responsive channel state gets closed out on the blockchain, all other channels should continue to update their Commitment Transactions via novation inside the channel.

That is the only option, because in other cases some nodes will receive payments and others do not. And that's not how it works: you have a route from A to B and this route as a whole is either completed or not. If it is completed, then fine, every node updates its closing transaction. But if there is any problem at any point of this transaction chain, then everything is rolled back to the state as if that payment from A to B was never started. If some node will try to use any state of "half-baked coins", then some penalty transaction will be broadcasted by some other node.

1) If node B does not receive confirmation during the timeout period, the transaction is considered incomplete.

It is solved by timeouts. You start from some huge timeout of "N*unit" and decrease it by "unit" for each node. In this way, timeouts are reached from the last node to the first. That means the first node cannot simply run away with its coins, because the timeout for the last node occurs first. Also, there are penalty transactions, so each node doing stupid things is putting the whole channel balance at risk.

Let A be the last node that has a closing channel transaction updated. How does node B know that everything ended well and all nodes were updated.

They don't, because nodes don't blindly trust that LN internal transactions (with HTLC and millisatoshis) are final. They are final only when closing channel transactions are updated for each node.

What would happen if the lightning node you chose, lost its multi-sig key after you deposited your coins?

I obviously know the answer, I just want to ensure that it can't happen in my future deposits.

What happens if the Mk node fails at the time of transmitting this information.

Nodes A, M1, ..., Mk-1 will assume that the transaction is completed. And the nodes Mk+1,...Mn,B will remain in uncertainty.