Lightning Watchtower Setup Guide

Why You Need a Lightning Watchtower

When you run a Lightning node, your funds depend on your ability to monitor the blockchain for cheating attempts. If your channel counterparty broadcasts an outdated commitment transaction — one where they had a higher balance — you have a limited window (typically 144-2016 blocks) to respond with a penalty transaction and claim the entire channel balance.

The problem: your node must be online to detect and respond to these breach attempts. If you lose power, your internet goes down, or your hardware fails during that window, you cannot defend yourself. A watchtower solves this by monitoring the blockchain on your behalf and broadcasting penalty transactions automatically if a breach is detected.

This guide covers setting up watchtower protection for your Lightning node, whether you run LND or Core Lightning.

How Watchtowers Work

The Breach Detection Process

1. Registration: Your Lightning node registers with a watchtower, providing a breach hint and encrypted penalty data for each channel state update. Together they contain enough information for the watchtower to construct a penalty transaction but do not reveal your channel balances or transaction history.
2. Monitoring: The watchtower watches every new block for transactions that match any registered breach hint.
3. Response: If a match is found (meaning a counterparty broadcast an old commitment transaction), the watchtower decrypts the corresponding penalty data and broadcasts the penalty transaction, which sends the cheater’s balance to you.
4. Settlement: You end up with both balances. The penalty takes the cheater’s, and your own balance in that old state was already paid to you (LND’s tower sweeps both in the same transaction). LND’s built-in tower and The Eye of Satoshi take no cut: you get the funds back minus the on-chain fee. Neither tower covers payments that were still in flight at that moment.

Privacy Considerations

Well-designed watchtower protocols minimize the data exposed to the watchtower operator:

• The watchtower only learns about a channel when a breach actually occurs. The hints and the encrypted penalty data reveal nothing about your channels during normal operation.
• The watchtower cannot determine your channel balances, counterparties, or payment history from the hints alone.
• The watchtower only learns the channel details if it needs to construct a penalty transaction — which only happens during an actual cheating attempt.

This design means using a watchtower does not significantly compromise your Lightning privacy, though the operator can see the IP address you connect from, unless you connect over Tor. It does not learn your node’s public key: LND talks to towers with separate session keys, and the Core Lightning plugin uses a key pair of its own.

LND Watchtower Setup

LND includes a built-in watchtower client and server. You can use your own second server as a watchtower or connect to a trusted third-party watchtower.

The watchtower client is off by default (wtclient.active=false). Switch it on when you open your first channel, not the night before a trip. After every channel update, your node sends the tower the penalty for the balance it has just revoked, and it never sends older ones later, so a tower only guards the balances revoked after its client was switched on. Lightning Backups and Watchtowers has the details.

Prerequisites

• An up-to-date LND: as of November 2026, version 0.21.6 or 0.20.7, the releases our Linux security advisory asks Lightning nodes to run
• Access to your LND node’s command line or API (on Umbrel and Start9, the node’s settings screens are enough: see below)
• If running your own watchtower: a separate server or device with LND installed

Option A: Connect to an Existing Watchtower

The simplest approach is to use a tower someone else runs, such as a friend’s LND node with its tower switched on. LND advises tower operators not to publish their tower’s key, so LND towers are usually shared privately: ask the operator for the tower’s URI (pubkey@host:port).

1. Enable the watchtower client in your lnd.conf:

[wtclient]
wtclient.active=true

2. Restart LND to apply the configuration. If LND runs as a systemd service named lnd:

sudo systemctl restart lnd

3. Add a watchtower using its public key and address:

lncli wtclient add pubkey@host:port

4. Verify the connection:

lncli wtclient towers

This command lists all registered watchtowers and their status. You should see the tower you added; under session_info, active_session_candidate: true means your node can open new backup sessions with it, and num_sessions counts the sessions it has opened so far. The next step shows whether backups are actually reaching your towers.

5. Check that sessions are being created:

lncli wtclient stats

This shows the number of backup updates sent to your watchtowers (num_backups). The count should increment as you make Lightning transactions, while num_failed_backups stays at zero.

Option B: Run Your Own Watchtower Server

For maximum sovereignty, run your own watchtower on a separate device. This eliminates trust in a third-party operator.

1. On your watchtower server, install LND and enable the watchtower server in lnd.conf:

[watchtower]
watchtower.active=true
watchtower.listen=0.0.0.0:9911

2. Start LND on the watchtower server and create its wallet, as on any LND node: the tower’s key is derived from that wallet. The tower needs no channels or funds of its own, and it begins listening on port 9911.

3. Retrieve the watchtower’s public key:

lncli tower info

This outputs the tower’s public key and the addresses it listens on. The tower’s URI is that public key, an @, and the address and port your node will use to reach it: pubkey@host:9911. If you also set watchtower.externalip to the tower’s IP address in its lnd.conf, the uris field of this command shows the full URI for you.

4. On your primary Lightning node, add your watchtower as described in Option A using the URI from step 3.

