Watchtowers

Watchtowers are third-party services that monitor the Bitcoin blockchain for channel breaches on your behalf. They provide security for Lightning nodes that cannot be online 24/7.

Why Watchtowers?

Lightning channels rely on both parties being able to detect and respond to cheating attempts. If your counterparty broadcasts an old commitment transaction, you must respond with a penalty transaction before the timelock expires.

The Problem: If your node is offline when a breach occurs, you cannot detect or respond to it.

The Solution: Watchtowers monitor the blockchain for you and broadcast penalty transactions automatically.

How Watchtowers Work

Registration

Your node generates encrypted breach hints for each channel state
You send these hints to a watchtower
The watchtower stores them without knowing your channel details

Monitoring

Watchtower monitors the blockchain for new transactions
For each new transaction, it checks against stored hints
If a hint matches, the watchtower can decrypt and broadcast the penalty

Penalty Execution

When a breach is detected:

Watchtower decrypts the penalty transaction
Broadcasts it to the Bitcoin network
Penalty transaction claims all channel funds
Watchtower may take a fee from recovered funds

Normal Flow:
Node → Watchtower: Encrypted breach hints (per state update)
Watchtower → Blockchain: Monitor for matching transactions

Breach Detection:
Counterparty → Blockchain: Old commitment transaction
Watchtower → Blockchain: Penalty transaction (claims funds)

Breach Hint Structure

Breach hints allow watchtowers to detect breaches without knowing channel details:

Breach Hint:
├── Locator (16 bytes): SHA256(breach_txid)[0:16]
├── Encrypted Blob: AES-encrypted penalty transaction
└── Session Info: Tower identification

The locator is derived from the commitment transaction ID. When a watchtower sees a transaction matching a locator, it can decrypt and broadcast the penalty.

Privacy Considerations

Well-designed watchtower protocols preserve privacy:

Information	Known to Watchtower
Channel partners	No (encrypted)
Channel capacity	No (encrypted)
Channel balance	No (encrypted)
Number of updates	Yes (hint count)
Breach occurred	Yes (if triggered)

Encrypted Blobs

The penalty transaction is encrypted with a key derived from the commitment transaction:

encryption_key = SHA256(breach_txid || session_key)
encrypted_blob = AES_CTR(penalty_tx, encryption_key)

Watchtowers cannot read the blob until they see the actual breach transaction on-chain.

Watchtower Implementations

LND Watchtower (wtclient/wtserver)

LND includes built-in watchtower support:

# Enable watchtower client in lnd.conf
[wtclient]
wtclient.active=true

# Connect to a watchtower
lncli wtclient add <tower_pubkey>@<host>:<port>

# List connected towers
lncli wtclient towers

# Check tower stats
lncli wtclient stats

Running Your Own Tower (LND)

# Enable watchtower server in lnd.conf
[watchtower]
watchtower.active=true
watchtower.listen=0.0.0.0:9911

# Get your tower's URI
lncli tower info

The Eye of Satoshi (TEOS)

An independent watchtower implementation:

# Install TEOS
cargo install teos

# Run the tower
teosd --btc_network=mainnet

# Register with TEOS from your node
# (implementation specific)

Watchtower Economics

Costs

For tower operators:

Storage: ~200-500 bytes per channel state
Bandwidth: Monitoring blockchain and receiving hints
Computation: Checking transactions against hints

For users:

Bandwidth: Sending hints after each channel update
Fees: Some towers charge per-hint or percentage of recovered funds

Fee Models

Model	Description
Free (altruistic)	Community-run, no fees
Per-hint	Fixed fee per state update
Recovery percentage	Tower keeps % of penalty funds
Subscription	Monthly/yearly flat fee

Backup Strategies

Watchtowers complement but don't replace proper backups:

What Watchtowers Protect Against

Counterparty broadcasting old state while you're offline
Short-term node downtime
Network connectivity issues

What Watchtowers Don't Protect Against

Loss of node data (seed, channel state)
Cooperative close disputes
Your own mistakes (broadcasting old state)

Recommended Setup

Multiple watchtowers: Don't rely on a single tower
Static Channel Backups (SCB): For disaster recovery
Regular node backups: Full database backups
Monitoring: Alerts for extended downtime

Watchtower Selection

When choosing watchtowers, consider:

Reliability

Uptime track record
Geographic distribution
Infrastructure quality

Privacy

Protocol used (encrypted blobs?)
Data retention policy
Logging practices

Trust Model

Trust Spectrum:
├── Self-hosted (most trust, most effort)
├── Friend's tower (trusted party)
├── Community towers (reputation-based)
└── Commercial towers (contractual)

Protocol Variants

BOLT Draft (Original)

The original watchtower proposal (never finalized as BOLT):

Simple locator-based matching
Single tower per channel
Basic encrypted blobs

TEOS Protocol

Enhanced protocol with:

Appointment-based scheduling
Accountability proofs
Multiple tower support

VLS (Validating Lightning Signer)

Alternative approach where signing is done remotely:

Signer validates all transactions
Can refuse to sign old states
Eliminates need for breach monitoring

Common Issues

Tower Unreachable

Problem: Cannot connect to watchtower.

Solutions:

Check network connectivity
Verify tower address/port
Try alternative towers
Run your own tower

Hint Upload Failures

Problem: Failed to send breach hints.