The Lightning Network’s Watchtowers

4 min readMay 23, 2022

Overview

In Lightning payment channels, peers in the channel exchange bilateral asymmetric payment commitment transactions. This is created for each updated channel state and if the channel must be closed unilaterally, the most recent commitment transaction is broadcasted and each peer gets their allotted amount. To disincentivize cheating, for each channel state change, a revocation secret is shared(by the peer sending coins to the other peer) which allows the honest party to claim all funds whenever the other party wants to cheat. This would punish them if they broadcast a previous state that was more beneficial to them.

“The intent of creating a new Commitment Transaction is to invalidate all old Commitment Transactions when updating the new balance with a new Commitment Transaction. Invalidation of old transactions can happen by making an output be a Revocable Sequence Maturity Contract (RSMC). To invalidate a transaction, a superseding transaction will be signed and exchanged by both parties that give all funds to the counterparty in the event an older transaction is incorrectly broadcast. The incorrect broadcast is identified by creating two different Commitment Transactions with the same final balance outputs, however, the payment to oneself is encumbered by an RSMC.”
- The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments

This revocation contract is timelocked such that the peer that initiates the unilateral channel close can only spend the funds when the timelock expires whilst the other peer can spend the funds immediately provided that they see the broadcasted transaction before the timelock expires.

This punishment mechanism poses a problem for any node that stays offline for a long time(past the timelock expiry) as a malicious peer can cheat. Watchtowers play a vital role in this situation.

What are watchtowers?

A watchtower is a third-party Lightning node that is dedicated to monitoring the blockchain and broadcasting justice transactions for their clients when their channel peer tries to cheat by broadcasting a previous channel state as the closing transaction.

How do watchtowers work?

Although there are different implementations of watchtowers such as the one by Lightning labs, the Basis of Lightning Technology (BOLT) is trying to standardize watchtowers as seen in the BOLT13 specification draft.

Watchtowers work in this general method:

The client (Lightning node that wants to use watchtower services) sets up their node and links the watchtower by updating their lnd.conf file according to the implementation they are using.
The watchtower-pubkey is given to the client on registration with the watchtower services which the client uses to connect to the watchtower.
The client then sends a half transaction ID(‘hint’) and a blob of a specific transaction for every commitment transaction during channel update to the watchtower without revealing the full transaction details.
The client also sends a signature that corresponds to their public key to the Watchtower thereby authorizing the server to sign the justice transaction and broadcast on their behalf.
The watchtower then monitors the blockchain for any transaction that corresponds to the hints they got from their clients.
On detection of any previous/ invalid channel state transaction that corresponds to the hint/half transaction ID they have, they use information from the detected transaction ID to decrypt the blob which is a justice transaction. They use the public key provided by the client to sign the justice transaction and then broadcast it to punish the cheating channel peer and recover all channel funds for their client.

“Watchtowers are not custodians of coin. Instead, they are given half of a txid to watch for, and an encrypted blob whose decryption key is the other half of the txid.” — ZmnSCPxj

NB: This is a generalized summary and different implementations of the watchtower service introduce some differences/tweaks to this.

Drawbacks

One feature of watchtowers that might be a drawback is the storage. The hints that are sent by clients are saved in the server’s database and if at any point the database is compromised, data is lost. The watchtower would not be able to carry out its job effectively.
A potential privacy implication of the use of watchtowers is a case where the server can link multiple state updates to the same channel. This is possible if the full details of the transaction(through transaction ID) are known to the watchtower. This means that the watchtower has information on the channel peers, the channel capacity, etc. — way more information that it does not need to have.
It is best to provide “hints”/half of the transaction ID, and an encrypted blob as mentioned above to the watchtower. This way, the watchtower does not know the details of the transaction and thus cannot link channel state updates.

Conclusion

For individuals not using hot wallets but running Lightning nodes and payment channels, it is required that the node be online at all times, as a malicious channel peer might broadcast a previous state as the closing transaction. In any case, where a node needs to be offline for an extended period, Watchtowers act as a third-party monitor to punish the cheat by broadcasting a justice transaction where all the channel funds will be sent to their client. It is advisable to use multiple watchtower services so as not to trust just one watchtower entirely.

References

Feel free to share your thoughts with me here or reach out to me on Twitter

The Lightning Network’s Watchtowers

Overview

Written by Jennifer Ezeobi