Author

Topic: Lightning node vs. hub vs. wallet & key handling. (Read 101 times)

legendary
Activity: 1876
Merit: 3132
December 24, 2021, 06:58:15 PM
#4
Any channel update that maintain or increase the overall balances would always be allowed, but decreasing that balance would not be allowed unless (3) explicitly "gives permission" to do so with a signature.

Keep in mind that if you are the channel founder, you always pay the closing fees. Commitment transactions are periodically updated so that they could be confirmed within reasonable time frame. If the mempool gets full, your balance will shrink to compensate for the higher fee. This approach will also make your node incapable of payment routing.

What does Electrum connects to for lightning?  I searched, watch some videos, and failed to grasp some necessary detail.

By default, Electrum uses trampoline routing which means that it delegates payment route calculation to the node which is the first hop. In this mode, Electrum connects only to some Electrum server just like it would normally. You can open a channel to a limited number of nodes because hardly any of them support trampoline routing.

If you turn off trampoline routing, you can open a channel to any Lightning node, but you will have to wait for your client to sync the network graph, which is used to calculate payment routes, from some random Lightning Network nodes. In this mode, Electurm also connects to a few Lightning nodes.

Does any wallet do "proper remote instant backups" already?  That is, full backups, that are updated such that a node failure at the worst time doesn't mess up channel state or require to force close any channel.

LND does not have any native backup functionality (there might be some decent third-party tools). C-lightning documentation covers various backup strategies. I personally use a backup plugin which replicates the channel database to a remote directory whenever it's updated. I successfully restored such backup when I was moving my node between different machines. I didn't have to close my channels in the process.
newbie
Activity: 22
Merit: 67
Thanks a lot.  A few keywords go a long way.

I had not stumbled across remote signing, and I had not seen that flavor of the term watch-only before, that is helpful. I wouldn't have know to search for those.


The first I had read, the second.... I had scanned a couple of the 61 pages.  It seemed either outside what I was looking for, or missing the context which was what I was looking for.  I will look again.

Little useless daily rant:
For precision, my concern about fGAFAM isn't as much "stealing the funds", which I must admit is what the keys analogy seemed to suggest.  It is much more about privacy and ownership.  They sure love meta-data and I don't trust that they will give me access to my data whenever I want or need it.  If big tech did ban a certain president across multiple supposedly unrelated "services," it is certainly willing to lock me out of any account, and I would not even expect them to provide any clear reason as to why even the pope asked a hundred times.  End of rant.

End goal:
My end goal is a setup that I trust, as defined by myself.  That would be two signature (on separate hardware) required for anything that isn't a payment, and a third signature to actually make payments.  e.g. (1) a lightning node, (2) a wallet, and (3) a payment-permission-giver.  I think of a hardware-wallet for the third, but it really doesn't have to be and using that term would too easily lead to confusion.

Both (1) and (2) would be required for anything to happen at all.  Any channel update that maintain or increase the overall balances would always be allowed, but decreasing that balance would not be allowed unless (3) explicitly "gives permission" to do so with a signature.

The idea is that even if either one of the two hot wallet is fully compromised, the funds remain completely safe because the non-compromised node would prevent any rules from being broken.

If both (1) and (2) are compromised, then... boom! in the unfortunate sense.

Meanwhile:
Is there a hybrid or multi-sig mode where both the wallet and the lightning node must sign?

And a question I forgot in my original post:  What does Electrum connects to for lightning?  I searched, watch some videos, and failed to grasp some necessary detail.

Does any wallet do "proper remote instant backups" already?  That is, full backups, that are updated such that a node failure at the worst time doesn't mess up channel state or require to force close any channel.

Zap wallet seems to allow making backup on the local drive, Google Drive or Dropbox.  What does it save exactly, and when?  What is it good for, and what is it NOT good for?


Installing LND as a "remote-signer" feels overkill, but I lack the knowledge and experience to if that is the case.

I will now be looking for some light-weight open-source Linux desktop remote-signer, and then I have some work to do to put things together.

I tried two lighting wallets a while ago, and I had a different not-so-smooth with each, Zap-Wallet was one of them.  I only consider Linux desktop software, for now at least.

