The Lightning Network FAQ

[BlackHatCoiner]

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

I wouldn't name such person "the average user". More like "newbie" or "in just for the money". A bitcoin user does self-custody; I hope we can all agree to this. Therefore, a person who's registered at an exchange that owns bitcoin for him, isn't a bitcoin user, but an exchange user.


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.

[1714608139]

1714608139

[1714608139]

1714608139

[1714608139]

1714608139

[1714608139]

1714608139

[n0nce]

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.

Kind of something like this?

[BlackHatCoiner]

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.

[n0nce]

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.

Interesting! I've never seen something like that myself in general (not for internet servers, either). But it sounds cool. I'm not skilled in web development myself, but would love playing around with such a webpage if it ever comes into existence.

Hey - to all the bored web devs - here's a free $1M idea for you!

[Cricktor]

...

How about https://github.com/MaxKotlan/LN-Visualizer and working website to test it at lnvisualizer.com?

[BlackHatCoiner]

Yes. Yes, about that. 

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

[Cricktor]

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

They don't want to be found and used that easily. You should run your own instance... a wild guess.

[BlackHatCoiner]

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

[n0nce]

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

That's my understanding, too, so my answer would be yes.

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?

Yes, exactly. But there are other risks when Node_1 goes offline, due to which the funds may be lost / stolen.
Node_2 could publish an older commitment, for example (not the case here, I know).

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

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.

Other things to try...
Have you tried to generate seed words from hsm_secret and restore those in Electrum?

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':
https://mempool.space/tx/137c7c044bd4027cde671187a1f38821a4509250b35693f3e3faa965253eb30f

Meanwhile, the address of Node_2 also got a second transaction labeled as 'Lightning Force Close' (1 input, 1 output) and Node_1's address still sits there with all its funds, so it lacks a similar transaction.
https://mempool.space/address/bc1qz9354tux3tzllhr2r3phktp65ghugl3sh09wjvtdl882rdf346gsgnfjxv
https://mempool.space/address/bc1qk82d4lc0fq8sy30804gwzx7qc8njydthcqp535

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


I just discovered the guesstoremote method in lightning-hsmtool. Not sure why it's even required to brute force anything, but worth a try, I guess.
dumponchaindescriptors should also give you a bunch of addresses derived from your hsm_secret, so you could match and see if https://mempool.space/address/bc1qk82d4lc0fq8sy30804gwzx7qc8njydthcqp535 is one of them.

[BlackHatCoiner]

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.

Yes, I tried it with a new testnet node. Backup recovery worked.

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 think that's what it should show. The multi-sig sent 150,000 sats to bc1qz9 and another 149,695 to bc1qk8. Once the bc1qz9 spent that UTXO, mempool.space labeled it as "Lightning Force Close". The bc1qk8 has not spent anything and that's probably why it doesn't show anything either.

But, I just noticed something. The initial multi-sig address (bc1q8lyz0239h864putwe9ue9zug75tmvg5mx8ug7uctxkyfe4jv2fgskrflw8), once the channel was closed non-cooperatively, sent money to another multi-sig (which was used by my properly working node later) and the rest to a single-sig address (which are currently inaccessible). Once my properly working node received the money, it spend them 1 day and 2 minutes later to one of its on-chain addresses (as far as I can see here). Therefore, the single-sig funds have to be recovered from this hsm_secret I have, as it was created 10 days before this non-cooperative closing.

I just discovered the guesstoremote method in lightning-hsmtool

I don't understand why max_channel_dbid is necessary, and I don't have it either.

[Rath_]

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

I made a post explaining the uncooperative channel close some time ago.

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.

In this case, node 2 broadcast a commitment transaction with the following outputs:

1) RSMC (P2WSH)- this output can be spent by node 2 after 144 blocks. Node 2 should move those coins to its own address as soon as possible in case node 1 somehow got their hands on the revocation key.
2) Standard output (P2WPKH) - this output can be immediately spent by node 1

So, what can you do to recover your coins? Well, use lightning-hsmtool guesstoremote just like @n0nce has already suggested. As for max_channel_dbid....

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.

You have to count all channels - even closed ones. So, if your node has had a total of 3 channels, you should set that parameter to 3.

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

[BlackHatCoiner]

Thanks for the detailed response.

