<p>Not sure if I get exactly what you are asking for. But some general remarks and thoughts should hopefully give you all the information you need to answer your question.</p>

<p>A watchtower basically needs  a copy of your channels state history. (a subset of the data will be sufficient but let's assume for simplicity that the watchtower needs an exact copy of the history of channel states) </p>

<p>Now the answer to your question depends.</p>

<p>If every watchtower is supposed to have the full history of every state channel on the network we would have a total storage requirement of <code>O(V*E)</code> with <code>V</code> being the number of nodes on the network and <code>E</code> the number of channels. And a single storage requirement of <code>O(E)</code>. Unless the person is a supporter of some Bitcoin forks like bcash, one can easily see that this would never scale as the number grows linear with the amount of payments taking place in the lightning network. This it has a storage requirement in the same order of magnitude as storing all transactions in one public blockchain with really large blocks.</p>

<p>However we could say that it is sufficient for every node to be a watchtower of <code>x</code> other nodes. In this way on average (amortized) every lightning node should have a storage overhead of a factor <code>x</code> with comparison to the storage requirements for their own state channels.</p>

CC BY-SA 4.0
2019-05-01T17:35:29.287Z
Hey, thanks Rene! Still confused: why for simplicity start with the assumption that the watchtower tower has a history of a channels state history? Why not the assumption that they only require the last update/change to the channel? I understand that it puts a heavier burden on a watchtower to maintain an entire history, so why not simplify to ‘I watchtower hold the most recent state of said channel and here it is! I’ve done my job! And saved you from conspiracy...’ or smth like that :/
Auriol
CC BY-SA 4.0
2019-05-01T17:38:33.620Z
Sorry, I guess I don’t know exactly how watchtowers must function to guarantee security, privacy, and trustlessness, but as I’m assuming nodes take the burden to become watchtowers by default, I don’t think starting with the most data heavy suggestion/implementation makes the scenario simpler, feasible, or practical
Auriol
CC BY-SA 4.0
2019-05-01T17:44:13.187Z
Would say that ‘However we could say...’, that later bit does touch on the idea of nodes in the network sharing responsibility by default, but not in maintaining a copy of the entire history :)
Auriol
CC BY-SA 4.0
2019-05-01T18:01:29.393Z
So, essentially the shared responsibility is to keep records of the most recent update to a state channel or several state channels depending on capacity, and provide evidence on layer one that there is a more recent state than of one who is trying to cheat. Does each watchtower (in current proposals) have to keep the entire record so as to match/catch older states being published to layer one? If so, could there be a way to identify state changes that correlate (come from the same channel interactions) without knowledge of every single state in a channel’s history?
Auriol
CC BY-SA 4.0
2019-05-01T18:05:21.087Z
AFAIK, Rene is right that ATM watchtowers would need to store an amount of data that is linear in the history of channel states if they are to be as private as we want them to be. Eltoo would change that to basically just saving the latest state. IMHO that is one reason why we're not seeing watchtowers in action: everybody is waiting for eltoo, which would make an idea like yours practical. The other is that right now (without eltoo), watchtowers seem practically unnecessary because the attack they are supposed to prevent is just too risky.
stefanwouldgo
CC BY-SA 4.0
2019-05-01T18:08:37.223Z
Ok, gotcha—need to do research^^; Thank you both!!
Auriol
CC BY-SA 4.0
2019-05-01T17:11:50.973Z
2019-05-01T17:11:50.973Z
Rene Pickhardt
<p>What would be the costs for forcing every node on the lightning network to provide watchtower services by default so that the burden is shared by other users maintaining the default and with consideration for relative value across the second-layer and for the rate at which users go offline? Could this work for lightning or other state channel networks? Why, or why not? ‬</p>

<p>So, what if all nodes in state channels are arbiters/watchtowers by default, but the cost of computation to support watchtower service on the network for a node (or node pair/channels) depends on the cost of ‘need’ of that node to have state/in channel transactions backed up, which is relative in value to other nodes in the network and to the rate at which nodes fail in the network. State channel users may choose to not use watchtower services at all, use watch tower services but not support it for others in the network, in which case they pay watchtowers at a premium, or to both support ‘watching’ and establish state channels. Also, if the responsibility of ‘watching’ should have a reasonable level of redundancy over periods of time so as to relieve the burden of computation costs of all watchers... sorry</p>

