<p>This question was answered by Christian Decker on IRC.</p>
<blockquote>
<p>Yes, it's a bit tricky, because you never want to start the old copy
once you started the new one, but absolutely doable. 1) stop the old
node, 2) rename the <code>.lightning</code> directory so you can't accidentally
restart the old node (maybe verify that starting will create a new
node), 3) copy the renamed <code>.lightning</code> to new host in the place where
you'll be running from, and 4) point lightningd to the copied
directory and start it.</p>
<p>I'd also delete any copy remaining on the old host for safety
(starting that one may lead to loss of funds). While you're at it,
make a backup of <code>hsm_secret</code> files in the directory (those are static
and safe to copy)</p>
</blockquote>

CC BY-SA 4.0
2021-12-13T16:21:09.957Z
No, more a footgun than a bug. Like accidentally broadcasting a revoked state could lead to you being punished and losing all your funds in the channel. Of course in an ideal world these footguns wouldn't exist but we don't know how to magic them away in the Lightning protocol (and it may well be impossible without designing a completely different protocol).
Michael Folkson
CC BY-SA 4.0
2021-12-13T16:28:46.053Z
I guess we are talking definitions/semantics. I would describe a footgun as something that is addressed with user guidance, user docs etc but it is well known and understood in the protocol. I would describe a bug as something that is discovered out of the blue and needs squashing asap (ie there is no reason for it to exist). Of course in consensus systems some bugs (like the CHECKMULTISIG OP_0 bug) can't be squashed without a hard fork so the definitions do get confusing and create grey areas.
Michael Folkson
CC BY-SA 4.0
2021-12-13T16:29:22.067Z
Correct, losing any state transition is deadly in the LN protocol, which is why we came up with a more forgiving protocol with eltoo. The protocol itself makes backups and restores pretty dangerous (and this migration is pretty much just a backup + restore), because even missing a single update may lead to loss of funds (and that's true for all implementations).
cdecker
CC BY-SA 4.0
2021-12-13T16:45:58.707Z
@Prayank: With onchain funds you can't lose your private key and you can't leak your private key to an attacker. Is that a bug? No it is a well understood footgun and limitation of cryptographic protocols. SImilarly Lightning requires you to monitor the chain (stay online) and not to accidentally broadcast a revoked state. Another well understood footgun and limitation of Lightning. Pre-eltoo if a malicious channel counterparty can trick you into broadcasting a revoked state you can lose your funds in the channel. No experimentation needed, it is a known footgun.
Michael Folkson
CC BY-SA 4.0
2021-12-13T14:56:26.110Z
2021-12-13T14:56:26.110Z
Michael Folkson
<p>If I wanted to move my c-lightning node to an other machine, is there a way to do that (and how)? Specifically, without changing my node key or closing my channels?</p>
<p>This question was asked by plant-boy on IRC.</p>

<core-lightning><server>
How do I move my c-lightning node to a different machine without closing my channels?
Michael Folkson
# How do I move my c-lightning node to a different machine without closing my channels?

(Asked by: username_0 on 2021-12-13)

If I wanted to move my c-lightning node to an other machine, is there a way to do that (and how)? Specifically, without changing my node key or closing my channels?

This question was asked by plant-boy on IRC.

**Tags:** core-lightning, server


---

## 1 answers

### Answer by username_0 on 2021-12-13. Score: 4

This question was answered by Christian Decker on IRC.

> Yes, it's a bit tricky, because you never want to start the old copy
> once you started the new one, but absolutely doable. 1) stop the old
> node, 2) rename the `.lightning` directory so you can't accidentally
> restart the old node (maybe verify that starting will create a new
> node), 3) copy the renamed `.lightning` to new host in the place where
> you'll be running from, and 4) point lightningd to the copied
> directory and start it.
>
> I'd also delete any copy remaining on the old host for safety
> (starting that one may lead to loss of funds). While you're at it,
> make a backup of `hsm_secret` files in the directory (those are static
> and safe to copy)

> **Comments:**
> **username_0**: No, more a footgun than a bug. Like accidentally broadcasting a revoked state could lead to you being punished and losing all your funds in the channel. Of course in an ideal world these footguns wouldn't exist but we don't know how to magic them away in the Lightning protocol (and it may well be impossible without designing a completely different protocol).  
> **username_0**: I guess we are talking definitions/semantics. I would describe a footgun as something that is addressed with user guidance, user docs etc but it is well known and understood in the protocol. I would describe a bug as something that is discovered out of the blue and needs squashing asap (ie there is no reason for it to exist). Of course in consensus systems some bugs (like the CHECKMULTISIG OP_0 bug) can't be squashed without a hard fork so the definitions do get confusing and create grey areas.  
> **username_1**: Correct, losing any state transition is deadly in the LN protocol, which is why we came up with a more forgiving protocol with eltoo. The protocol itself makes backups and restores pretty dangerous (and this migration is pretty much just a backup + restore), because even missing a single update may lead to loss of funds (and that's true for all implementations).  
> **username_0**: @Prayank: With onchain funds you can't lose your private key and you can't leak your private key to an attacker. Is that a bug? No it is a well understood footgun and limitation of cryptographic protocols. SImilarly Lightning requires you to monitor the chain (stay online) and not to accidentally broadcast a revoked state. Another well understood footgun and limitation of Lightning. Pre-eltoo if a malicious channel counterparty can trick you into broadcasting a revoked state you can lose your funds in the channel. No experimentation needed, it is a known footgun.  

---

