[Lightning-dev] Trustless WatchTowers?

ZmnSCPxj ZmnSCPxj at protonmail.com
Wed Apr 18 10:16:26 UTC 2018

Good morning list,

A possible problem with the encrypted blob approach came to my mind.

A potential thief, knows the commitment transaction it will attempt to use to steal (obviously).

That potential thief, also knows the commitment transaction ID (obviously).

In the encrypted blob approach, the key is part of the commitment transaction ID.

Now it seems, that if I am a thief, and I wish to steal from (for example) Rusty while he is on vacation, I could identify the WatchTower(s) he is using, and send many (txid[16:], blob) with random blob to that WatchTower(s).

Now if the WatchTower is given a (txid[16:], blob) for a txid[16:] that it already has, but for a different blob, what should it do?

* If it ignores the new txid[16:], then I could send the invalid (txid[16:], blob) to the WatchTower before I send the revocation of the commitment to Rusty; Rusty can only send a valid (txid[16:], blob) after I send the revocation to him, after all.  Then I implcitly prevent the WatchTower from accepting the correct blob from Rusty,
* If it replaces the old txid[16:] and keeps the new pair, I could send txid[16:] to the WatchTower some time after I send the revocation to Rusty, hoping that Rusty behaves "politely" and does not spam the WatchTower repeatedly with its blob after I send my replacement.
* If it stores all the (txid[16:], blob) pairs it receives, then an obvious DoS is to flood the WatchTower with such pairs, preferably distributedly, in the hope of bringing down the WatchTower.

Now the WatchTower cannot know if it is Rusty who has the "right" to provide a given txid[16:], or me, or some other hardware I have "hired" to do my bidding.  This is in fact the whole point of an encrypted blob: the WatchTower only learns about the channels (and indirectly the identity of the counterparties in the channel) if a theft attempt is actually made.  Indeed, Rusty could have used Tor to contact the WatchTower (to obscure further who the WatchTower is protecting, in case the channel does not get stolen) and the WatchTower cannot know if it was actually Rusty or I (and it would leak privacy for the WatchTower to learn for certain who it is protecting, potentially allowing the WatchTower to profile Rusty spending habits).

The (txid[16:], blob) pairs I make in this attack need not have valid blob: either way the WatchTower cannot know, before I publish the entire commitment transaction, which blob came from Rusty correctly and which ones were invalid ones created by me and my army of fellow machines taking over the world.


An obvious solution is for the WatchTower to charge a tiny amount (micropayment, how apt) for each (txid[16:] blob) pairs it keeps.  Then I cannot flood the WatchTower with poisoned blobs without at some point spending more than what I would earn by stealing.

Now Lightning itself is positioned as a micropayment platform, so the obvious logic is that the WatchTower will get paid on-Lightning.  But every successful (and unsuccessful!) payment requires two channel updates, invalidating two commitment transactions and requiring two (txid[16:], blob) pairs that Rusty needs to get to a WatchTower.  Obviously Rusty has to have two WatchTowers, so that he uses one WatchTower to watch the channel of the other WatchTower.  But once Rusty pays to one WatchTower, he now has two (txid[16:], blob) pairs to send to the other WatchTower, which would charge for this service and require a payment.  This emits two new (txid[16:], blob) pairs to send to the first WatchTower, ad infinitum, at least until Rusty runs out of money.

One way to break this loop would be for WatchTowers to provide a "prepaid watching" service,

1.  Rusty contacts two WatchTowers and gets invoices for prepaid watching.
2.  On paying an invoice for prepaid watching, Rusty gets a preimage that serves as a "ticket" (encryption key). The WatchTower who provided that preimage promises to watch up to N txids (with N much greater than 2) when presented using this ticket.  For example let us assume that an invoice for prepaid watching pays for 100 (txid[16:], blob) pairs.
3.  On paying both invoices, Rusty now has two tickets and four (txid[16:], blob) pairs.  Rusty can now put the blobs from one WatchTower to the other WatchTower, using the two tickets, and having 98 more blobs he can use on each ticket for his other Lightning activity.
4.  An obvious rule for the WatchTower to apply would be to require that, at least within a ticket, a txid[16:] cannot be duplicated.  Across tickets, txid[16:] can be duplicated.

The ticket partially obscures the privacy of Rusty: the WatchTower knows that all the blobs within a ticket are from the same node, but cannot correlate across tickets (well if Rusty always uses non-published channels to them, they can identify him easily; obviously he should publish those channels and let others route through them).  Having multiple WatchTowers reduces how much each WatchTower learns about Rusty, and lets Rusty have one WatchTower watch the channel with a different WatchTower.

If I were to try stealing from Rusty, I would need to poison txid[16:] across multiple tickets.  Since within a ticket, txid[16:] cannot be duplicated, I need to buy 1000 tickets to flood the WatchTowers with 1000 invalid (txid[16:],blob).  Of course if I were to try stealing from all 1000 nodes on the mainnet network, I would be able to amortize that, but that would require greater preparation on my part.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180418/bf23b29e/attachment.html>

More information about the Lightning-dev mailing list