<p>tl;dr - the first part up to ‘why or why not’^^;</p>

<lightning-network><lightning-network-daemon><watchtower>
What if all nodes on the lightning network were watchtowers by default?
Auriol
# What if all nodes on the lightning network were watchtowers by default?

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

What would be the costs for forcing every node on the lightning network to provide watchtower services by default so that the burden is shared by other users maintaining the default and with consideration for relative value across the second-layer and for the rate at which users go offline? Could this work for lightning or other state channel networks? Why, or why not? ‬

So, what if all nodes in state channels are arbiters/watchtowers by default, but the cost of computation to support watchtower service on the network for a node (or node pair/channels) depends on the cost of ‘need’ of that node to have state/in channel transactions backed up, which is relative in value to other nodes in the network and to the rate at which nodes fail in the network. State channel users may choose to not use watchtower services at all, use watch tower services but not support it for others in the network, in which case they pay watchtowers at a premium, or to both support ‘watching’ and establish state channels. Also, if the responsibility of ‘watching’ should have a reasonable level of redundancy over periods of time so as to relieve the burden of computation costs of all watchers... sorry

tl;dr - the first part up to ‘why or why not’^^;

**Tags:** lightning-network, lightning-network-daemon, watchtower


---

## 1 answers

### Answer by username_1 on 2019-05-01. Score: 2 | Accepted answer

Not sure if I get exactly what you are asking for. But some general remarks and thoughts should hopefully give you all the information you need to answer your question.

A watchtower basically needs a copy of your channels state history. (a subset of the data will be sufficient but let's assume for simplicity that the watchtower needs an exact copy of the history of channel states)

Now the answer to your question depends.

If every watchtower is supposed to have the full history of every state channel on the network we would have a total storage requirement of `O(V*E)` with `V` being the number of nodes on the network and `E` the number of channels. And a single storage requirement of `O(E)`. Unless the person is a supporter of some Bitcoin forks like bcash, one can easily see that this would never scale as the number grows linear with the amount of payments taking place in the lightning network. This it has a storage requirement in the same order of magnitude as storing all transactions in one public blockchain with really large blocks.

However we could say that it is sufficient for every node to be a watchtower of `x` other nodes. In this way on average (amortized) every lightning node should have a storage overhead of a factor `x` with comparison to the storage requirements for their own state channels.

> **Comments:**
> **username_0**: Hey, thanks username_1! Still confused: why for simplicity start with the assumption that the watchtower tower has a history of a channels state history? Why not the assumption that they only require the last update/change to the channel? I understand that it puts a heavier burden on a watchtower to maintain an entire history, so why not simplify to ‘I watchtower hold the most recent state of said channel and here it is! I’ve done my job! And saved you from conspiracy...’ or smth like that :/  
> **username_0**: Sorry, I guess I don’t know exactly how watchtowers must function to guarantee security, privacy, and trustlessness, but as I’m assuming nodes take the burden to become watchtowers by default, I don’t think starting with the most data heavy suggestion/implementation makes the scenario simpler, feasible, or practical  
> **username_0**: Would say that ‘However we could say...’, that later bit does touch on the idea of nodes in the network sharing responsibility by default, but not in maintaining a copy of the entire history :)  
> **username_0**: So, essentially the shared responsibility is to keep records of the most recent update to a state channel or several state channels depending on capacity, and provide evidence on layer one that there is a more recent state than of one who is trying to cheat. Does each watchtower (in current proposals) have to keep the entire record so as to match/catch older states being published to layer one? If so, could there be a way to identify state changes that correlate (come from the same channel interactions) without knowledge of every single state in a channel’s history?  
> **username_2**: AFAIK, username_1 is right that ATM watchtowers would need to store an amount of data that is linear in the history of channel states if they are to be as private as we want them to be. Eltoo would change that to basically just saving the latest state. IMHO that is one reason why we're not seeing watchtowers in action: everybody is waiting for eltoo, which would make an idea like yours practical. The other is that right now (without eltoo), watchtowers seem practically unnecessary because the attack they are supposed to prevent is just too risky.  
> **username_0**: Ok, gotcha—need to do research^^; Thank you both!!  

---

