Lightning Backups and Watchtowers: Keeping Channel Funds Safe

Two things keep the money in your Lightning channels safe. Someone, your own node or a watchtower, must watch the blockchain and punish an outdated channel balance before the cheater’s waiting period runs out. And you must keep the right backups: your recovery words for on-chain funds and a fresh copy of channel.backup for the money in channels, while an old copy of channel.db never goes back onto a node. Recovery words alone protect on-chain bitcoin. A channel is different: what you own in it is the latest balance you and your peer (the node at the other end) both signed, and that record lives only on your node. This lesson covers both jobs, then what channels cost on-chain, so you can size yours sensibly.

Why Your Words Alone Aren’t Enough

Lightning Network Explained showed how a channel moves money: for every payment, both sides sign a new commitment transaction, a ready-to-publish transaction that pays each side its current share, and each hands the other a revocation key that cancels the previous one. Publishing a revoked commitment transaction is called a breach. That design creates risks a seed can’t cover:

What could go wrong	What protects you
A peer publishes an old balance while your node is off	Your node, if it is back in time; otherwise a watchtower
The node’s disk or memory card dies, taking the latest balances with it	Your recovery words plus a recent channel.backup
You restore an old copy of the channel data, so your node now holds an old balance	Nothing can: never restore channel.db
A channel has to close while fees are high	Channels big enough to be worth closing, and some bitcoin kept on-chain

The Watching Window

Either side can close a channel alone by publishing its latest commitment transaction: a force close. The closer’s own share is then locked for a waiting period, counted in blocks from the moment that transaction confirms. If the transaction is an old, revoked one, the other side can use the revocation key during that period to take the whole channel with a penalty transaction (also called a justice transaction). Once the period ends, the old balance stands.

Each node chooses the wait its peer must accept (BOLT 2, part of the Lightning specification, calls it to_self_delay), so your node sets your watching window when the channel opens. LND, the Lightning software most node platforms run, scales it with channel size: 144 blocks, about a day, for channels under 1,198,372 sats (a sat is a hundred-millionth of a bitcoin), rising to 2,016 blocks, about two weeks, from 16,777,215 sats up (LND sample configuration).

The rule follows: never leave your node off for longer than the shortest window among your channels, with a margin, because the penalty transaction must also confirm in time. “On” means LND running and your Bitcoin node in sync, since your node learns about a cheat from new blocks. To see each channel’s window, run lncli listchannels: under remote_constraints, csv_delay is how many blocks your peer must wait, your window to catch a cheat; under local_constraints, it is how long you would wait if you closed the channel yourself.

Watchtowers: Someone Watching While You’re Away

A watchtower is a server that holds penalty transactions for your channels and publishes the right one if a peer cheats while your node is off; LND calls it “a second line of defense” (LND watchtower guide). The tower watches; the watchtower client in your node keeps it supplied, sending after each channel update a small encrypted package the tower can only open once the matching revoked transaction appears on the blockchain. LND’s towers are altruist: they return all the funds, minus on-chain fees, and take no cut. Five things to know:

• The client is off by default. LND ships with wtclient.active=false (LND sample configuration). Running a Lightning Node shows how to switch it on in Umbrel and in plain LND, and our Lightning Watchtower Setup Guide goes step by step.
• A tower only knows balances revoked while the client runs. Your node sends each package at the moment a balance is revoked and never sends older ones later (LND source), yet a cheating peer can publish any old balance. Switch the client on when you open your first channel, not the night before a trip.
• The tower must be online when the cheat happens. Run it on another machine, ideally in another place with its own power and internet, or use one run by someone you trust. LND can be a tower itself (watchtower.active=1).
• It protects balances, not payments in flight. LND’s towers back up only the two balance outputs of a revoked transaction, not the outputs for payments still in progress (LND watchtower guide).
• Its fee is set in advance: 10 sat/vB by default (wtclient.sweep-fee-rate), meaning 10 satoshis per virtual byte of transaction size. A higher setting, which applies to backups made after you change it, gives penalties priority if fees jump while you’re away.

