Watchtower

A watchtower is a service that monitors the Bitcoin blockchain on a Lightning node's behalf, ready to punish channel breaches even while the node itself is offline. Lightning's security model assumes participants watch the chain to catch cheating, but real-world nodes reboot, lose power, and go dark — a laptop node might be closed more often than open. Watchtowers close that gap by outsourcing the watching without outsourcing the funds.

The breach problem

Every payment channel update creates a new commitment transaction and revokes the previous one — but revoked states remain technically valid Bitcoin transactions. A dishonest peer could broadcast an old commitment in which their balance was higher, hoping you are not watching. The protocol's built-in deterrent is the penalty (or justice) transaction: because the cheater handed over a revocation secret when the state was superseded, the wronged party can sweep the entire channel balance, turning attempted theft into total loss for the attacker. But that deterrent only functions if someone spots the revoked commitment during the dispute window and responds in time. Offline means defenseless — unless a watchtower is standing in.

How a watchtower defends you without learning your business

The elegant part is what the watchtower does not know. For each channel update, your node sends the tower a hint keyed to a truncated identifier of the revoked commitment transaction, paired with an encrypted blob containing what is needed to construct the penalty transaction — encrypted with the full transaction ID as the key. The tower stores these blindly: it cannot decrypt anything in advance, and it learns nothing about your balances or payment activity. Only if a revoked commitment actually confirms on-chain does the tower see the matching transaction ID, decrypt the corresponding blob, and broadcast the pre-signed penalty transaction — sweeping funds to an address you control. A tower that never catches a breach never learns anything at all. Implementations vary in economics: altruistic towers respond for free (the model shipped in common node software), while reward-based designs let the tower claim a cut of swept funds as a bounty.

Running and choosing towers

For a sovereign operator the questions are practical. Who runs your tower? The best answer is you — a second node at a different location, on separate power and network, watching your primary's channels. Failing that, several independent towers run by parties unlikely to collude: nothing prevents registering with more than one, and redundancy is cheap since the tower holds only encrypted blobs. Watchtowers matter most where the stakes and downtime risk are highest — an always-on routing node with large channels should assume it is a target, and a mobile or intermittently-online node should assume its peers notice its schedule. Watchtowers reinforce the revocation guarantees at the heart of the Lightning Network; they are how "don't trust your counterparty" survives contact with the reality that no machine stays online forever.

What a watchtower cannot do

Clarity about scope prevents false comfort. A watchtower defends against exactly one thing: a counterparty broadcasting a revoked state. It is not a backup — if you lose your node's channel state and seed, no tower restores a satoshi. It does not keep your node online, route your payments, or manage fees on a force-close; those remain your problems. The tower itself must also be functioning at the moment of breach: a tower that is offline, out of disk, or discarded your session data is a silent failure you may never detect until it mattered, which argues for redundancy and the occasional health check. And the deterrent depends on the dispute window — channels configured with very short timelock deltas shrink the interval in which anyone can react. Treat towers as one layer in a defense stack: reliable power and networking first, sane channel parameters second, watchtowers as the failsafe behind both.