Topic: The Lightning Network FAQ - page 10. (Read 33426 times)

Now, this is the step I don't quite understand on how we eliminate trust. Once Dina receives the 100,000 sats, what forbids her from denying to reveal R to Chan?

Secondly, if Chan gets the secret R, what forbids him from not giving it to Bob (so he can later give it to Alice)?

~

I can give you a more detailed explanation on why that's necessary once you confirm that it has worked.

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.

Makes sense. Have you tried setting up a new node (maybe on testnet) and doing a backup creation / restore? If that works you may feel safer in the future.

What's odd to me is that mempool.space labels your actual force close transaction (if I understand correctly) just as a 'Multisig 2 of 2'

I just discovered the guesstoremote method in lightning-hsmtool

(Regarding my 150,000 lost sats)

Does an hsm_secret recover non-cooperatively closed channel's funds?
As far as I understand, hsm_secret is some sort of seed for the internal on-chain wallet.

However, I don't know if it can be used to recover funds with this sort of events:

• Node_1 opened a 300,000 worth of sats channel with Node_2.
• Node_1 sent 150,000 sats to Node_2.
• Node_1 goes offline.
• Node_2 cancels the channel non-cooperatively.
• Can Node_1 recover the bitcoin with hsm_secret?

It's not the $30, but the fact that I lost bitcoin while I'm acting very cautiously drives me crazy.

Ugh. Come on. Who's responsible for the SEO? That thing should be on top for "lightning network visualization".

...

Haven't seen the new mempool.space Lightning software. Smooth! I was thinking of something more user-friendly, less-buggy, not that slow, with no world map, with Tor nodes included, and in 3D. Nodes can be represented as spheres, their sphere size accordingly to their capacity, and user can search the network in a player versus player camera style.

All that's needed is a good parse of lightning-cli listchannels.

Hey guys, I thought of an idea, and I just want you to tell me your opinions: Lightning Network 3D overview (similar to internet-map, but in 3D). As far as I've searched, I haven't found anything other than this: https://explorer.acinq.co/, but that's not smoothly running enough.

That doesn't apply to the average user, who's totally fine with keeping their funds on an exchange.

Isn't ideal, in which manner?

Money and private stuff, which is how I'd characterize my Lightning transactions.

Isn't ideal, in which manner? Sure, anything you do in the cloud is run much faster than in a Raspberry Pi at home, but the home device grants you privacy. I would never host sensitive content on a cloud service, regardless of which company hosted it; and when I say sensitive I mean two things: Money and private stuff, which is how I'd characterize my Lightning transactions.