[Lightning-dev] Revocations and Watchtowers

[ZmnSCPxj]

Good morning Christian,


> Even with shachain the storage requirements for the nodes (not the
> watchtowers) are far from being constant either: since any old state,
> including anything that we built on top of it (HTLCs), so we need to
> keep information around to react to those as well (preimages that cannot
> be subsumed in a shachain since the HTLC preimage is chosen by many
> remote senders).

Ah, right.
I forgot these.

More specifically, even though the HTLC outputs are revocable with only knowledge of the revocation key, the SCRIPT itself needs to be provided in full, including the payment hashes.

> When it comes to eltoo, just reusing the same watchtower protocol that
> we designed for LN-penalty, with unidentified blobs, randomly inserted
> by anyone, and encrypted with the commitment transaction is likely too
> simplistic, and results in the O(n) requirement you mentioned. My
> proposal would be to establish an authenticated session with a
> watchtower, e.g., by signing all encrypted updates using a session key,
> and the watchtower only replacing updates that match the session. An
> attacker could not replace my updates I stashed with the watchtower
> since it cannot hijack my session. This means that the watchtower can be
> certain that it can discard old states, but still have the correct
> reaction stashed when it needs it.
>
> Notice that this is already what the lnd watchtower protocol pretty much
> does, and it is likely that we'd like a session anyway in order to pay
> the watchtower for its service. I think it's unrealistic to expect
> altruistic watchtowers storing encrypted blobs for some random people
> out there in eternity, without getting compensation for it. To hide the
> activity and timing of our channels we could simply open multiple
> sessions with the watchtower, or spread them across multiple watchtowers.

It seems that even with multiple sessions with a single watchtower, if the watchtower assumes you are not under direct attack (a reasonable assumption), it would still get all the information on all activity on a channel.

Spreading across multiple watchtowers assumes other watchtowers are somehow not sybils of an existing Big Brother watchtower.

> I'd even go further and just add the channel outpoint (or should I call
> it "contract outpoint"?) to the update in cleartext so that the
> watchtower can prune states for closed channels. We can still spread the
> states across multiple watchtowers to hide update rate and timing. So
> this effectively gets us to a O(1) storage space for watchtowers in
> eltoo.

Would this not mean revealing funding outpoints for unpublished channels as well, at least to the watchtower?

It seems to me there is significantly more privacy loss with these kinds of watchtowers.

Before, I proposed to continue using encrypted-blob watchtowers, except rather than triggering on txid[:16], instead trigger on sighash[:16] (so it would work with either Poon-Dryja or Decker-Russell-Osuntokun).
This would work with `SIGHASH_NOINPUT` on the update transactions (by matching the computed sighash for `SIGHASH_NOINBPUT`), letting watchtowers rebuild the entire sequence of updates (by also looking at further matches of sighash[:16]) in case of a breach, but *only* in case of a breach.
With this style, watchtowers cannot know, even within a session, whether a hundred updates you send are for a single channel updating 100 times or for a hundred channels updated once each.

Similarly to Poon-Dryja watchtowers you would send the (sighash[:16], encrypted_blob) pair for an update tx that has just been replaced with a new version.
And if the old update tx is never put onchain, the watchtower never learns about what channel it was watching (unlike the proposed style where the key is the actual channel outpoint, which reveals to the watchtower the channel it was watching).


Of course, I suppose privacy is less important in practice for most users than convenience and low price, sigh.

A privacy-conscious person might run one or more private watchtowers for their nodes, and distribute them physically as much as he or she can.
But there is still the risk that one or more of these are hacked (indeed there is increased risk if they are not within easy physical reach of the owner), and it would be best still if the watchtowers so created have as little practical information to reveal as possible, so I believe my point still stands.


Nonetheless, code talks, so feel free to ignore me here.


Regards,
ZmnSCPxj