Margherita Favaretto [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-12 📝 Original message: Hello, dev-lightning ...

📅 Original date posted:2018-11-12
📝 Original message:
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/5b5e5313/attachment-0001.html>;