[Lightning-dev] Recovering protocol with watchtowers

[ZmnSCPxj]

Good morning Margherita,

How does this scheme protect privacy of node?
I would at least suggest that the pubkey used be different from the node normal pubkey.

If I find out the pubkey of A, can I spoof A and give a higher nonce value with a blob containing random data (which is indistinguishable from a properly-implemented ciphertext) to the watchtowers of A?  Presumably part of the protocol will require that any updates be signed using the key of A, otherwise I can easily corrupt the data being backed up for A.

In case of a breach while node A is offline, can the Watchtowers do anything?
Please note, that main purpose of Watchtowers is to handle breaches while client is offline, not backup.
It would be pointless for Watchtower to exist if it can only provide data while A is online.
The best time to attack A is when A is unable to defend itself.
Please refer to https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001196.html for information on what we consider the best design for watchtowers so far.

Please note also, that you cannot make a single channel with multiple peers; you must make a channel for each peer.
(well it is theoretically possible, with eltoo, to make multi-party channel. but it requires all members to be online at every update, such that if a single party is offline, the channel is unuseable; having multiple 2-party channels with each peer is far better since if one of your peers drops, you can use the channels with other peers)

Regards,
ZmnSCPxj

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, November 13, 2018 2:59 AM, Margherita Favaretto <s170065 at student.dtu.dk> wrote:

> Hello, dev-lightning community,
> I’m writing to you to share an update of my Thesis project (previous object e-mail: Recovering protocol for Lightning network 11/01/2018).
> I warn you that this message is quite long, but I hope that could be interesting for you, and then it would be great receiving your opinions. :-)
>
> The problem that I'm focusing on is the recovering mechanism of false positive in the Lightning network, that it is possible to re-define as how it is possible to have a solution of backup in the network in case of false positive nodes, with a particular attention to privacy and security.
> First of all, compared to the solution proposed in the previous e-mail, I've decided not to use the other connected nodes as the back-up of recent status, but using Watchtowers. In fact, the problem of using a normal node is that it might be offline, and so it could not guarantee the service of backup.
> In my design, I consider a watchtower simply as a full node that is online 24h, but I have not considered the mechanism of monitoring status channel (maybe we can overlap the two functions later).
>
> An example is that in the near future, the main e-commerce organizations may offer a new service of "Watchtower- Recovery", that the nodes can purchase to back up their commitments data. This means that the user can leverage a payment channel with the watchtower offering the service.
>
> This feature strongly suggests using more than one watchtower, to mitigate the risk that a single watchtower is attacked and all data inside are deleted.
>
> In my solution, I define two new concepts:
> - nonce-time Tn, as the current value of nonce-time (sequential integer number that defines the order   of the backups)
> - payload P, that consists of
>   1.a zip of all status channels of a node A at a specific time T1
>   2. the nonce time corresponds to the time T1 of the status contained in the zip
>   3. channel_id of the channel with A
> This payload is encrypted by the public key of the node A, so the watchtowers cannot know the status channel of A. -> {zip(T1), T1, channel_id} pk(A)
>
> The idea is not sent all data to all watchtowers, but just send the actual nonce-time and the actual payload to one of the watchtower, and just send the new nonce-time to the others. Therefore, we can split the data into different watchtowers, without sending the payload after each transaction to all of them.
>
> To explain the design, let's consider Alice, which has a channel (with Eltoo protocol) with Bob, Charlie, Diana, and three watchtowers W0, W1 and W2. Everytime that Alice is online, she is connected to the three watchtowers.
>
> How to send data to the watchtowers
>
> Alice and Bob change their status channel. So, Alice sends the new status to the watchtowers W0 and shares the current nonce-time with W1 and W2. When Alice sends her information to the three watchtowers, these memorize the node, current nonce-time, payload:
>
> W0: A T0 P0
> W1: A T0   -
> W2: A T0   -
>
> Alice and Charlie change the status of their channel. So, Alice sends the new status to W1 and sends the new nonce-time to the others, which substitute the previous current nonce-time in the information of A:
>
> W0: A T1 P0
> W1: A T1 P1
> W2: A T1  -
>
> Alice and Diana change the status of their channel. So, Alice sends the new status to W2 and sends the new nonce-time to the others:
>
> W0: A T2 P0
> W1: A T2 P1
> W2: A T2 P2
>
> Alice and Charlie change again the status of the channel. So, Alice sends the new status to W1 and upgrade the nonce in the others:
> W0: A T3 P3
> W1: A T3 P1
> W2: A T3 P2
>
> How to request back up to the watchtowers
>
> When Alice needs to have the backup of all her data, she has to ask all her watchtowers the information connected to her node. For example, taking the last example above:
>
> W0 sends {A, T3, P3} to A
> W1 sends {A, T3, P1} to A
> W2 sends {A, T3, P2} to A
>
> Alice analyzes the information sent by W2, she notices that the payload contains the nonce T2, whereas the new nonce-time is T3. Then, she notices that the payload sent by W1 corresponds to T1, but the nonce is T3. When Alice analyzes the information sent by W0, she can analyze that the Payload corresponds to T3, that is also the last nonce-time. So Alice knows her last status.
>
> Security
>
> Since all the watchtowers store the current time-nonce and the payload is encrypted with the public key of A, we can mitigate the following risks:
> - a watchtower sends an older payload instead of the last one. The payload has to contain the current time-nonce to be considered the last one, each payload with a nonce time older are not considered.
> - if the watchtower W0 with the last payload P3, sends P0 and you know that the current nonce time is T3, it is possible to discover the malicious activity. If W1 has the payload P1, the W2 has the payload P2 and the current nonce-time is T3, I could conclude that W0 contains P3 and is cheating.
> -If one of the watchtowers, W3 decides to change the nonce-time, for example from T3 to T5 and send to A T5 with the payload. Alice can think that the actual time-nonce is T5, but no one of the watchtowers contains a payload corresponding to the state T5. This sort of misbehaviour is solved from the majority, e.g. if 2/3 nodes confirm that the actual nonce-time is T3, Alice considers this last nonce-time as the last one and not T5. The attack can happen just If the 51% of the watchtower agree to cheat and send to Alice another nonce-time.
>
> Fee
>
> Every time that the node A requests data to the watchtower for the backup, she sends it a small fee through the Lightning channel. This money encourages the watchtowers to guarantee the service every time.
>
> This one is a simple draft of my design, If you have any feedback/suggestions, please do not hesitate to contact me, even a short feedback would be very helpful! :-)
> In more details, I'd like to know does it make sense to overlap the concept of watchtower with the mechanism of backup?
>
> Thank you very much in advance,
>
> Cheers
> Margherita
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181112/a2259961/attachment-0001.html>