Margherita Favaretto [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-10-23 to 2018-11-18
💬 Posted a total of 6 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:52:58

- reply

📅 Original date posted:2018-11-18
📝 Original message:
Hello, lightning dev community,
I’m writing to you to share an update of my Master Thesis project (previous
object e-mail: Recovering protocol for Lightning network 11/12/2018),
regarding a recovery mechanism of false positive in the Lightning network.
First of all, I'd like to thank Conner Fromknecht and Alex Bosworth for the
discussion during this week, and ZmnSCPxj for the feedback to my previous
email: all your suggestions were very important to proceed with my work.
Thanks also to Olaoluwa Osuntokun to notify me of the problem with my
email, I'm trying to use another one now. :-)
To recap, the problem I'm focusing on is the recovery of the unspent
bitcoins stuck inside the Lightning Network after a wallet failure (e.g.
lost or corrupted transaction data put into the wallet storage).
The Lightning Network provides higher speeds and confidentiality for
bitcoin transactions, but the absence of the underlying distributed ledger
makes impossible the recovery of unspent transactions through the
traditional cryptographic seed and the BIP32 address derivation.
My solution, named Açai Protocol, aims to use the watchtowers not just for
monitoring the channels, but also as a backup service in order to solve the
problem.
Compared to the solution proposed in the previous e-mail, I've abandoned
the idea to use a public key to encrypt data in the watchtower, and I've
decided to adopt the concepts of txid, hint and blob, to maintain the
privacy and the security of nodes.
For simplicity, I've created a project on Github:
https://github.com/margheritafav/LightningNetworkProject, where you could
find all the details about the Açai Protocol, and also you are welcome to
add your comments and feedback.
<https://github.com/margheritafav/LightningNetworkProject>
margheritafav/LightningNetworkProject
<https://github.com/margheritafav/LightningNetworkProject>
github.com
Contribute to margheritafav/LightningNetworkProject development by creating
an account on GitHub.
I hope that the explanation of the design is clear, otherwise please do not
hesitate to ask clarification.
Any thoughts/feedback would be really appreciated, to proceed in the wisest
way and find a solution that can also cover all the needs of the community.
If you are interested in this research topic, please do not hesitate to
contact me for a possible collaboration at s170065 at student.dtu.dk.
Thank you very much in advance,
Cheers
Margherita
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181117/1e2de273/attachment-0001.html>

2023-06-09 12:52:34

- reply

📅 Original date posted:2018-11-13
📝 Original message:
Hello ZmnSCPxj,
thanks for your e-mail and your feedback, I'll answer your questions in the following points.
In case of a breach while node A is offline, can the Watchtowers do anything?
In my solution, the function of backup is not destinated to substitute the first function of the watchtower, that is monitoring the status channel, but instead, the backup option can be considered as a sort of additional feature.
I haven't merged the two functions yet, but the idea is to collaborate to have watchtowers which can have the function of monitor the channel, so defend A when it is offline, but also the function of backup when A loses the data of past commitments (e.g. software doesn't work properly). So, I'd like to highlight that the two functions are independent.
The reason because I'm using a watchtower is just because I need a full node online 24h, that can guarantee the service.
In my solution, the payment channels are created ad-hoc for the backup mechanism, and in the commitment transaction between the node A and the Watchtower has to be added a new field that contains the current nonce-time and payload.
How does this scheme protect the privacy of a node?
This scheme protects the privacy of the node because the payload contained the information of status channel and nonce-time are encrypted on the public key of A. So the watchtowers cannot decrypt the payload and modify it (e.g. with a higher nonce value as you wrote) since just A has the own private key.
If you refer that another node can personify A and send the payload to a watchtower, this is not possible since the payload has to contain the channel_id between A and the specific watchtower, and this information is not known by the other node of the network. So, A can discover a malicious activity because that channel_id is not correct.
As I've written in the previous point, my work is independence from the function of monitoring the channel when node A is offline, so my project doesn't use the blob data.
I hope to get the question, otherwise, could you explain a little bit more the point, please?
Please note also, that you cannot make a single channel with multiple peers; [...]
As regarding the channel, If A has three watchtowers, it has to have three distinct payment channels. Every watchtower is independence from the others.
If you have any opinions/feedback/suggestions, please do not hesitate to write to me. : -)
Kind regards,
Margherita
________________________________
Da: ZmnSCPxj <ZmnSCPxj at protonmail.com>
Inviato: marted¨¬ 13 novembre 2018 00:33:41
A: Margherita Favaretto
Cc: lightning-dev at lists.linuxfoundation.org
Oggetto: Re: [Lightning-dev] Recovering protocol with watchtowers
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/20181113/6170eec2/attachment-0001.html>

2023-06-09 12:52:33

- reply

📅 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>

2023-06-09 12:51:56

- reply

