<p>I was intrigued by your question and tried to figure out whether any trustless solutions have been proposed.</p>
<p>I found a [Lightning-dev] mailing list thread positing a <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001233.html" rel="nofollow noreferrer">rough idea by ZmnSCPxj</a>. Z-man drafts a scheme in which the watchtower payload is encrypted to the message signed in the witness program of the <em>trigger</em> 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 <a href="https://blockstream.com/eltoo.pdf" rel="nofollow noreferrer">Eltoo paper section 4.2</a>). While the attacker could modify their own signature on the trigger transaction by re-signing with a new <code>r</code> 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. <strong>Under this scheme, the watchtower would not have the trigger transaction and thus would be unable to initiate unilateral closing.</strong></p>
<p>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.</p>
<p>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.</p>

CC BY-SA 4.0
2022-01-09T23:28:07.117Z
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.
Vojtěch Strnad
CC BY-SA 4.0
2022-01-10T19:59:11.363Z
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
CC BY-SA 4.0
2022-01-10T20:02:59.770Z
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
CC BY-SA 4.0
2022-01-11T04:17:28.510Z
I believe your answer will be very helpful to people trying to understand eltoo. Thanks a lot!
Vojtěch Strnad
CC BY-SA 4.0
2022-01-08T16:52:58.107Z
2022-01-10T20:01:28.427Z
2022-01-10T20:01:28.427Z
Murch
<p>The way Lightning Network works now, watchtowers maintain a list of <em>penalty transactions</em> 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.</p>
<p>With eltoo, watchtowers instead need to store the most recent <em>update transaction</em> 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?</p>

<lightning-network><ln-closing-channels><eltoo><watchtower>
Does eltoo require trusting watchtowers not to close channels?
Vojtěch Strnad
# Does eltoo require trusting watchtowers not to close channels?

(Asked by: username_0 on 2021-11-16)

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?

**Tags:** lightning-network, ln-closing-channels, eltoo, watchtower


---

## 1 answers

### Answer by username_1 on 2022-01-08. Score: 7 | Accepted answer

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](https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-May/001233.html). 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](https://blockstream.com/eltoo.pdf)). 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.

> **Comments:**
> **username_0**: 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.  
> **username_1**: 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.  
> **username_1**: 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.  
> **username_0**: I believe your answer will be very helpful to people trying to understand eltoo. Thanks a lot!  

---