To check it is working, lncli wtclient towers lists your towers and lncli wtclient stats counts the backups sent, a number that should grow as you use your channels.

On a Phone Wallet

A wallet that runs its own Lightning node on your phone, as Phoenix does, needs watching too, and phones are often off. Phoenix watches the blockchain through Electrum servers (servers that answer wallets’ questions about the blockchain), and pointing it at your own “significantly reduces your dependency on third parties to secure your wallet,” says ACINQ, its maker. Open the app from time to time: a Phoenix wallet left unused for a long time may have its channel closed, with the money moved to its on-chain “final wallet” (Phoenix FAQ).

What to Back Up, and What Never to Restore

Three items on an LND node matter for recovery. Setting Up Your Bitcoin Node showed how to handle them in Umbrel; here is what each does.

Item	What it is	What it brings back	When to copy it
Your 24 words (and seed passphrase, if you set one)	LND’s seed	Your on-chain funds, and the key that unlocks channel.backup	Once, on paper or metal
channel.backup	The static channel backup: your channels and how to reach each peer, encrypted	Each listed channel’s settled balance, through a force close by the peer	After every channel you open or close
channel.db	The live record of every channel’s latest balance	Nothing you can safely use, once it is out of date	Never as a backup; never restore an old copy

The 24 Words

LND’s words use a format called aezeed. It shares the word list of BIP39, the standard most wallets use for recovery phrases, and nothing else, so the words restore into LND, not into an ordinary wallet expecting a BIP39 phrase (LND recovery guide). Label them as an LND seed. If you set the optional seed passphrase, store it somewhere else (kept with the words, it adds no protection) and never lose it: the words are encrypted with it, so without it they restore nothing (LND safety guide). Store them like any seed (Seed Phrase Storage Best Practices); Bitcoin Address Types and Derivation Paths explains why phrases restore in different places.

channel.backup, the Static Channel Backup

The file is “static” because it changes only when LND starts or a channel opens or closes, not with each payment, so a copy made after your last open or close is still complete. It is encrypted with a key derived from your 24 words: useless without them, and safe on a USB stick or in cloud storage (LND safety guide).

• Copy it off the node after every channel you open or close, or automate the copy. On plain LND, lncli exportchanbackup --all --output_file=channel.backup writes a fresh one. Umbrel’s Lightning Node app also uploads an encrypted copy to Umbrel’s backup server automatically, by default (Umbrel); keep your own as well.
• Check a copy without touching your channels: lncli verifychanbackup --multi_file=/path/to/channel.backup confirms the file is intact and belongs to your node.

channel.db, the File You Never Restore

Never treat it as a backup: the danger comes the day an old copy goes back onto a node. A copy from last night holds last night’s balances, and publishing a revoked balance is exactly what a breach is. In LND’s words, “having an old state of a channel basically means forfeiting the balance to the other party.” A backup or snapshot of the whole machine counts too: if it includes the Lightning data, restoring it puts an old channel.db back. Protect the live file instead. LND’s safety guide calls SD cards and USB thumb drives unsafe for a file written this often, recommends an SSD, suggests a UPS (a battery that rides out power cuts), and warns against unclean shutdowns and interrupted channel commands. If your platform keeps Lightning on a memory card, keep your channel.backup copies especially fresh.

On Core Lightning, the other common node software, hsm_secret holds the seed (nodes created since version 25.12 start from 12 BIP39 words), emergency.recover is the static backup, and database snapshots are discouraged “as any loss of state may result in permanent loss of funds”; the guide recommends real-time database replication instead (Core Lightning backup guide).

What a Recovery Gives Back