📅 Original date posted:2018-10-31
📝 Original message:
Good morning dev-lightning community,
Last weekend, I had the opportunity to take part in "LightningHackdayNYC". It was an incredible event, thanks to all organizers, to all speakers and all people available to share all own knowledge.
Discussing with the people of the community, I could define better the problem that I'm focusing on and have some ideas for the solution.
I've created a project on GitHub: https://github.com/margheritafav/LightningNetworkProject , where you could find a draft of my research, and also you are welcome to add your comments and feedback.
To recap, the aim of the project is realizing a recovering protocol for Lightning Network. As someone suggested me in the previous e-mails, Eltoo is already solving this problem in part. With Eltoo, the nodes are able to share the last status of the channel, so if one of the two nodes loses some information, it can simply ask to the other node to share the most recent status. Unfortunately, this mechanism doesn't include the case that the other node doesn't share the last transaction, but instead an older one, more favourable for own balance. My project aims to solve this particular issue and make the protocol more solid to face completely the case of a false positive node.
Idea: The main idea of the design is using the other connected nodes as a back-up of own recent status.
If a node A is connected to a node B and a node C, for each transaction between A and B, A sends an encrypted information, regarding the last commitment transaction with B, to C. For each commitment transaction with C, A sends an encrypted information, regarding the last commitment transaction with C, to B.
In this way, if A loses the last transactions, she may ask the information to the other connected node and update the status.
I think that this idea can solve the current lack in Eltoo and I'm planning to analyze more this solution in the next days. Any thoughts/suggestions are really appreciated to proceed in the wisest way and find a solution that can also cover all your needs. If someone of you is interested in this research, I'm available to share more details about the design of my idea and I'm open to discussion. Moreover, if someone is already working on this research topic, please not hesitate to write me for possible collaborations to work together.
Thank you in advance,
Margherita Favaretto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181031/95a78dac/attachment.html>

2023-06-09 12:51:53

- reply

📅 Original date posted:2018-10-23
📝 Original message:
Dear Lighning-dev group,
I am Margherita Favaretto, a Master student of Cyber Security at the Technical University of Denamark (DTU). I'm currently in San Francisco for one month, to advance with my academic research on Lightning Network by taking part to the networking events that are happening here.
My research is focused on a remediation protocol for Lightning Network double-spend attacks. More in detail, my research wants to mitigate the problem of false positives (e.g. software errors). Today, attacking nodes get excluded from the network, without any distinction between a software bug or an "Eve" malicious node.
The solution, that I'm calling a "trusted remediation" gossip protocol, wants to solve: the identification of a false positive; the communication to other nodes; and the remediation payments mechanism. I would really appreciate an open feedback about the relevance of this issue, and which is the best way to be in contact with you.
Your help would help me to focus my research on the right issues, and open a discussion about my assumptions and the related work that could help me. The goal is to give my contribution to this project and be actively part of the group as an independent researcher.
Any thoughts/suggestions are really appreciated. I'm available for possible collaborations outside of this scope with people interested on this research topic.
Thank you in advance,
Margherita Favaretto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181023/d3f812f8/attachment.html>

2023-06-09 12:51:53

- reply

2023-06-09 12:51:53

- reply

📅 Original date posted:2018-10-26
📝 Original message:
Good morning,
Thanks for the reply to my email and for the very helpful suggestions.
Eltoo is a very attractive solution and I've already spent the last days studying it.
With the regards of your queries, I’m trying to solve the inadvertent publication of revoked commitment transactions, and a remediation that can avoid the channel termination penalty.
My solution aims to keep the remediation inside the Lightning network, avoiding time and cost of an additional on-chain transaction.
I’m looking forward to finding more into the Eltoo documentation, and the possibilities provided by contingent payments.
Margherita
________________________________
Da: lightning-dev-bounces at lists.linuxfoundation.org <lightning-dev-bounces at lists.linuxfoundation.org> per conto di Alejandro Ranchal Pedrosa <alejandro.ranchal_pedrosa at etu.upmc.fr>
Inviato: mercoledì 24 ottobre 2018 10:37:36
A: lightning-dev at lists.linuxfoundation.org
Oggetto: Re: [Lightning-dev] The problem of false positives for double spend attacks
Hi Margherita,
can you be a bit more specific about what you mean by double-spend attacks?. A double-spend is not an attack that can be performed acting solely on the Lightning Network, and as far as I know there are no nodes being banned because of this.
If there are nodes that are being banned for tampering or sending wrong information on the p2p Lightning Network (such as changing channel_announcements or creating others that are wrong) is something I am not completely sure (maybe in some implementations? or is it specified in BOLT). In any case, this is not a double-spending attack.
Best,
Alejandro.
On 24/10/2018 00:18, Margherita Favaretto wrote:
Dear Lighning-dev group,
I am Margherita Favaretto, a Master student of Cyber Security at the Technical University of Denamark (DTU). I'm currently in San Francisco for one month, to advance with my academic research on Lightning Network by taking part to the networking events that are happening here.
My research is focused on a remediation protocol for Lightning Network double-spend attacks. More in detail, my research wants to mitigate the problem of false positives (e.g. software errors). Today, attacking nodes get excluded from the network, without any distinction between a software bug or an "Eve" malicious node.
The solution, that I'm calling a "trusted remediation" gossip protocol, wants to solve: the identification of a false positive; the communication to other nodes; and the remediation payments mechanism. I would really appreciate an open feedback about the relevance of this issue, and which is the best way to be in contact with you.
Your help would help me to focus my research on the right issues, and open a discussion about my assumptions and the related work that could help me. The goal is to give my contribution to this project and be actively part of the group as an independent researcher.
Any thoughts/suggestions are really appreciated. I'm available for possible collaborations outside of this scope with people interested on this research topic.
Thank you in advance,
Margherita Favaretto
_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org<mailto:Lightning-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181026/182bd40d/attachment.html>