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.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