Hardware suggestion: A small, low-power computer with a steady internet connection, such as a Raspberry Pi, can serve as a watchtower. Like any LND node, the tower needs a source of new blocks: either a Bitcoin Core node or Neutrino, LND’s built-in light client, which follows the chain through other people’s full nodes instead of one of its own. LND also runs on a pruned Bitcoin Core node (one that keeps only recent blocks), though it is slower and uses more bandwidth that way, and LND’s safety guide recommends an unpruned one. The Eye of Satoshi, covered below, needs Bitcoin Core.

Umbrel/Start9 Watchtower Setup

If you run Umbrel or Start9, you switch on the watchtower client and add towers in the node’s own settings, with no command line. These steps match Umbrel’s Lightning Node app (version 0.21.6) and StartOS 0.4, as of November 2026.

On Umbrel, in the Lightning Node app, which runs LND:

1. Open the Lightning Node app, click the three-dot menu on its main screen and choose Advanced Settings.
2. Open the Watchtower group, switch on Watchtower Client and click Save and Restart Node.
3. When the node is back, open Advanced Settings again, paste the tower’s URI (pubkey@host:port) into the box under Watchtower Client and click Add. Each tower you add appears in the list below it.

The same group has Watchtower Service, which turns this node into a tower for other people and shows its URI once you save and restart, and Watchtower Client Sweep Fee Rate, LND’s wtclient.sweep-fee-rate (10 sat/vB by default).

To check your towers from a command line, open umbrelOS Settings, then Advanced settings, Terminal and App, and choose Lightning Node: that opens a terminal inside LND’s container, where lncli wtclient towers and lncli wtclient stats work as shown above. Over SSH (ssh umbrel@umbrel.local), put docker exec -it lightning_lnd_1 in front of each command, as in docker exec -it lightning_lnd_1 lncli wtclient towers.

On Start9, in the LND service:

1. Open the LND service and go to its actions & config page.
2. Under Watchtower, open Watchtower Client Settings, set Enable Watchtower Client to Enabled and add each tower’s URI under Add Watchtowers. LND restarts, and it adds the listed towers every time it starts.

To run a tower for other people, Watchtower Server picks the address it can be reached at (its Tor onion address by default), and Watchtower Server Info shows the URI to share. StartOS’s Core Lightning service has its own watchtower settings, covered in the next section. For general node management guidance, see our Lightning node infrastructure guide.

Core Lightning Watchtower Options

Core Lightning (CLN) does not include a built-in watchtower system like LND. Instead, the CLN ecosystem uses external watchtower implementations:

The Eye of Satoshi (teos)

TEOS is a standalone watchtower implementation compatible with CLN. It is developed as an independent project and follows the BOLT watchtower specification proposals. Its last tagged release, v0.2.0, dates from February 2023, and the repository’s latest change is from October 2025. It still works as described below, but it gets little maintenance, so build it from the current source and keep the tower’s host up to date.

On Start9, the Core Lightning service already includes The Eye of Satoshi, both the client plugin and the tower. In its actions & config page, Watchtower Settings has a Watchtower Client switch with a list of tower URIs (tower_id@host:port) and a Watchtower Server switch, and Watchtower Client Info shows the towers your node uses. Volunteers share public towers in the project’s altruistic tower list. Most of its entries date from 2022 and 2023, so after you register a tower, check that it shows as reachable (see “Verify Watchtower Operation” below). The steps below are for a Core Lightning node you set up yourself.

1. Install the teos watchtower server on your secondary device. These commands, from the project’s install guide, build it with Rust’s cargo tool and install two programs, teosd (the tower) and teos-cli (its control tool), in ~/.cargo/bin:

git clone https://github.com/talaia-labs/rust-teos.git
cd rust-teos
cargo install --locked --path teos

2. Configure teos with your Bitcoin Core RPC credentials, in a file named teos.toml in its data folder (~/.teos/ by default):

# ~/.teos/teos.toml
btc_network = "mainnet"
btc_rpc_user = "your_rpc_user"
btc_rpc_password = "your_rpc_password"
btc_rpc_connect = "127.0.0.1"
btc_rpc_port = 8332
# the default, 127.0.0.1, only accepts connections from this machine
api_bind = "0.0.0.0"
api_port = 9814

3. Start the teos server:

teosd

4. On your CLN node, install the teos client plugin, which installs a program called watchtower-client in ~/.cargo/bin:

git clone https://github.com/talaia-labs/rust-teos.git
cd rust-teos
cargo install --locked --path watchtower-plugin

5. Load the plugin in CLN:

lightning-cli plugin start ~/.cargo/bin/watchtower-client

A plugin started this way stops when CLN restarts, and your backups stop with it. To load it at every start, add a line such as plugin=/home/you/.cargo/bin/watchtower-client, with your own home folder, to CLN’s config file (~/.lightning/config by default).

6. Register with your teos server, using the tower ID that teos-cli gettowerinfo shows on the tower:

lightning-cli registertower tower_id@host:port

Best Practices for Watchtower Configuration

Use Multiple Watchtowers

Do not rely on a single watchtower: if your node and your only tower are both down when a partner cheats, nobody answers. The two clients use several towers in different ways:

