17 sats \ 5 replies \ @xz 13h \ parent \ on: lnd backups bitcoin
I think the explanation @justin_shocknet wrote has more detail generally and is important to note what he said about the way SCB backup works. It's not really a backup.
In answer to your question about trust.
I think it's not an issue with channel peers. The only issue is mempools. in that if for some reason your closures went through at a low fee (say 1~3 sats/vB) and then mempools spike, well there'd be costs that might make the small channels get much less funds back as a propotion of the channel size. Also, you might be waiting indefinetly. Usually force closures would estimate appropriately, and they will get mined, even in high fees, just could be unlucky if they spiked for a long duration just after force closing. But peers are not really an issue. Funds a re safe.
The scenario in that you might lose a seed phrase might be a problem only if you lost access to your node (corrupted db, SSD or whatever.) You could just have an external wallet in Bitcoin Core or whereever you like and close channels one by one (without force closing) and shift all of your funds to a new wallet by opening channels with a close address for your new wallet. But then again, maybe this is not going to work for force closing. So, bit difficult to say in each scenario.
  • I meant to say above, if you have the seed, and want to keep using the node, you can just close old channels one by one, and if you wanted to open any new channels, use an expernal wallet (lilke one that is cold storage, hww, or multi-sig) with:
lncli openchannel xxx --local_amt xxx --close_address bc1xxx --sat_per_vbyte x
or
bos open xxx --amount xxx --coop-close-address bc1xxx
not sure if there's much difference in those two commands.
write
preview
107 sats \ 3 replies \ @justin_shocknet 13h
It's kind of trusted unless you have recourse, since the SCB basically asks the peer to force close the channel as a signal that you don't have the latest state to do it gracefully yourself.
If they're willing to wager that you completely lost the state, as in don't have a watchtower somewhere, they could broadcast an old state and steal some funds that were sent to your side of the channel. The risk to them is that you might have set a trap, and the latest state in a watchtower somewhere ready to issue a justice tx should they attempt this.
If the peer is altogether unreachable, recovery gets more complicated and involves external chantools that Lightning Labs has available, this too would require the seed phrase.
reply
17 sats \ 0 replies \ @xz 13h
AH yes. I stand corrected. this is true. I forget about this because make a point of checking I have watchtowers.
reply
0 sats \ 1 reply \ @ChrisS OP 11h
Thanks for your help. I was able to test backup with the seed phrase and static channel backup and everything worked as expected. What would the next step be to back up the node in such a way as to not have to trust the peer to not try and steal your funds with an old state and to be able to recover funds if peer is offline? I understand there’s a lot of things that can go wrong if your backup is not completely up to date and your accidentally broadcast an old state. But there must be some way to safely do it.
reply
0 sats \ 0 replies \ @justin_shocknet 11h
A watchtower is basically a second node to deal with some of these issues
https://github.com/lightningnetwork/lnd/blob/master/docs%2Fwatchtower.md
Even if everything goes perfectly in a recovery scenario, closing channels and replacing them can get expensive, so it's best to make sure the node environment is a resilient one so it doesn't come up... I suggest an Nvme with a laptop battery at minimum
reply
0 sats \ 0 replies \ @xz 13h
*edit: I meant, If you want to keep using but DON'T have the seed.. but I guess it's obviously a much safer to have the seed!
reply