Watchtower

What Is a Watchtower?

A watchtower is a service that monitors the Bitcoin blockchain on behalf of Lightning Network users, watching for fraudulent channel closure attempts. When a counterparty tries to steal funds by broadcasting an old channel state, the watchtower detects the breach and broadcasts a penalty transaction that claims all channel funds for the honest party.

The name evokes a medieval tower keeping watch for approaching threats. In the Lightning context, the threat is a malicious channel partner attempting to cheat by publishing a revoked commitment transaction. The watchtower stands guard, ready to respond even when the channel owner is asleep, offline, or otherwise unavailable.

Watchtowers solve a fundamental challenge in Lightning Network security: the requirement for users to remain online and monitor the blockchain continuously. Without watchtowers, a user who goes offline for extended periods risks losing their channel funds to a dishonest counterparty who exploits their absence.

Why Watchtowers Exist

Lightning Network channels use a clever punishment mechanism to ensure honesty. Each time the channel state updates, both parties exchange revocation keys for the previous state. If someone broadcasts an old state, the other party can use these keys to claim all funds in the channel as a penalty.

However, this punishment mechanism has a critical requirement: the honest party must detect the breach and respond within a time window, typically 144 blocks (about 24 hours) but configurable per channel. If the honest party is offline and misses this window, the cheater successfully steals the funds.

This creates an asymmetry that favors attackers. A malicious actor can wait for their target to go on vacation, experience an internet outage, or simply sleep, then broadcast a favorable old state. The victim, unaware of the attack, loses their funds by default.

Watchtowers eliminate this asymmetry. By delegating monitoring to a third party, users gain protection regardless of their online status. The watchtower provides 24/7 vigilance, responding to breaches instantly even when the channel owner cannot.

For mobile wallet users, watchtowers are particularly important. Phones have unreliable connectivity, limited background processing, and users may not open their wallet apps for days or weeks. Without watchtower protection, these users would be vulnerable to any counterparty willing to attempt fraud.

How Watchtowers Work

Watchtower operation follows a specific protocol to enable breach detection and response:

1. Client registration. The Lightning wallet connects to a watchtower and establishes a monitoring relationship. This may involve authentication, payment, or simply a request to begin watching.
2. State backup. Each time the channel state updates, the client sends encrypted breach remedy data to the watchtower. This data contains just enough information for the watchtower to respond to a specific breach, but reveals nothing about channel balances or normal activity.
3. Continuous monitoring. The watchtower watches every Bitcoin block, comparing transaction IDs against its database of potential breaches. This requires scanning the blockchain but not maintaining full channel state.
4. Breach detection. If a watched commitment transaction appears on-chain, the watchtower decrypts the corresponding remedy data using the transaction ID as the decryption key.
5. Penalty broadcast. The watchtower constructs and broadcasts the penalty transaction (also called a justice transaction), claiming all channel funds to an address controlled by the honest party.

The encryption scheme is crucial for privacy. The watchtower stores encrypted blobs that it cannot read until a breach occurs. The breach transaction itself serves as the decryption key, meaning the watchtower learns channel details only when intervention is necessary.

This design achieves a useful property: the watchtower can protect many channels without learning anything about them during normal operation. Only actual fraud triggers information disclosure, and at that point, the information enables justice rather than surveillance.

Types of Watchtowers

Commercial Watchtowers

Professional watchtower services charge fees for their monitoring. These may be subscription based (monthly fee), per-update (small payment each time you backup state), or commission-based (percentage of recovered funds). Commercial watchtowers have financial incentives to maintain reliability and uptime.

The business model aligns incentives: users pay for peace of mind, and the service profits by providing reliable protection. However, this centralization creates potential single points of failure and surveillance concerns.

Self-Hosted Watchtowers

Users can run their own watchtowers on separate infrastructure. A server in a different location than your Lightning node provides redundancy. If your main node goes offline, your watchtower continues monitoring and can respond to breaches.

Self-hosting eliminates third-party trust but requires technical capability and infrastructure costs. It works well for power users and businesses but is impractical for casual Lightning users.

