Does eltoo require trusting watchtowers not to close channels?

Question

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?

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.