A Lightning Watchtower monitors the Bitcoin chain on behalf of a payment-channel user. If the peer publishes a revoked state, it can broadcast a prepared recovery transaction. This helps protect funds while the user's node is offline, but depends on correct data, connectivity and timely confirmation. A node is the software that manages channels and processes Lightning payments; while offline, it cannot communicate with the other participants.
Anna and Pavel have a payment channel: funds are locked together in Bitcoin, and Lightning payments change how those funds are divided. Pavel pays Anna, both agree to the new balances and revoke the old state. Then Anna loses her internet connection. If Pavel published the old state, he could try to reclaim money he had already spent. Anna can arrange for a Lightning Watchtower to cover this situation. Her node sends it encrypted information beforehand to protect revoked states. When the service recognizes the corresponding transaction on the chain, it can broadcast a recovery transaction without Anna being online. It does not make payments for her or fix her disconnected node. [1] [8]
Each agreed division of funds has a commitment transaction: a signed transaction that can close the channel on the Bitcoin chain. During an update, the participants exchange information that makes publishing the previous, revoked state punishable. This article describes that penalty-based channel design. If Pavel uses the current valid state, he is allowed to close the channel unilaterally while Anna is offline. A Watchtower is not meant to block that closure. It acts against a specific revoked state, whether Pavel published it deliberately or accidentally from an old backup. Revocation matters, not the transaction's age. [1] [8]
A Seed Phrase is a backup written as words, used to recover the private keys needed to sign payments. LND is one of the programs used to run a Lightning node. Anna does not give the service her Seed Phrase or the private keys to her entire wallet. She supplies limited information and signatures for a particular response; LND calls this package a JusticeKit. The recovery transaction, known as a justice transaction, returns protected funds under conditions prepared in advance. This does not give the Watchtower freedom to spend Anna's other coins. Under the model with no tower reward, the Bitcoin transaction fee is deducted from the protected amount. The code also supports types with a tower reward, but that alone does not mean a particular operator offers a paid service. [3] [4] [5]
The Watchtower needs to actually receive the information before it can help. Entering its address in settings or seeing a task queued for upload is not enough. The client, the part of Anna's node that communicates with the tower, needs acknowledgements of received updates. Connectivity can fail, a storage agreement called a session can run out of capacity, or a backup can be rejected. Anna therefore needs to monitor undelivered updates and errors too. Even accepted data does not guarantee success: the tower must keep following the correct chain and get its response confirmed in a block in time. [6] [8]
If Anna loses her device, the Watchtower is not where she restores it from. The service watches for misuse of revoked states; it does not restore her wallet or rescue stolen keys. LND uses a Static Channel Backup (SCB) for channel recovery. Together with the wallet seed, it helps recover funds by closing channels, rather than resuming exactly where the node left off. An SCB is neither a copy of every update nor the encrypted package sent to a tower. Starting an old channel.db database without the proper recovery procedure is particularly dangerous: the node could publish its own revoked state. Follow the backup instructions for your particular wallet and version. [7]
A transaction output specifies an amount and the conditions for spending it. The protection works because someone publishing their channel state cannot immediately spend their delayed output. BOLT 3 calls that output to_local and the waiting period to_self_delay. CSV is the rule that measures this delay in blocks from the output's confirmation. The other participant can use the penalty path with the proper revocation key without that wait. This gives the Watchtower a head start to respond. When the delay ends, the penalty path does not disappear, but the peer can now spend the funds too. The outcome depends on which conflicting spend confirms validly. Merely broadcasting the recovery transaction is not enough, and a block count is not an exact number of hours. [1] [9]
Before choosing a service, establish what it actually protects. HTLCs are conditional payments that may still be pending in a channel; monitoring balances does not establish coverage for those payments. Dust here means an output too small to be included in the particular transaction. The verified backupTask in LND v0.21.3-beta prepares existing non-dust to_local and to_remote outputs of the revoked commitment. It does not provide general protection of all HTLC outputs; the relevant documentation describes that as a future extension. Bitcoin Script is the language used to express an output’s spending conditions. Being able to spend an output through a penalty path does not mean that a particular tower has received the required data or can carry out that protection. [3] [5]
The encrypted package does not require the tower to continuously read all of Anna's balances. It uses a short identifier to look for a match and information from the transaction it recognizes to decrypt the data. The following is a technical reference for a specific LND version; txid means transaction identifier and blob means a package of data. In LND v0.21.3-beta, BreachHint is the first 16 bytes of SHA-256 of the binary txid. BreachKey is SHA-256 of the same binary txid concatenated with itself. This is neither the first 16 characters of a displayed txid nor its plain first half. The client encrypts a JusticeKit; knowledge of the matching transaction allows derivation of the key and decryption of the data. [2] [3]
Running a tower for others and having your own channels watched are different tasks. These settings are for LND operators; RPC is the interface through which the program receives commands. LND separates watchtower.active for the server from wtclient.active for the client. Enabling a server alone does not arrange backups of your own channels at another tower. lncli tower info shows the server’s pubkey, listeners and uris; lncli wtclient add registers a tower for the client. The tower’s public key differs from the Lightning node key. Check the network, address reachability and RPC support in the build being used. [5]
A response has to pay for space in a Bitcoin block. A satoshi is the smallest unit of bitcoin. A virtual byte measures transaction size while accounting for the different weights of its components. The rate is satoshis per virtual byte of transaction size, not a percentage of the protected funds. In LND v0.21.3-beta, policy and session field sweep_sat_per_vbyte gives the fee rate in sat/vB. The fee reduces the returned amount. backupTask may reject a state with too little value or unsuitable session parameters; not every prepared task is an eligible backup. A later configuration change is no proof of changes to previously signed transactions, and an insufficient rate may delay the response. [3] [6]
A second tower can help when the first fails only if it has received the necessary data itself. Independence includes connectivity and operators, not just different service names. Multiple independent towers and self-monitoring can reduce the impact of one outage. Check which specific updates each tower has received, however; several registered addresses alone do not establish replication of every state. Separate machines, networks and locations reduce shared failures. Encrypted blobs and authenticated connections limit balance visibility, but do not eliminate metadata, update-frequency exposure or correlation risk. [5] [8]
When checking protection, distinguish an update sent from an update actually received. These commands and field names are a more detailed reference for LND administrators; a tower acknowledging a backup is not a transaction confirming in a block. Use lncli wtclient towers, lncli wtclient tower, lncli wtclient stats and lncli wtclient policy. In LND v0.21.3-beta, distinguish num_backups from num_pending_backups; the latter counts backups awaiting acknowledgment by the tower. num_failed_backups in the stats response counts unsuccessful unacknowledged backups. Statistics cover the period since client startup. active_session_candidate identifies a candidate for sessions, not proof of complete protection. [6]
Correct configuration is a starting point. A test should cover the sequence from recognizing a revoked state to recovering the protected funds; do not attempt this with your real money. Check the specific client and tower releases, supported channel and session types, data freshness, fees and chain synchronization. Test response behavior in an isolated test environment; an ordinary unilateral closure (force close) does not demonstrate a response to a revoked state. Evidence of the result consists of the publication of the revoked state (breach), reconstructed justice transaction and its confirmed outputs. A successful demonstration guarantees neither future availability nor removal of every Lightning risk. [1] [3] [6]
For the clearest picture, read this entry together with Lightning Network, Payment Channel, Self-custody. The reverse links also lead from Payment Channel.