Altruistic Watchtowers

Altruistic watchtowers operate without charging users, providing free breach protection as a public good. These services are typically run by community members, Lightning developers, or organizations promoting network health.

The altruistic model has gained significant attention as a way to improve Lightning security without adding costs for end users. Projects like The Eye of Satoshi and community-run instances provide decentralized monitoring infrastructure.

However, altruistic watchtowers raise sustainability questions. Without revenue, operators depend on donations or goodwill. Users must trust that the service will remain operational, and there is no financial recourse if it fails. Despite these concerns, altruistic watchtowers play an important role in democratizing Lightning security.

Integrated Watchtowers

Some Lightning service providers integrate watchtower functionality directly. Wallet providers, exchanges, and custodial services often monitor channels for their users automatically. Users gain protection without explicit watchtower setup, though they must trust the provider.

Trust and Privacy Considerations

Using a watchtower involves sharing information with a third party, creating both trust and privacy implications:

What Watchtowers Learn

In the standard BOLT watchtower protocol, the watchtower learns minimal information during normal operation. It stores encrypted blobs keyed by commitment transaction IDs. It cannot correlate blobs to specific channels, determine channel balances, or observe payment activity.

When a breach occurs, the watchtower learns more: the channel funding outpoint, the penalty transaction details, and the recovery address. This information exposure is limited to fraud scenarios and enables the watchtower to execute its protective function.

Trust Requirements

Watchtowers cannot steal funds. The penalty transaction they broadcast sends money to an address the user controls. A malicious watchtower could fail to respond to breaches, but it cannot redirect recovered funds.

The primary trust assumption is reliability: users trust that the watchtower will actually respond when needed. A watchtower that goes offline during a breach attack provides no protection. For this reason, users may register with multiple independent watchtowers for redundancy.

Privacy Enhancements

Research continues on improving watchtower privacy. Proposals include blind signatures to prevent watchtowers from correlating updates, homomorphic encryption for state validation, and network-level protections to hide which user submitted which backup.

Alternative architectures like Spark take a different approach, eliminating the breach vulnerability entirely through protocol design rather than monitoring infrastructure.

Implementation and Deployment

LND Watchtower

LND includes built-in watchtower client and server functionality. The server mode lets you run a watchtower that others can connect to. The client mode connects to external watchtowers for protection.

# lnd.conf - Enable watchtower server
watchtower=true
watchtower.listen=0.0.0.0:9911

# Enable watchtower client
wtclient.active=true
wtclient.sweep-fee-rate=10

Core Lightning (CLN)

Core Lightning supports watchtowers through plugins. The watchtower plugin provides similar functionality to LND's built-in support, with backup and recovery capabilities.

BOLT 13 Specification

BOLT 13 defines a standard protocol for watchtower communication, ensuring interoperability between different Lightning implementations and watchtower services. The specification covers session establishment, state updates, and breach response coordination.

Alternatives to Watchtowers

While watchtowers address the monitoring problem, other approaches tackle the underlying vulnerability differently:

Longer Timeout Periods

Channels can be configured with longer to_self_delay periods, giving users more time to detect and respond to breaches. A 2-week timeout instead of 24 hours reduces watchtower dependency but adds friction to legitimate channel closures.

Channel Factories

Channel factories allow multiple parties to share a single on-chain UTXO. Some designs reduce or eliminate the breach vulnerability through different commitment structures, though they introduce new complexity.

Eltoo Channels

The proposed eltoo channel construction eliminates the punishment paradigm entirely. Instead of penalties for old states, eltoo allows any party to simply replace an old state with the current one. This removes the need for watchtowers but requires a Bitcoin soft fork (SIGHASH_ANYPREVOUT) that has not yet been activated.

Spark Protocol

Spark uses a fundamentally different architecture that does not require channels or commitment transactions. Without the revocation-based security model, there is no breach vulnerability and no watchtower requirement. Users gain Lightning-like speed without the monitoring burden.

FAQ