LN is infact less private. because they name tag their channels/nodes. bitcoin addresses dont name tag their addresses by default
That's a good point; yes. I don't think you can name tag channels, but you can name tag nodes and I'd advice against that. Otherwise I could find your node by your username and see who you have channels with and now much balance is in there. It would still be extremely hard to find out when, to whom and how much you transact in those channels, but the information that is easy to gather may already be too much for many people's privacy standards.
firstly he called himself ignorance, and was blaming himself for the issues..
well if he has issues regaining some custody of funds just because he switched off his node.. that is a NODE flaw. not a human flaw.
The issue wasn't switching it off, but not having / not being certain about your backups. Compare it to someone running Bitcoin Core and not having backed up their private keys. Do you blame Bitcoin Core for that? Let's go a step further: Bitcoin Core has no easy to write down seed phrase backups; would you blame it on Bitcoin Core if someone lost their funds due to a hardware failure of their Core node?
bitcoin does not lose its keys/wallet when you close the wallet. people cant make moves against your funds if you just go to bed or turn your node off.. yet in LN they can!!!
That's correct; but keep in mind this was about a hardware failure.
Also keep in mind, nobody ever claimed Lightning to be 'as good' in
everything as Bitcoin Core. You do have some tradeoffs (e.g. in caution / backups / ..), for the benefits you get (speed, costs). It kind of makes sense; you gain some, lose some. You can't have everything..
having a risk that a competitor(partner) can take action and steal funds just because you turned off your computer or went to sleep is not a human flaw. its a protocol flaw
Not a flaw; a design necessary to achieve the goals an off-chain system wants to achieve. And this point can be relativized; if you know you're going to turn your node off for extended periods of time often, you can set a longer lock time and reduce this risk by 99.9999%.
this topic is about lightning observing. and i am observing lightning.
YOU may think its a topic of "lightning admiration" or "lightning kiss-assing" and only admiration should be mentioned. but some people want to know the con's too not just the dreamy utopian pro's of fantasy and fake promises
It's good that people know the 'cons', nothing against that - in fact, I continued the conversation with cAPSLOCK about his node restoring troubles for a whole page or more; giving this issue visibility. Just stick to the facts and don't overblow the 'downsides' on Lightning while ignoring the same 'downsides' (e.g. needing a backup) in Bitcoin Core.
also scaling bitcoin is not just about "bigger blocks" thats the silly propaganda story you fangirls like to push as bitcoins only solution to more usability on bitcoin network. there are many ways to increase bitcoin usability on the bitcoin network and reduce the transaction fee and also scale bitcoin..
but hey.. seems you are just going to be another fangirl that just follows the same scripts of other fan girls.. without thinking for yourself and having a response thats not a script i have heard before word for word..
I never propagated that; it's just what I heard you say in the past (that blocks should be larger). What else do you propose? You just vaguely mention 'many ways', but don't say which ones they are. If they exist and are viable, why don't you write a thread about all of these great ways, with their upsides and downsides where we can discuss them and maybe write a PoC for Bitcoin Core or whatever other software? Just saying 'they exist' doesn't help anyone because these ideas won't come to fruition if you don't elaborate on them.
and yes i say fan girls because the stereotype fits.
girls are more stereotypical followers of influencers. much more then women, men or boys.
(fangirls are even more 'influencer<->drone' follower stereotypical than a herd of cows)
Oh that sounds very misogynous. Maybe you haven't, but I've known a lot of great women; older and younger ones, great minds, no 'drone followers' at all. I've definitely known tons of men being like that, though. Just type in 'Elon Musk' on Twitter search and look at thousands if not millions of middle-aged men following that guy like a god, eating up every word he says as if it's absolute truth. If that's not a drone-follower, I don't know what is.
Now... On to my topic of node recovery, which I appreciate you all listening to, and honestly I hope that MAYBE it would be useful to someone else. I CERTAINLY would be a decent resource at this point for helping someone go through this ordeal with either LND or CL! If someone is reading this and needs help, ping me.
I'll definitely refer people to you if they have such issues in the future..
CL node:
The CL node is back up, and running. As if nothing happend, I think. It is only missing 3 channels . Well two really since the third is my LND node. Lol. That channel will not be coming back up. The other two are "benthecarman" and "Rath [keysend]". The latter is a forum member and posts in this thread. Is your node just down? The first one? I dunno. Anyone else have an active channel with him?
This sounds awesome! I do have a node with @Rath (
@'ing him apparently notifies him, as his profile states), and it regularly goes offline for a bit; I guess his internet connection isn't great. I just checked and right now it's actually online.
OK here is the freaky part of the whole thing. I ran through all the restoration process, including decrypting/restoring the backup database. When the node came back up about half the channels were connecting, but the other half were not. Something seemed wrong. When I went to look at the info for the node IT HAD THE WRONG PUBKEY! Umm... huh? so I recreated the hsm_secret from the seed words (I had used one in a "rescue backup" originally). After bouncing lightningd not only did I have the RIGHT pubkey, but most of the other channels connected right away.
Interesting; so using the
hsm_secret file gave a wrong pubkey, but using the seed words resulted in the right one? Difference in amount of channels connecting or not connecting after pubkey change might be implementation-specific (either some running outdated versions or running LND vs CLN).
But how did the channel backup get restored? I guess that the assumption that the hsm_secret has something to do with decrypting that is not the case?
I've never heard of hsm_secret encrypting the channel backups; in my memory it's just the secret / entropy (basically for anything on-chain).
And HOW ON EARTH did some of my channels come back up?!??!? That part seems crazy. And I feel lucky not to have set off alarms on my channel partners node. The whole investigation was prompted by the fact that half my partner nodes were REFUSING connection.
My bet would be on outdated nodes and / or LND vs CLN difference. But yes, it should probably set off red lights if someone switches their public key, I guess..
There are two things at fault here. A shitty SDD failure, and my lack of good preparation.
Did the SSD spontaneously die? Usually I'd advise for whole system / drive backups, but in case of Lightning, using the backup plugin (or what's now built-in) makes more sense, since it initiates a backup every time there's a channel-state update, which is what matters most. If your latest backup doesn't include one channel's latest update, you can get into trouble.
Anyway, thanks, all for the audience. I will quiet down about this now.
Thanks for all the updates! Gave great insights; I only had such issues and failures / no backup, etc. in Lightning's 'reckless' phase and on Testnet which is multiple years back now, so memory gets a bit blurry. It's refreshing to see how the current state of Lightning is when it comes to failures and backup restore process.
