<p>Unless bob uses a watchtower service where he outsources the storage of data Bob needs to know all previous revocation secrets. However he does not need to store and save all of them as the revocation secretes are derived in a deterministic way. This means whenever I know a revocation secret of a current state I will be able to derive all previous revocation secrets from it.</p>
<p>You can <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#keys" rel="nofollow noreferrer">find the details of the key derivation in the key's section of BOLT 03</a></p>
<p>That being said revocation secrets are not the same as preimages of HTLCs (which I believe your question implies / confuses) The old preimages of settled HTLCs do never need to be stored or need to be reproduced. This is because in the penality transaction case from the second stage HTLCs the revocation secret is sufficient to access the funds before the timelock.</p>

CC BY-SA 4.0
2020-07-18T07:53:54.623Z
Thanks! But if revocation secrets aren't verified like a HTLC preimage - how are they verified? Are the transactions publish the public key and when the secret is published it is checked as the corresponding private key? Which Bitcoin opcode supports this kind of verfication?
user107511
CC BY-SA 4.0
2020-07-18T09:44:54.930Z
When a new commitment tx is negotiated and the old revocation secret is revealed one can check if it can be used to produce a valid signature. Nodes must do this before sending a new commitment signed message
Rene Pickhardt
CC BY-SA 4.0
2020-07-15T14:21:06.597Z
2020-07-15T20:12:23.147Z
2020-07-15T20:12:23.147Z
Rene Pickhardt
<p>When using a lightning channel, two sides are sending transactions representing the current state (or balance) between them, and for each state sent, they invalidate the previous state by sending a secret for a hash puzzle in a HTLC transaction.</p>
<p>For example, when Alice sends Bob the new state between them, it also sends a secret for the puzzle in the previous state. Bob can use it to redeem Bitcoin if Alice publishes the previous state transaction on the blockchain.</p>
<p>My question is - does Bob need to save all the secrets of all the previous states until the channel is settled and closed? Sounds like Bob might need to save a lot of data when having many channels.</p>

<lightning-network><hash-time-locked-contract>
Lightning Network state deprecation secret keeping
user107511
# Lightning Network state deprecation secret keeping

(Asked by: username_0 on 2020-07-15)

When using a lightning channel, two sides are sending transactions representing the current state (or balance) between them, and for each state sent, they invalidate the previous state by sending a secret for a hash puzzle in a HTLC transaction.

For example, when Alice sends Bob the new state between them, it also sends a secret for the puzzle in the previous state. Bob can use it to redeem Bitcoin if Alice publishes the previous state transaction on the blockchain.

My question is - does Bob need to save all the secrets of all the previous states until the channel is settled and closed? Sounds like Bob might need to save a lot of data when having many channels.

**Tags:** lightning-network, hash-time-locked-contract


---

## 1 answers

### Answer by username_1 on 2020-07-15. Score: 1

Unless bob uses a watchtower service where he outsources the storage of data Bob needs to know all previous revocation secrets. However he does not need to store and save all of them as the revocation secretes are derived in a deterministic way. This means whenever I know a revocation secret of a current state I will be able to derive all previous revocation secrets from it.

You can [find the details of the key derivation in the key's section of BOLT 03](https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#keys)

That being said revocation secrets are not the same as preimages of HTLCs (which I believe your question implies / confuses) The old preimages of settled HTLCs do never need to be stored or need to be reproduced. This is because in the penality transaction case from the second stage HTLCs the revocation secret is sufficient to access the funds before the timelock.

> **Comments:**
> **username_0**: Thanks! But if revocation secrets aren't verified like a HTLC preimage - how are they verified? Are the transactions publish the public key and when the secret is published it is checked as the corresponding private key? Which Bitcoin opcode supports this kind of verfication?  
> **username_1**: When a new commitment tx is negotiated and the old revocation secret is revealed one can check if it can be used to produce a valid signature. Nodes must do this before sending a new commitment signed message  

---