Say your node’s disk dies. On a fresh LND you enter your 24 words and hand over your latest channel.backup (on plain LND, lncli create --multi_file=channel.backup; on Umbrel, the Lightning Node app restored from your words also finds its automatic backups). Then:

1. Your node rebuilds its on-chain wallet from the words and reads the channel list from the backup.
2. It connects to each peer and says it has lost its channel data.
3. The peer force-closes the channel with its own latest commitment transaction and sends the details your node needs. This step of the protocol is called data loss protection.
4. Once that transaction confirms, your node collects your share. The long wait falls on the side that closed; your share is free within a block (BOLT 3).

What you don’t get back:

• The channels. Every channel in the backup closes. Reopening costs new fees, and the closing fees fall on whichever side opened each channel (LND safety guide).
• Payments in flight at the moment of failure: the backup recovers settled balances only (LND recovery guide).
• Money in channels whose peer never comes back. Recovery needs each peer online and answering, so close channels with peers that stay offline for long; LND calls them zombie channels. Since version 0.19 the file also carries a last-resort force close for this case, but if the channel changed after the copy, publishing it is a breach, so LND says to consult a recovery specialist first (LND recovery guide).
• Channels opened after your last copy. They aren’t in the file. That money depends on the peer closing on its own, and sweeping it then takes a specialist tool such as chantools, from LND’s makers, Lightning Labs. The same tool can build a fresh channel.backup from a copy of channel.db made after the channel opened; the copy itself must never be run.

Moving to New Hardware Is Not a Restore

Restoring from a backup is for emergencies, and two LND nodes must never share a seed, “even if they aren’t running at the same time” (LND safety guide). Phoenix gives the same warning for its app: “Do NOT run two Phoenix apps with the same seed.” LND documents two safe ways to move:

1. Move the whole data folder. Stop LND on the old machine, move its entire data folder to the new one, start it there, and never start the old one again. This is the one time channel.db travels: the live file moving once, not an old copy coming back. It works between machines with the same operating system and kind of processor.
2. Start fresh with the same words. Close every channel on the old node, wait until lncli pendingchannels shows none, shut it down for good, restore your 24 words on the new machine and open new channels.

What Opening and Closing Cost On-Chain

Every channel touches the blockchain at least twice. Fees buy space in a block, measured in virtual bytes (vB), at a fee rate in satoshis per virtual byte (sat/vB); Transaction Fees and Bitcoin’s Security Budget explains how the rate is set. Real transactions from late August 2026, when about 1 sat/vB was enough, each viewable on mempool.space:

• Opening a channel, spending one coin from the wallet and sending the change back (see it): 154 vB, 157 sats.
• A cooperative close, where both sides sign one closing transaction (see it): 192 vB, 196 sats.
• A force close of a 2,000,000-sat channel (see it): 1,210 sats in all.

That force close’s transaction (278 vB, 304 sats in fees) split the channel four ways:

• two anchor outputs of 330 sats, one per side, which its owner can spend to add fees later. Nobody needed them, so 16 blocks later someone swept (collected) both, as the rules allow anyone to do;
• 21,050 sats for the side that didn’t close, free after one block and swept at block 14, counting from the close, for a 124-sat fee;
• 1,977,986 sats for the closer, locked for 240 blocks, about 40 hours, then swept for a 122-sat fee. The other node had set that wait, and 240 blocks is exactly LND’s default for a 2,000,000-sat channel.

Of the 2,000,000 sats, 1,998,790 came back; the other 1,210 went to fees and anchors, about six times what a cooperative close cost that same night.

The Same Transactions at Other Fee Rates

As of November 2026, 1 to 3 sat/vB is usually enough, and in 2025 and 2026 the median fee rate in blocks almost never reached 10 sat/vB. It has been far higher: on busy days in 2024, 20 sat/vB or more was common, and in December 2023 the median passed 300 sat/vB (mempool.space block fee rates). One channel in the August data had been opened in November 2023 at 57 sat/vB, paying 8,778 sats for the same 154 vB; closing it in 2026 cost 195.

