A Lightning watchtower addresses a specific risk: your channel partner publishes a revoked channel state while your node cannot respond. It watches for that breach and can submit a preauthorized on-chain remedy. Its value depends on what it received, what it covers and whether it can act in time. Those details matter more than a dashboard simply saying a tower is connected.
Why an old state still matters
Lightning participants exchange signed commitment transactions representing their channel balances. When they advance the channel, they also reveal information that revokes the previous state. “Revoked” does not mean an old transaction becomes invalid under Bitcoin's consensus rules. Instead, publishing it exposes the broadcaster to a penalty. The exchange of revocation secrets is defined in BOLT 2's channel-update protocol.
The protection comes from the transaction scripts. The broadcaster's main output has a relative timelock, measured in blocks. If that commitment was revoked, the other participant can use the revocation spending path without waiting for that delay. This creates an opportunity to claim the offending party's output before it becomes available through the ordinary delayed path. BOLT 3 describes these scripts.
This is why an offline node creates an operational concern: a valid remedy must still reach the chain. A watchtower helps cover that absence; it does not change the underlying deadline.
What the tower receives
LND's design sends the tower encrypted breach-remedy information, often called a justice transaction. The tower stores fixed-size encrypted blobs and can decrypt and publish the remedy when the corresponding revoked commitment appears. Its ordinary role does not require taking custody of the user's wallet. The LND watchtower guide also describes encrypted, authenticated client communications using temporary keypairs to reduce tracking through persistent identifiers.
The distinction is important: authorizing a particular breach response is different from authorizing an operator to make arbitrary payments. Encryption limits what the tower can learn from stored protection data, but that should not be stretched into a promise of anonymity across every network connection or service relationship.
Coverage needs equal attention. LND's published guide states that its tower protection covers the main commitment outputs, while HTLC-output protection is outside the scope described there. HTLCs are conditional payment outputs. Readers should verify the deployed release's coverage rather than translating “watchtower enabled” into “every possible channel loss is covered.”
Where protection stops
A normal unilateral close using an unrevoked state is a different event from a breach. A tower's penalty remedy does not make that close fraudulent or cancel its timelocks. Nor does it undo an authorized payment, provide missing receiving capacity or replace a recovery plan. These are different failure modes, not extra duties implied by the name.
The broader BOLT 5 on-chain requirements include resolving channel outputs and dealing with reorganizations. They also discuss circumstances in which transaction pinning can obstruct penalty transactions. The practical conclusion is limited but important: detecting a breach and securing a confirmed remedy are separate achievements. No tower can promise a miner will include a transaction immediately.
Availability is a design choice
Lightning Labs recommends placing a protective tower on a separate machine, network and location. Its configuration guide describes LND's integrated, explicitly enabled server and client functions and altruistic operation without compensation.
Consider a hypothetical home node and tower sharing one router and electrical circuit. Either process might survive the other's software crash, but both can disappear in the same outage. Moving the tower elsewhere reduces that shared exposure while adding another machine or operator to maintain. An unpaid service's existence alone tells you little about its retention policy, maintenance plans or response during an outage. Ask those questions before relying on it.
Fees introduce another tradeoff. LND's configuration reference describes a chosen fee rate for signing justice transactions. Paying more can consume more recovered value; choosing too little can weaken competitiveness when blockspace is expensive. A sample setting is not a guarantee that a future breach will be resolved economically or promptly.
Questions worth asking
Before treating a tower as part of an outage plan, establish:
- Which channel types and outputs does this exact client/server combination protect? Lightning Labs' policy API distinguishes legacy, anchor and Taproot clients; compatibility should not be guessed from old tutorials.
- Are updates being acknowledged, or merely queued? The client statistics API distinguishes backups made, pending acknowledgments and failed acknowledgments. Its counters are in-memory statistics since startup, not a permanent audit trail.
- Who notices when updates stop, the tower loses chain access or its operator retires the service?
- What fee policy applies, and what remains the node operator's responsibility?
A useful watchtower arrangement produces evidence of coverage and continued operation. Treat it as a specific, time-sensitive security service, then check whether that service matches the outage you are trying to survive.