<p>While I agree with you in that this is an issue, it is in no way different from current systems. In current systems, stealing credentials of a bank give you pretty much enough power to move the money around. In the case of the LN, stealing credentials of a payment channel/tx gives you the possibility of compromising that payment channel, or to publish that tx.</p>

<p>However, the damage is not that bad if only <em>one</em> of the two participants is compromised:</p>

<ul>
<li><p>In the event of <em>key theft</em>, the thief can simply try to cooperate with the counterparty in creating a new state that benefits the counterparty, creating some kind of LN-like protocol to ensure a part of the funds go to the thief.  The thief must however do this for each of the channels and counterparties, while in the meantime the hub can update the state and invalidate the stolen keys.</p></li>
<li><p>In the event of <em>tx theft</em>, the thief can simply either publish a previous state (which the hub should have deleted completely anyway when updating), by which the hub loses all funds after counterparty proves fraud. Or instead, the thief can only publish the current state, in which nothing changes.</p></li>
</ul>

<p>I do not really think this is much of a problem, but perhaps I am missing some case scenario here. Please complete my answer if that's the case.</p>

CC BY-SA 4.0
2019-12-26T09:24:36.183Z
If the thief has inbound liquidity, he can simply create a invoice to receive the stolen fund.
Chris Chen
CC BY-SA 3.0
2018-03-21T11:58:41.063Z
2018-03-21T11:58:41.063Z
ranchalp
<p>Reading the whitepaper, I came across a point: nodes wishing to act as effective intermediaries, 'hubs' or not, need high availability and need to operate autonomously. </p>

<p>This means they must have access to the private keys of their payment channels in order to rebalance in support of transactions!! Vulnerabilities in the Lightning Network service - or other services on the same system or adjacent network - will end up exposing those keys to risk of theft.</p>

<p>Are there any solutions to this?</p>

CC BY-SA 3.0
2018-03-21T09:29:18.520Z
Can you explain a bit more, which private key you mean? It has nothing to do with the bitcoin wallet privkey. Are you referencing the random secret, that changes after every lightning tx?
pebwindkraft
<security><lightning-network>
Lightning network hub security?
jamarcus_13
# Lightning network hub security?

(Asked by: username_0 on 2018-03-20)

Reading the whitepaper, I came across a point: nodes wishing to act as effective intermediaries, 'hubs' or not, need high availability and need to operate autonomously.

This means they must have access to the private keys of their payment channels in order to rebalance in support of transactions!! Vulnerabilities in the Lightning Network service - or other services on the same system or adjacent network - will end up exposing those keys to risk of theft.

Are there any solutions to this?

**Tags:** security, lightning-network

> **Comments:**
> **username_1**: Can you explain a bit more, which private key you mean? It has nothing to do with the bitcoin wallet privkey. Are you referencing the random secret, that changes after every lightning tx?  

---

## 1 answers

### Answer by username_2 on 2018-03-21. Score: 1

While I agree with you in that this is an issue, it is in no way different from current systems. In current systems, stealing credentials of a bank give you pretty much enough power to move the money around. In the case of the LN, stealing credentials of a payment channel/tx gives you the possibility of compromising that payment channel, or to publish that tx.

However, the damage is not that bad if only *one* of the two participants is compromised:

* In the event of *key theft*, the thief can simply try to cooperate with the counterparty in creating a new state that benefits the counterparty, creating some kind of LN-like protocol to ensure a part of the funds go to the thief. The thief must however do this for each of the channels and counterparties, while in the meantime the hub can update the state and invalidate the stolen keys.
* In the event of *tx theft*, the thief can simply either publish a previous state (which the hub should have deleted completely anyway when updating), by which the hub loses all funds after counterparty proves fraud. Or instead, the thief can only publish the current state, in which nothing changes.

I do not really think this is much of a problem, but perhaps I am missing some case scenario here. Please complete my answer if that's the case.

> **Comments:**
> **username_3**: If the thief has inbound liquidity, he can simply create a invoice to receive the stolen fund.  

---

