Timechain Wiki

Watchtowers

9 min read

Watchtowers are third-party services that monitor a Lightning operator's channels for force-close attempts and broadcast a punishment transaction if a counterparty publishes a revoked commitment state. They address Lightning's structural "must be online" requirement: under the LN-Penalty (Poon-Dryja) construction, the honest party must observe and respond to a malicious broadcast within a relative-timelock window or lose the punishment opportunity. Operators who cannot guarantee continuous online presence can outsource this monitoring. Two trust models exist: altruistic watchtowers (no fee, weaker liveness) and reward-or-fee watchtowers (paid; stronger incentive alignment). The architecture is BOLT-specified (BOLT 13 draft) but adoption has been uneven. The proposed eltoo upgrade — using SIGHASH_NOINPUT or similar — would obviate watchtowers by replacing punishment-and-revocation with a "newest state wins" rule, contingent on covenant-enabling soft forks not yet on a published timeline.

Why this note matters

The watchtower architecture is the operational response to one of Lightning’s most consequential design constraints. The LN-Penalty construction makes off-chain state advancement safe by making it economically suicidal to broadcast old state — but the safety guarantee depends on someone observing and punishing the broadcast within the relative-timelock window. Watchtowers operationalize that “someone” for users who cannot be online continuously themselves.

Understanding watchtowers also illuminates the eltoo-vs-current-Lightning tradeoff. The proposed eltoo upgrade would remove the punishment-and-revocation mechanism entirely, replacing it with a simpler “newest state always wins” construction. Watchtowers would become unnecessary for eltoo channels. The watchtower architecture is partly an artifact of the current consensus rules; a future-Bitcoin protocol that activates SIGHASH_NOINPUT (or its equivalent) could deprecate the entire monitoring layer.

The structural need — Lightning’s online requirement

Under the current LN-Penalty construction (described in detail in Lightning channels):

  • Each channel-state update produces a new commitment transaction; the prior commitment becomes “revoked.”
  • Either party can broadcast the most recent commitment unilaterally; only the most recent commitment is economically safe.
  • If a party broadcasts a revoked (older) commitment, the counterparty has a window — the to_self_delay relative-timelock, typically 144-1008 blocks (~1-7 days) — to observe the broadcast and respond with a punishment transaction that sweeps the broadcaster’s entire channel balance.
  • If the counterparty does not respond within the timelock window, the broadcaster’s funds become spendable to the broadcaster — even though they cheated.

The honest-party-must-be-online requirement is structural. An operator who runs a Lightning node continuously can defend their own channels. An operator who is offline for the to_self_delay window or longer has no defense against a counterparty’s cheat-broadcast — unless someone else is watching on their behalf.

The watchtower mechanism

A watchtower is a third-party service that maintains state on behalf of a Lightning operator and responds to channel-related events:

  1. At each commitment update, the operator’s Lightning node sends the watchtower a small encrypted update package — sufficient information for the watchtower to construct a punishment transaction if the counterparty broadcasts the corresponding revoked commitment, but not enough to reveal channel balances or payment activity to the watchtower.
  2. The watchtower stores the update package indexed by a state-identifier (typically a hash of the commitment transaction’s txid). Modern watchtowers store millions of state updates across many channels.
  3. The watchtower monitors the base-layer chain for transactions matching any of its stored commitment txids. When a match is found, the watchtower retrieves the corresponding punishment package, constructs the punishment transaction, and broadcasts it to the base layer.
  4. The honest party (the watchtower’s client) receives the full channel balance when the punishment transaction confirms — assuming it confirms within the relative-timelock window.

The encrypted-blob construction. The information the watchtower receives is engineered to be useful only for the punishment task. The watchtower cannot decrypt channel balances, cannot see payment history, and cannot infer the client’s channel partners. The watchtower learns only that some channel exists and may need punishment.

Trust models

Two principal watchtower-trust models have emerged:

Altruistic watchtowers. Operated by community-minded individuals or organizations without explicit fees. The client trusts the operator’s continued goodwill, the operator’s continued operational uptime, and the operator’s continued storage of update packages. Many altruistic watchtowers run as community services with varying degrees of reliability.

Reward or fee watchtowers. Operated as paid services with explicit incentive alignment. The client pays per-update or per-channel; the watchtower’s economic interest is aligned with continued reliable service. Some reward-watchtower designs include reward-output mechanisms in the punishment transaction itself — the watchtower can be compensated from the punishment proceeds. Reward-watchtower architectures are technically possible but adoption has been slow due to specification and implementation maturity.

The watchtower-liveness assumption. Both models assume the watchtower is online when needed. A watchtower that goes offline during a counterparty’s cheat-broadcast window provides no protection. Modern Lightning operators who rely on watchtowers typically configure multiple watchtowers in parallel for redundancy.

The defense-against-fraud-broadcast-by-watchtower concern. A watchtower itself could not steal client funds (the watchtower’s update package only allows constructing punishment transactions; the watchtower does not have channel-state signing keys). A watchtower could fail to act — but that is a liveness failure, not a custody failure. The trust profile is liveness-only, not custody-bearing.

The BOLT 13 specification status

The watchtower specification is BOLT 13 (draft status as of 2026). Standardization has been slower than other Lightning protocol layers because:

  • Multiple competing design proposals existed in the early Lightning ecosystem
  • The eltoo upgrade path would obviate the need entirely, reducing urgency
  • Implementation-specific watchtower designs (LND’s altruist_v2 protocol; CLN’s plugin-based watchtowers) addressed practical needs ahead of formal specification

