<p>With reliability, I assume you mean protecting channel balances against server failure (Not being able to close the channel correctly following an error).</p>

<p>You can reproduce the wallet in both nodes, but that doesn't contribute to securing a payment channel's balance in the case of a failure. It simply just means both node instances have identical wallet keys.</p>

<p>In other words, the two node instances may be signing with the same wallet keys, but they cannot be operating as a single peer for a given channel. </p>

<p>Since it is the individual payment channel balance (unbroadcasted, signed commitment transactions) which is at risk, it would be necessary to secure the commitment transaction data of a single node instance to protect your balance in case of a server failure.</p>

CC BY-SA 4.0
2019-01-09T17:30:53.507Z
2019-01-09T17:30:53.507Z
James C.
<p>No, because channels are very stateful, and each node MUST have the up-to-date state to be able to sign and revoke commitments. Any node which has out-of-date state will potentially cause loss of all funds in channels.</p>

<p>If you do need to migrate your node due to server downtime, you should ensure that you have replicated the most recent state onto your new server before attempting to reconnect to the network. Even if you have an automated replication strategy in place, if a server goes down, you can not be sure whether the most recent state was replicated to your new server until you can recover the state of the node which went down.</p>

<p>Clients will only keep a record of the most up-to-date gossip messages from a given node id, so broadcasting a new IP address will replace the old view of the IP address for other participants. Each client will probably use the node's public key as the primary key for indexing the node in its database.</p>

CC BY-SA 4.0
2019-01-09T17:28:11.717Z
2019-01-09T17:28:11.717Z
Mark H
<p>Is it possible to run two nodes with the same public key on the Lightning network? The reason is reliability -- two different servers run different instances of node software with the same setup (incl keys) -- if one fails -- the other one continue serving. Possible?</p>

<p>thank you.</p>

<lightning-network>
Is it possible to run two nodes with the same public key?
Stronzo
# Is it possible to run two nodes with the same public key?

(Asked by: username_0 on 2019-01-09)

Is it possible to run two nodes with the same public key on the Lightning network? The reason is reliability -- two different servers run different instances of node software with the same setup (incl keys) -- if one fails -- the other one continue serving. Possible?

thank you.

**Tags:** lightning-network


---

## 2 answers

### Answer by username_1 on 2019-01-09. Score: 1

With reliability, I assume you mean protecting channel balances against server failure (Not being able to close the channel correctly following an error).

You can reproduce the wallet in both nodes, but that doesn't contribute to securing a payment channel's balance in the case of a failure. It simply just means both node instances have identical wallet keys.

In other words, the two node instances may be signing with the same wallet keys, but they cannot be operating as a single peer for a given channel.

Since it is the individual payment channel balance (unbroadcasted, signed commitment transactions) which is at risk, it would be necessary to secure the commitment transaction data of a single node instance to protect your balance in case of a server failure.


---

### Answer by username_2 on 2019-01-09. Score: 0

No, because channels are very stateful, and each node MUST have the up-to-date state to be able to sign and revoke commitments. Any node which has out-of-date state will potentially cause loss of all funds in channels.

If you do need to migrate your node due to server downtime, you should ensure that you have replicated the most recent state onto your new server before attempting to reconnect to the network. Even if you have an automated replication strategy in place, if a server goes down, you can not be sure whether the most recent state was replicated to your new server until you can recover the state of the node which went down.

Clients will only keep a record of the most up-to-date gossip messages from a given node id, so broadcasting a new IP address will replace the old view of the IP address for other participants. Each client will probably use the node's public key as the primary key for indexing the node in its database.


---