Let me brief the docs. I need to run "guesstoremote p2wpkh node_id max_channel_dbid hsm_secret", where p2wpkh I enter my non-accessible address (that is, bc1qk82d4lc0fq8sy30804gwzx7qc8njydthcqp535), where node_id the public key of the node that closed the channel non-cooperatively, where max_channel_dbid my max guess of opened channels (I'll say about 15, so 15), and where hsm_secret the location of my hsm_secret. Is that correct?


Yep, it is!

9,001 sats to both of you via keysend.  

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

So, what's about that max_channel_dbid?

[n0nce]

~

Thanks for the thorough explanation! I think I got it now.

I tried to visualize my understanding below. I'm still unsure why the force close outputs need to be spent (quickly), though.

Code:

         ┌────────────────────────────────────────────────────────────────┐
         │ Address (Multisig)      Channel open (single-funded)           │
         │                                                                │
         │ bc1q8lyz0239h864putwe9ue9zug75tmvg5mx8ug7uctxkyfe4jv2fgskrflw8 │
         └─────────────────────────────┬──────────────────────────────────┘
                                       │
                                       │
                     ─┬────────────────┴─────────────────┬─
                      │ Transaction (Force Close)        │
                      │                                  │
                      │ 137c7c044bd4027cde671187a1f38821 │
                      │ a4509250b35693f3e3faa965253eb30f │
                     ─┴─────────────┬─────┬──────────────┴─
                                    │     │
                       ┌────────────┘     └────────────┐
                       ▼                               ▼
┌──────────────────────────────────────────┐ ┌──────────────────────────────────────────────────────────────┐
│Address (single-sig, node 1)              │ │Address (single-sig, node 2)                                  │
│bc1qk82d4lc0fq8sy30804gwzx7qc8njydthcqp535│ │bc1qz9354tux3tzllhr2r3phktp65ghugl3sh09wjvtdl882rdf346gsgnfjxv│
└──────────────────────┬───────────────────┘ │                                                              │
                       │                     │Time locked 1day                                              │
                       │                     └─────────┬────────────────────────────────────────────────────┘
                       │                               │
                       ▼                               ▼
      Can spend immediately using pk          Spent to own address ASAP
             from guesstoremote

[CryptKeeper]

[BlackHatCoiner]

This is also impressive: https://bl.ocks.org/tyzbit/d1c83732d2767bb955125d41f5921888

[BlackHatCoiner]

I'm reading lnbook - onion routing, and I feel that the authors, while they've done a great job, don't make this clear enough. My question is: How do you ensure transaction finality with onion routing?

Alright, so let's take the same example. Alice wants to send 100,000 sats to Dina, and Bob & Chan are intermediaries.

 1. Dina sends Alice her secret R's hash (H).
 2. Alice tells Bob that if he pays Chan 100,100 sats, she'll pay Bob 100,200 sats if he gives her R.
 3. Bob tells Chan that if he pays Dina 100,000 sats, he'll pay Chan 100,100 sats, if Chan gives him R.
 4. Chan pays Dina 100,000 sats, if Dina gives him R.

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)?

Thirdly, as far as I can tell, the user who firstly moves money is Chan (to Dina). Then, Chan expects from Bob to get the 100,100 sats. What forbids Bob from denying to give it to him?

I'm 99% sure that I lose it when it comes to the OP_SHA256 H OP_EQUAL scripts. How do Alice, Bob, Chan and Dina eliminate trust, ensure that R will reach Alice, and all that with every sat being sent rightly? Is there a chance the money "get stuck" in the middle?

[n0nce]

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?

If she doesn't reveal it, Chan's 'payment' doesn't 'get through', as the channel state update script requires Dina to reveal R to receive the payment. Chan commits to the payment, under that condition and can't revoke this commitment either.
Commitment schemes in general, are a pretty great invention for this type of stuff!

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

Similar thing: Chan only actually 'gets the payment' from Bob if he reveals R.
After that, 'turtles, all the way down'.

The 3 minutes of this video starting at 13:15 explain it quite well:
https://youtu.be/yKdK-7AtAMQ?t=796

[CryptKeeper]

[CryptKeeper]

[franky1]

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?

If she doesn't reveal it, Chan's 'payment' doesn't 'get through', as the channel state update script requires Dina to reveal R to receive the payment. Chan commits to the payment, under that condition and can't revoke this commitment either.
Commitment schemes in general, are a pretty great invention for this type of stuff!

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

Similar thing: Chan only actually 'gets the payment' from Bob if he reveals R.
After that, 'turtles, all the way down'.

The 3 minutes of this video starting at 13:15 explain it quite well:
https://youtu.be/yKdK-7AtAMQ?t=796

and now you all know that Dina gets paid using chens money

which if there is a break in the route. like if bob goes offline chen doesnt get paid
thus alice keeps her funds too because she to doesnt pay bob. and now Dina has been paid walking off pretty happy to get free money and alice walks off happy knowing dina accepted payment for goods designated to go to alice, without alice paying..

thanks chen you paid for alices goods

along with blackhat having issues of missing funds where he cant find the key to spend it via a simple methods.. and needing to hack his own wallet to find the keys(facepalm)

yep LN is even more riskier and flawed than a pegged sidechain like Luna

but its good you guys are now seeing, experiencing the flaws instead of the utopian dreams of XXXevent s earning XXprofit messages you previously only wanted to talk about.

bitcoin works. no stress. just put in the destination address and amount. and wait for confirm.. done..
imagine a average joe using LN. like a el salvador citizen using LN last year as the backnobe of chivo.. ooopps. LN failed thousands of times for thousands of people

do you now see why LN is not a "solution" or better than bitcoin...