Implementation status:

  • LND ships native watchtower support (altruistic) and supports configuring multiple watchtowers
  • Core Lightning / CLN supports watchtowers via plugins (watchtower plugin; sauron plugin; others)
  • Eclair has experimental watchtower support
  • Mobile-Lightning wallets (Phoenix, Breez, Zeus) approach watchtowers differently — many rely on the wallet provider’s infrastructure rather than user-configured watchtowers

The standardization process is ongoing. As of 2026, watchtower deployment is a fragmented operational reality rather than a uniform protocol-level feature.

eltoo and the future of watchtowers

The proposed eltoo construction would change Lightning’s state-advancement mechanism fundamentally:

  • Under LN-Penalty, the most recent commitment is “valid” and prior commitments are revoked-and-punishable.
  • Under eltoo, the protocol enforces a simple “newer commitment supersedes older” rule directly. Broadcasting an older commitment cannot harm the honest party because the honest party can immediately broadcast the newer commitment as a replacement.

The mechanism. Eltoo would use SIGHASH_NOINPUT (or SIGHASH_ANYPREVOUT, the renamed proposal) to allow each commitment transaction to spend the prior commitment transaction without binding to a specific previous-commitment txid. A counterparty who broadcasts an older commitment can be immediately superseded by the honest party broadcasting the newer commitment, regardless of the order or timing.

The consequence for watchtowers. Eltoo channels would not require continuous monitoring. The honest party could be offline indefinitely without exposure; on returning online, they could broadcast the newer commitment to resolve any in-flight bad-commitment situation. Watchtowers would still be useful for liveness reasons (responding to in-flight HTLCs that need on-chain settlement) but the safety-against-fraud function would be obviated.

The activation barrier. SIGHASH_NOINPUT (or its equivalent) requires a base-layer soft-fork upgrade. The OP_CTV/CHECKTEMPLATEVERIFY discussion (see OP_CAT and the covenants programmability debate) and broader covenant debate includes eltoo-relevant proposals, but no concrete activation timeline is published. The watchtower architecture remains operationally relevant for the foreseeable future.

Tradeoffs and design choices

Outsourced monitoring vs running-your-own-node. An operator who runs a Lightning node continuously does not need a watchtower — they can defend their own channels. The choice is between operational complexity (continuous node operation) and trusted-intermediary dependence (watchtower with liveness assumption). The self-custody-discipline ladder applies: pure self-sovereignty > self-sovereignty-with-watchtowers > custodial Lightning.

Encrypted-blob protocol vs richer-protocol designs. The encrypted-blob design provides strong privacy (watchtower learns minimum) but limits the watchtower’s functions (cannot help with cooperative close, cannot help with HTLC management, cannot help with channel-rebalancing). Richer-protocol designs would allow watchtowers to provide more services but at the cost of additional information disclosure to the watchtower.

Multi-watchtower redundancy vs single-watchtower simplicity. Configuring multiple watchtowers in parallel improves liveness assurance but requires sending each update to multiple destinations and incurs the multi-tower bandwidth cost. Most modern Lightning operators configure 1-3 watchtowers; the optimal number depends on watchtower-provider reliability.

Altruistic vs reward economics. Altruistic watchtowers don’t bill but offer weaker reliability guarantees; reward watchtowers offer stronger guarantees but the payment-mechanism design is still evolving. The economic-equilibrium question for reward-watchtower pricing is unsettled.

The eltoo transition. The current watchtower architecture is partly an artifact of LN-Penalty’s design. Migration to eltoo-based channels would shift the watchtower role substantially. Existing LN-Penalty channels would coexist with eltoo channels during any transition; the operational complexity of managing two construction families is real.

Substantive analytical critique of the watchtower-liveness requirement lives in Lightning Network operational critiques.

Open questions for further development

  • Will BOLT 13 reach final-spec status, and what will it look like? The specification has been incrementally refined; finalization timeline is unclear.
  • Will reward-watchtower designs achieve broad adoption? The incentive alignment is structurally attractive; the implementation-and-payment complexity has slowed deployment.
  • What is the eltoo activation timeline? SIGHASH_NOINPUT activation depends on broader covenant-debate resolution; concrete timelines are not published.
  • How do mobile-Lightning wallets balance watchtower needs against the trusted-LSP architecture? Many mobile wallets effectively delegate watchtower function to the LSP; the trust profile is opaque to the operator.
  • What is the role of watchtowers in eltoo channels? Eltoo obviates the safety-against-fraud role but liveness-for-HTLC-resolution may still warrant watchtower-like infrastructure.

Canonical sources for this note

Specifications

  • BOLT 13 (draft) — Watchtowers Specification: github.com/lightning/bolts (status varies)
  • Christian Decker, Rusty Russell, Olaoluwa Osuntokun, “eltoo: A Simple Layer2 Protocol for Bitcoin” (2018) — the eltoo proposal
  • BIP 118 — SIGHASH_ANYPREVOUT (renamed from SIGHASH_NOINPUT): github.com/bitcoin/bips/blob/master/bip-0118.mediawiki

Foundational references

  • Mastering the Lightning Network — Chapter 16 treats watchtowers and the broader online-requirement context
  • LND watchtower documentation: github.com/lightningnetwork/lnd/tree/master/docs/watchtower.md
  • CLN watchtower plugin documentation

Graph View

Backlinks