<p>Without eltoo (ie today) a watchtower needs to store a different justice transaction for every channel update in case the channel counterparty broadcasts (deliberately or accidentally) an expired channel state.</p>
<p>With eltoo (once/if we have SIGHASH_ANYPREVOUT enabled onchain) a watchtower will only need to store a single justice transaction in case the channel counterparty broadcasts an expired channel state. The watchtower can delete old justice transactions.</p>
<p>This <a href="https://diyhpl.us/wiki/transcripts/chaincode-labs/2019-09-18-christian-decker-eltoo/" rel="nofollow noreferrer">presentation</a> from Christian Decker at Chaincode Labs is a great resource on eltoo.</p>

CC BY-SA 4.0
2021-03-15T21:19:19.267Z
In fact, since the commitment transactions in eltoo are symmetric, it's even sufficient to store only a single state per channel, rather than per channel participant!
Murch
CC BY-SA 4.0
2021-03-16T10:10:54.237Z
Another trick that Richard Myers came up with is that you only need to store a commitment if you receive, since that's what you're interested in, so you can stay silent and just tell the watchtower whenever your balance increased, your peer is incentivized to do the same whenever their balance increases, further halving communication costs.
cdecker
CC BY-SA 4.0
2021-03-15T16:30:56.790Z
2021-03-15T18:09:06.033Z
2021-03-15T18:09:06.033Z
Michael Folkson
<p>I vaguely remember a paper which stated that in their current implementation, lightning watchtowers require a lot of memory because they need to store information about (a penalty TX for) every balance change that happens on a channel they watch. And that eltoo would be more memory-efficient because it only requires storing information pertaining to the latest respective state. However, when talking about this in a large group of bitcoiners, there was no consensus about this. Does anyone know whether this is actually the case? Does a watchtower really need to store info about every channel balance change?</p>

<lightning-network><ln-penalty-transaction><eltoo><watchtower>
Is eltoo more memory efficient for watchtowers?
Hare Brained Brian
# Is eltoo more memory efficient for watchtowers?

(Asked by: username_0 on 2021-03-15)

I vaguely remember a paper which stated that in their current implementation, lightning watchtowers require a lot of memory because they need to store information about (a penalty TX for) every balance change that happens on a channel they watch. And that eltoo would be more memory-efficient because it only requires storing information pertaining to the latest respective state. However, when talking about this in a large group of bitcoiners, there was no consensus about this. Does anyone know whether this is actually the case? Does a watchtower really need to store info about every channel balance change?

**Tags:** lightning-network, ln-penalty-transaction, eltoo, watchtower


---

## 1 answers

### Answer by username_1 on 2021-03-15. Score: 4

Without eltoo (ie today) a watchtower needs to store a different justice transaction for every channel update in case the channel counterparty broadcasts (deliberately or accidentally) an expired channel state.

With eltoo (once/if we have SIGHASH\_ANYPREVOUT enabled onchain) a watchtower will only need to store a single justice transaction in case the channel counterparty broadcasts an expired channel state. The watchtower can delete old justice transactions.

This [presentation](https://diyhpl.us/wiki/transcripts/chaincode-labs/2019-09-18-christian-decker-eltoo/) from Christian Decker at Chaincode Labs is a great resource on eltoo.

> **Comments:**
> **username_2**: In fact, since the commitment transactions in eltoo are symmetric, it's even sufficient to store only a single state per channel, rather than per channel participant!  
> **username_3**: Another trick that Richard Myers came up with is that you only need to store a commitment if you receive, since that's what you're interested in, so you can stay silent and just tell the watchtower whenever your balance increased, your peer is incentivized to do the same whenever their balance increases, further halving communication costs.  

---

