A shachain is a compact scheme, designed by Rusty Russell, for storing all of the per-commitment revocation secrets of a Lightning channel without the storage growing with the number of channel updates.

Every time a channel’s state advances, the previous state must be revocable: the peer hands over a secret that would let the counterparty punish them if they ever broadcast that old state. Naively, each secret is 32 bytes and you would have to keep every one — storage that grows linearly with the number of updates. Each payment, whether successful or not, requires 2 additional revocation keys to be stored (one for the state update that adds the HTLC, one for the update that removes it).

The shachain instead derives all secrets from a single seed arranged as a tree of hashes. Because a parent in the tree can regenerate all of its descendants, a node only ever needs to keep a handful of secrets to reconstruct every revocation key produced so far. This lets a channel handle up to 2^48 revocations at a fixed storage cost, rather than one stored key per state.

The tree above is a 3-bit toy — 8 secrets instead of 2^48. It reads from the top (the seed) down to the leaves. Following an edge down: if that level’s bit is unset (0) the secret passes straight down unchanged; if it is set (1) you flip that bit of the secret and then hash it with SHA256. Because we hash while going down the tree, holding any node lets you regenerate the whole cone of secrets below it but never anything above or beside it.

Let’s consider a channel between Alice and Bob, from the perspective of Alice sending her revocation secrets to Bob after each state update (the symmetric case is analogous). Alice needs to be able to very quickly derive each new secret from the seed; and Bob needs to be able to reconstruct any revocation secret sent by Alice, without knowledge of the seed. In our 3 bits example, Alice will at most need to compute 3 hashes in order to derive any revocation secret. For a real Lightning channel, at most 48 hashes are required to derive a revocation secret from the seed. Alice starts by computing 111 (3 hashes from the seed) and sends it to Bob, who stores it. Then, on the next update, Alice computes 110 and sends it to Bob. Since 111 can be obtained by hashing 110 (and also flipping a bit), Bob can discard 111 and keep only 110. More generally, any time Alice sends a revocation secret that is a “parent node” in the tree, Bob can safely discard all the secrets below it. The same logic applied to a 48 levels deep tree allows the receiving node (here Bob) to reconstruct any revocation secret sent by Alice by storing at most 49 secrets at any point in time. 2^48 potential secrets, condensed in a 49 items long array!