Step	Size	At 1 sat/vB	At 20 sat/vB	At 300 sat/vB
Open a channel	about 154 vB	about 150 sats	about 3,100 sats	about 46,000 sats
Cooperative close	about 192 vB	about 190 sats	about 3,800 sats	about 58,000 sats
Force close: closing transaction plus sweeping the closer’s share	about 410 vB	about 410 sats	about 8,200 sats	about 123,000 sats

These are costs if each transaction must confirm at that rate. A force close also leaves 660 sats in anchors, and each payment in flight adds one or two transactions.

Why Force Closes Cost More, and Who Pays

• More transactions: the closing transaction, a sweep of each side’s share, and more for each payment in flight, against one transaction for a cooperative close.
• A fee chosen in advance. The closing transaction was signed during normal use, at a fee set by whichever side opened the channel. When that side is LND, on channels with anchor outputs it keeps the fee at 10 sat/vB or less by default (max-commit-fee-rate-anchors). With no payments in flight, LND doesn’t hurry: it leaves the anchors alone and sweeps your share with a target of about a week, 1,008 blocks (LND sweeper guide). In a fee spike, such a close costs you time more than sats.
• Payments in flight can’t wait. Each has a deadline, so LND speeds up the closing transaction with child pays for parent (CPFP): a new transaction that spends your anchor and pays enough fee to carry both. For that, LND keeps 10,000 sats per channel, up to 100,000, set aside in its on-chain wallet (LND source).
• The opener pays. The closing transaction’s fee and both anchors come out of the opener’s balance, even when the other side forces the close (BOLT 3).

So close cooperatively whenever your peer is online, and open or close when fees are low if nothing forces you to hurry. Size channels so a close during a fee spike can’t eat them: at 300 sat/vB, a force close whose transactions all had to confirm at that rate would cost over 100,000 sats. Keep some bitcoin on-chain for fee bumps. For Phoenix’s own pricing, Lightning Wallets Compared works through a first deposit.

Check Your Understanding

1. Your LND node has four channels of 400,000 sats each and no watchtower. You’ll switch it off for a three-day trip. What is the risk, and what can you do about it?

Answer

On LND’s defaults, channels under 1,198,372 sats make the peer wait 144 blocks, about a day: that is your whole window. A peer who published an old balance on the first day of your trip could collect it long before you got back. The sure fix is to leave the node running, with your Bitcoin node in sync. A tower added the night before helps only partly: it learns only balances revoked from then on, so older ones stay unguarded. For next time, run the watchtower client from the day you open channels, with a tower on another machine, and check with lncli wtclient stats that backups are going through.

2. Your node’s SSD fails. You have your 24 words, a channel.backup copied last week, and a copy of channel.db a script made last night. You opened one new channel two days ago. What do you restore, and what should you expect?

Answer

Restore the 24 words with the newest channel.backup you have. Last week’s file lacks the new channel; Umbrel’s automatic copy, if you left it on, is updated as your channels change. Never start a node on last night’s channel.db: even one night old, it may hold a revoked balance, which would make your node the cheater. Its one safe use: chantools can build a fresh channel.backup from it, new channel included. Either way, each peer in the backup force-closes and your settled balances return on-chain minus fees; the channels end and payments in flight are lost.

3. Fees have jumped to 300 sat/vB. The peer on your 150,000-sat channel has been offline for a week, so a cooperative close isn’t possible, and no payments are in flight. Should you pay to force-close it quickly?

Answer

No. At 300 sat/vB the table puts a force close at roughly 123,000 sats if every step confirmed at that rate: most of the channel. With no payments in flight nothing is urgent, and LND won’t speed up such a close on its own: its closing transaction would sit at the rate it was signed with until fees fall. So wait for fees to drop and close then. If the peer returns meanwhile, a cooperative close needs a single transaction of about 192 vB.