What about this legendary member Rath_ for his helpful posts on lightning network.

The user was last active four months ago and posted last almost 8 months ago, a tag will not draw their attention.

NEW experimental feature: peer storage - back up your encrypted emergency channel backup with your peers
Protocol updates: Offers (BOLT12) and dual-funding breaking changes to comply with updated lightning spec

So to avoid it you need to broadcast the most up-to-date settlement transaction to the network.

Again, there's a period of time after B broadcasts such a state (closes the channel unilaterally), during which you can come back online and provide a newer state (state 2).

Is the Lightning Network used strictly for small transactions between two parties or can one party use it to send a large quantity of BTC (e.g. 35 BTC) to the other party?  Is there any advantage to sending large amounts using the Lightning Network vs. using the normal bitcoin Blockchain?

First iteration, so keen to hear feedback what other numbers & stats might be of interest.  

Is your node up? Our connection dropped.

I'm just reminding this, because I honestly never understood what was the purpose of all this hassle and bustle. Funds' restoration should be rather trivial thing to do.

But would it also be the case outside of “swaps”, say if the party I'm sending an LN payment to is offline, or if I shut down after sending an LN payment but before they receive it (for whatever reason)?

If I decided to be using lightning network channel, after I have gotten my appropriate wallet for it. How will I now connect my wallet or will the wallet automatically connected main blockchain?

Secondly must recipient also be on lightning network channel before the transaction can take place.?

since i am a noob in the technical stuff, can anyone here say something more about the device?

Stuff such as a Lightning signer seems necessary for the long term. Air-gapped lightning funds aren't possible with the current model.

What binary does it run when I execute lightningd?

I would have expxected a 'Lightning Force Close' transaction to have 1 (Multisig) input and 2 outputs.

While you and I both know how a force close works in theory, I haven't found an actual flow graph or similar, that would definitely help explain the current situation (only one of the 2 nodes got the 'Lightning Force Close' transaction, basically).

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.

max_channel_dbid is your own guess on what the channel_dbid was, or at least the maximum possible value, and is usually no greater than the number of channels that the node has ever had.

Does this also mean anyone that has a nano ledger s would eventually need to get a nano ledger s plus or x in the future?  I know lot of people from years back bought the nano ledger s and store their coins there.  But is there any concern now that because this product is discontinued, it won't work later on in the future such as there won't be any firmware updates for it anymore?

Do you recommend everyone with just a nano ledger s now buy another hardware wallet such as the nano s plus or the x and just input their seed phrase into the new hardware wallet and no longer use the nano ledger s anymore or there is absolutely no need for that now?  

The receiver needs to reveal it! The only reason I know BlackHatCoiner's public key is because we considered opening a channel. There's no way to do keysend without revealing node ID.