Good morning Laolu,
>> However, this has the drawback that each update of a single channel will
>> generate a `(txid[:16], blob)` pair that has the same `txid[:16]` key,
>> letting the WatchTower correlate the timing and number of updates of each of
>> your channels.
>
> On the other hand, going with the "swap this blob" approach is much, much
> more scalable as each client of the watchtower only consumes a bounded
> (could say constant) amount of space. If you pad out the blob to the max
> size accounting for HTLC limits (which further obfuscates the details of the
> update), then watchtowers can easily plan out the storage requirements as a
> function of the number of open clients.
It would also mean that WatchTowers would need to identify their clients, a
further privacy leak. This is because if the WatchTower simply allows "swap
this blob", the attacker can identify the WatchTowers the victim uses, and they
know which txid they will use to attack. They can then give a "swap this blob"
with a blob that cannot be decrypted to a valid blob, disabling the WatchTower.
Perhaps it could be made to work if the WatchTower demands a public key +
signature. If this is the first time the `txid[:16]` is used, then the
WatchTower accepts the public key. For future times (i.e. replacement
requests) the WatchTower checks the signature and public key of the replacement
vs the public key of the first time, and only accepts if the public key matches
and the signature is verified for the public key. But this can still be
attacked: prior to signing the transaction, the attacker determines the txid
that will be monitored by the WatchTower, and before sending the signature to
the victim to start the channel, the attacker gives a `(txid[:16], blob)` with
invalid blob to the WatchTower. The victim receives the signatures, then
creates the proper blob for the first state, and then gives the valid blob to
the WatchTower --- who rejects it, because an existing blob from the attacker
is already reserved to the attacker public key.
This can be prevented if the WatchTower knows a stable identity (possibly
pseudonymous) of the victim and attacker. See:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html
for my ruminations on this topic. In that post, the WatchTower charges for
each `(txid[:16], blob)` pair it stores and monitors, and will store multiple
pairs with the same `txid[:16]` key if they are from different tickets.
Charging for the service reduces DoS attacks, and storing multiple pairs with
the same key prevents key-reservation attacks like the above I described. It
also lets the service be used completely anonymously, without even a
pseudonymous public key. The ticket scheme lets the WatchTower correlate
updates coming from a single ticket, but this is limited since each ticket
purchased has a finite number of uses.
An enhancement to the above would be to restructure things so that WatchTowers
sell ticketbooks of multiple tickets. Each ticket is valid for storing one
`(txid[:16], blob)` pair, and WatchTowers will store multiple `(txid[:16],
blob)` pairs with the same txid. Then the WatchTower can operate as Chaumian
bank on the tickets they sell, so that clients in theory can swap tickets from
the same WatchTower with each other to decorrelate uses of tickets within a
ticketbook.
> In order to mitigate the timing leaks, clients don't need to _immediately_
> update their blob. Instead, they can add a level of randomization via a
> timer drawn from a particular distribution. The downside of this is that
> there's a window of opportunity wherein a new state is at play, yet the
> watch tower hasn't yet been updated. Even with asymmetric commitments, one
> would still want to introduce such randomization in order to de-correlate
> their updates (and also batch several updates into a single message).
>
>> It seems desirable to at least retain the property that the WatchTower
>> cannot correlate our updates to our channels.
>
> Is the scalability tradeoff worth it though?
I think not.
>> since only the latest update transaction is valid
>
> All update transactions are valid, just some are more valid than others ;)
Haha, yes.
>> Under Poon-Dryja, if I have watching service contracts from several
>> WatchTowers, when I get another revocation, I can distribute the revocation
>> data to a subset of all my serving WatchTowers; under
>> Decker-Russell-Osuntokun I would have to contact all of them to give the
>> latest update transaction.
>
> Not necessarily. Due to the nature of the update transactions, several
> watchtowers could even progressively advance the update transaction towards
> the final most up to date state. Your constraint of "i need to update them
> all each time" seems arbitrary and isn't inherent to either of the schemes.
You are right and this is my mistake.
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
