The way Lightning Network works now, watchtowers maintain a list of penalty transactions to broadcast in case one party attempts to close a channel with an outdated channel state. The watchtower cannot on its own initiate the closing of a channel.

With eltoo, watchtowers instead need to store the most recent update transaction to override any outdated update transactions that might be published. However, doesn't that mean the watchtower can unilaterally force close a channel by publishing an update transaction?

1 Answer 1


I was intrigued by your question and tried to figure out whether any trustless solutions have been proposed.

I found a [Lightning-dev] mailing list thread positing a rough idea by ZmnSCPxj. Z-man drafts a scheme in which the watchtower payload is encrypted to the message signed in the witness program of the trigger transaction. As a reminder, the trigger transaction initiates the unilateral closing process and is necessary to protect against the funding transaction's refund condition becoming valid prematurely. Hence, the trigger transaction MUST precede publishing of any update transaction (see Eltoo paper section 4.2). While the attacker could modify their own signature on the trigger transaction by re-signing with a new r value, they cannot modify the message digest that was signed without invalidating the counterparty's signature. Thus, the message signed in the trigger transaction is an unconditionally available and immutable datum that can be used to encrypt watchtower payloads. Under this scheme, the watchtower would not have the trigger transaction and thus would be unable to initiate unilateral closing.

Z-man further describes how the watchtower would check whether an older update transaction has been submitted to the network, to evaluate whether its payload is demanded. One downside of the proposed scheme is that the watchtower can correlate all payloads for the same channel once the trigger transaction has been published which allows the watchtower to learn more about the channel's history and activity level in the case of a unilateral close. However, the update transactions are all semantically identical, simply spending the channel funds in a single input to a single output that stages the corresponding settlement transaction which encodes the actual final state of the channel. The update transactions may differ in additional inputs and outputs however.

The proposal only elicited two further messages to the mailing list, and I wasn't able to find more discussion of the concept. I'm not sure whether it is viable and would be actively pursued if/when the Eltoo update mechanism would get rolled out.

  • I didn't notice that the process of closing a channel is not initiated by publishing an update transaciton but with a trigger transaction. And watchtowers don't need to store the trigger transaction, right? It seems you tried to answer much more than what was in the original question. Jan 9 at 23:28
  • Yeah, maybe I went overboard. I actually reread the Eltoo paper almost completely, heh. But yeah, the Watchtower wouldn't have the trigger transaction, because their action would only be necessary when an outdated update transaction had been published. Necessarily, the trigger transaction would have to have preceded an update transaction. In other words, Eltoo watchtowers would not be able to unilaterally initiate a channel closing, but they could publish one or more outdated states if either party initiates unilateral closing.
    – Murch
    Jan 10 at 19:59
  • Well, first I read Z-man's proposal three times, because I didn't grok it. I figured I'd explain my understanding of it while it's fresh so others that try to parse the proposal would get a running start.
    – Murch
    Jan 10 at 20:02
  • I believe your answer will be very helpful to people trying to understand eltoo. Thanks a lot! Jan 11 at 4:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.