• Core Lightning: the plugin sends every update to every tower you register, so each tower holds a full copy. If one goes offline, the others still cover every balance.
• LND: the client sends each update to one tower only. It fills a session of up to 1,024 updates (wtclient.max-updates) with one tower, then starts the next session with the next tower on your list. So your towers split your history between them, and on a node with few payments one tower may hold all your recent updates for a long time. If a partner publishes an old balance, the tower holding it has to be online. With LND, how reliable each tower is matters more than how many you have: start with your own tower on separate hardware.

With either client, a tower you add later holds only the updates made after you add it. Each client works with its own kind of tower: LND’s client with LND towers (port 9911), and the Core Lightning plugin with The Eye of Satoshi towers (port 9814). Aim for 2-3 independent watchtowers:

• Your own watchtower on separate hardware
• One or two community-operated watchtowers
• Optionally, a watchtower hosted on a VPS in a different geographic location

Verify Watchtower Operation

Periodically check that your watchtower connections are active:

# Check tower status
lncli wtclient towers

# Check backup statistics
lncli wtclient stats

The stats should show incrementing backup counts corresponding to your channel activity. If numbers stagnate while you are making payments, investigate the watchtower connection. If num_pending_backups keeps growing, the tower LND is using is not taking backups: add another tower, then run lncli wtclient remove followed by the stuck tower’s public key, and LND hands its pending backups to your other towers.

On Core Lightning, lightning-cli listtowers shows each tower’s status, which should be reachable. A subscription error means your subscription with that tower has run out (on a tower with default settings, 10,000 updates or about a month); run registertower again to renew it.

Geographic Distribution

Place your watchtower on different infrastructure than your primary node. If both run on the same hardware, a single failure takes out both your node and its protection. If both are in the same house, a power outage disables both. Ideal setup: primary node at home, watchtower on a separate hosted server or at a trusted friend’s location.

Storage Considerations

Watchtower servers store a breach hint and an encrypted penalty for every channel update of every registered client. Storage requirements grow with the number of clients and their channel update frequency, but each update is small: a few hundred bytes (about 330 in LND). A watchtower serving a few dozen nodes needs negligible additional storage.

When Are Watchtowers Actually Needed?

The realistic threat model for watchtowers centers on these scenarios:

• Extended node downtime: If your node stays offline for longer than your shortest waiting period, about a day on small LND channels, a malicious counterparty could broadcast an old state and keep it. Watchtowers protect during this window.
• Hardware failure: If your node’s storage fails and you lose channel state, you cannot respond to breaches yourself. A watchtower retains the breach hints independently.
• Natural disasters: Fire, flood, or other events that destroy your hardware. A geographically separate watchtower continues monitoring.

In practice, breach attempts are extremely rare on the Lightning Network. The economic incentive is weighted heavily against cheating — a failed attempt results in total loss of channel funds via the penalty mechanism. However, the cost of running a watchtower is so low that the protection is worth having as insurance, particularly as your channel balances grow. Effective channel management combined with watchtower protection provides the strongest defense for your Lightning funds.

Watchtower Costs

Approach	Setup Effort	Running Cost	Trust Level
Community watchtower	5 minutes	Nothing for you	Trust the operator
Own watchtower on a Raspberry Pi	1-2 hours	The electricity of a small computer	Self-sovereign
VPS-based watchtower	30 minutes	A small VPS plan	Trust VPS provider

For most home node operators, the combination of one self-hosted watchtower and one community watchtower provides robust protection at minimal cost. For more on overall node operation and security, see our comprehensive guide.

FAQ

Does a watchtower see my Lightning payments or channel balances?

No. During normal operation, the watchtower only stores breach hints and encrypted penalty data that it cannot decrypt. The watchtower only learns channel details if an actual breach occurs and it needs to construct a penalty transaction. Your payment history, channel balances, and counterparty identities remain private under normal conditions.

What happens if my watchtower goes offline at the same time as my node?

If both your node and your watchtower are offline at the same time, nobody is watching during that window. That is why a tower should run on different hardware from your node, with its own power and internet, so that a single power cut, internet outage or disaster cannot take both down. With Core Lightning, every tower you register holds every update, so a second or third tower covers you while one is down. LND sends each update to only one of your towers, so with LND the reliability of each tower matters more than the number: start with your own tower on separate hardware.

Can a watchtower steal my funds?

No. The watchtower only has the information needed to construct penalty transactions, which send funds to your address. It cannot construct transactions that redirect funds to itself. The worst a malicious watchtower can do is fail to act during a breach. Running your own tower removes that doubt, and with Core Lightning you can also register several towers, each holding every update.

Do I need a watchtower if my node is always online?

A node that is reliably online 24/7 — as described in our guide on running a Lightning node at home — can detect and respond to breaches on its own. However, no system is truly “always online.” Hardware failures, software crashes, power outages, and internet disruptions happen to everyone eventually. A watchtower costs almost nothing to run and provides insurance against these inevitable events. The question is not whether your node will go offline, but when — and whether you are protected when it does.