[Lightning-dev] Trustless Watchtowers

ZmnSCPxj ZmnSCPxj at protonmail.com
Thu Nov 15 08:23:36 UTC 2018


Good morning Conner,



> >
> > > From my bare knowledge of go, it seems data structures and messages so far,
> > > without actual logic, but please inform me if I am incorrect.
> >
> > Much of the server side has been implemented, which accepts encrypted blobs from
> > watchtower clients and stores them. The functionality related to scanning blocks
> > and publishing justice txns has also been implemented, but has not been merged
> > yet. The big remaining task is to integrate the client such that it properly
> > backs up states after receiving revocations from the remote peer.

Is the server in a different repo from lnd?
I suppose I should look at non-c-lightning repos more often.

> >
> > > Note however that watchtowers would require to keep all encrypted blobs that
> > > are keyed to the same partial txid. I.e. watchtowers need to store the pair
> > > in a set with the set looking at the entire txid+blob as the identity of the
> > > object. Otherwise it would be possible, if your watchtower is identified by
> > > your counterparty, for the counterparty to give the commitment transaction's
> > > txid with a randomly-generated blob to your watchtower before it gives the
> > > revocation key to you.
> > > I have described the above problem before here:
> > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html
> > > with an unsatisfactory solution.
> >
> > Indeed, this was great observation! The tower can't be sure which client is
> > uploading the "real" blob either. In light of that, the chosen design uses a
> > two level bucketing structure that maps:
> > <txid[:16]> -> client_pubkey1 : encrypted_blob1
> > -> client_pubkey2 : encrypted_blob2
> > ensuring that different client's can't overwrite each other. Further, the tower
> > will only store one blob for a given txid per client. Upon decryption, the tower
> > would learn that only one of this a valid update (and possibly delete state for
> > the offender).
> >
> > > However, this remains your counterparty best avenue of attack, is to simply
> > > spam your watchtower until it runs out of resources and crashes.
> >
> > The client pubkeys described above are tied to what we've been referring to as a
> > session. In order for a client to facilitate the attack described above, they
> > would have to pay the tower for multiple sessions tied to different ephemeral
> > session keys.
> > A session grants the client the ability to store up to N blobs, where N would be
> > several thousand. Thus, the cost to perform the attack would be many orders of
> > magnitude greater than the cost to back up one channel. In the private tower
> > case, there isn't necessarily payment, though it's more or less assumed that one
> > wouldn't DOS their own tower.
> > In practice, the tower should only ever accept sessions if it can be certain it
> > has the appropriate disk-space to facilitate them, so I don't think
> > there is much
> > risk in the node crashing due to this. Someone could still pay to fill
> > up my tower,
> > but the tower would be compensated appropriately. The tower could also raise
> > it's price point if it detects such behavior.

I understand.
It seems similar to "ticket" system I proposed in that post also.

Somebody (not in summit, it was some paper whose author I forgot, and whose title I also forgot...) gave a good idea of combining paying the watchtower with checking if the watchtower is actually working.
Basically, we simulate a breach, which releases some money to the watchtower.
If the watchtower correctly fixes the breach, then it gets paid.
If not, we retain our money and can find another watchtower.
However, it seems not so compatible with session system...?
You have to pay to get a session key first, and this cannot be recovered if the watchtower turns out to not actually monitor breaches.
(I suppose the session keys could be low cost, since they are effectively just spam prevention, and watchtowers could charge larger for breach recovery, in which case it may be sensible to have both.)

> >
> > > And if the watchtower identifies the user, then this leaks the privacy of the
> > > user to the watchtower, and what would then be the point of encrypted blob?
> >
> > I believe the same session-based, encrypted-blob approach would work eltoo
> > towers as well, if the concern is primarily about the channel partner presuming
> > the valid blob. The general design should be readily able to serve
> > eltoo clients,
> > with some slight modifications to breach detection and justice txn construction.
> > My greater concern with the update-and-replace model is that it leaks timing
> > information about a particular channel to the tower, since the tower must know
> > which prior state needs replacing. So even though it is possible to make eltoo
> > towers constant-space per channel, IMO we're better off storing all prior
> > encrypted blobs to maintain adequate privacy. On private towers, perhaps this
> > privacy/space tradeoff may acceptable, but not sure if the tradeoff makes sense
> > on public towers.

Indeed, replacement here implies that the watchtower can track channels.
With sessions but not replacement, the watchtower knows a single session belongs to a single node, but does not know how many channels the node has.

However, if so, what txid will eltoo watchtowers watch for?
The trigger transaction will have fixed txid, but is constant for the entire channel lifetime (and thus leaks which channel is being watched).
The update transactions will vary their txid because fees are paid by adding more inputs.
An idea I had before was that the result of sighash function would be the key instead of the txid, since under `SIGHASH_NOINPUT` the same result of the sighash function will be used regardless of additional inputs/outputs/fees on update transactions.

Regards,
ZmnSCPxj


More information about the Lightning-dev mailing list