As for the End Goal above, it seems to me that the most plausible path is to be patching a remote signer-such that two instances of it work together to act as a single remote signer that connects to a watch-only node.  I may hire some developer who knows better than I to help with that, but I still have some figuring out to do before that.

If anyone has any suggestion or pointers that can be useful, or if you know your stuff enough and are willing to work on something like that for some sats, let me know, that would be greatly appreciated.

legendary
Activity: 1876
Merit: 3132
TL;DR  Can I have a lighting node that does not hold my keys, and have a lighter weight wallet that does the signing required?

Yes, it is possible. LND can run in watch-only and singing-only modes. Here you can find a detailed documentation about it. At the moment, both modes require to be connected to a full Bitcoin node, but there is a pull request which will address that problem.

While I have some fair understanding of how channels work and how lightning network is supposed to work, but I am completely lost (maybe not, but close enough) regarding what the actual implementations are doing or not doing.

Make sure to visit The Lightning Network node experience and The Lightning Network FAQ threads.

I heard that some mobile app connect to non-custodial servers that do the routing for the client.  I also came across a feature consisting of uploading an encrypted backup of im-not-so-sure-what-exactly.

For example, BlueWallet is a custodial Lightning wallet which accepts on-chain deposits from users and credit them balance on the Lightning Network. All payments are sent from/received to BlueWallet's node which manages the channels for the users so that they don't have to worry about inbound/outbound liquidity.

Eclair Mobile, which is a non-custodial wallet, allows users to make and upload an encrypted backup of their channel database, which consists of data needed not only to reestablish channels with peers but also to construct penalty transactions if the other party ever attempts to cheat. The (unencrypted) backup itself should be useless to a third-party as it shouldn't contain any signed transactions that could result in a fraudulent force-close.

And I want a separate (desktop) wallet that will do the signing, as well as whatever else it needs to do, ideally not much more.

You should be able to connect to your LND node using Zap Wallet.
newbie
Activity: 22
Merit: 67
TL;DR  Can I have a lighting node that does not hold my keys, and have a lighter weight wallet that does the signing required?  Or, a setup that requires two signatures, either from two separate nodes or a node (or hub?) and a wallet?


While I have some fair understanding of how channels work and how lightning network is supposed to work, but I am completely lost (maybe not, but close enough) regarding what the actual implementations are doing or not doing.

I tried to install lnd, and c-lightning with various degree of success.  I've been asked to write down a seed it generated.  While it does make some sort of sense [for it to hold funds] and I expect a how wallet to be involved in the process, I don't dare put funds in there as I feel too clueless about what this beast is capable (or incapable) of, even though I am totally fine using Electrum, Wasabi, etc, with (cold) and without (hot) hardware wallets. Those weren't clean and swift "apt install" or "yum install" setups. And I am mostly scare about backups here to be honest.

I have Bitcoin nodes to handle and verify the chain, separate software to manage my wallets and, unless a hot wallet is required, a separate hardware device to sign onto my transactions for security.  I am not so keen to the idea of putting my (a) seed into the lnd node, even though I expect a hot wallet to be involved.

I heard that some mobile app connect to non-custodial servers that do the routing for the client.  I also came across a feature consisting of uploading an encrypted backup of im-not-so-sure-what-exactly.  But, sorry, sorry, sorry..  I respect but don't necessarily hold the opinion that Foogle Drive or fiCloud are better than nothing.  For gaslighting sake: is giving a thief a copy on my house and car keys make me safer in the event I lose my keys?  (Don't respond to that, PLEASE!)

Anyway, I am looking for a self-hosted "node?" that handles all the communication, routing, verification, backups and stuff, BUT doesn't [have to] hold the keys.  And I want a separate (desktop) wallet that will do the signing, as well as whatever else it needs to do, ideally not much more. Indeed, without the wallet connected, the channels would be unusable, and the node would be at most a sort of watchtower and an online backup, but the point is to keep the workhorse as separate from the keys as possible.

Defining some terms may be helpful. Hopefully, not too many words have multiple and interchangeable meanings.  I should be able to word my questions better, or ask better questions, as I get less confused about what is out there and which software does what.
Jump to: