📅 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>;
Margherita Favaretto [ARCHIVE] /
npub1f7…dmk0y
2023-06-09 12:51:56
in reply to nevent1q…g3g5
Author Public Key
npub1f7vh4ksven5ymwf3spene5jj6a8dgu52e0z4kaakq9z74mvtlkcsjdmk0ySeen on
wss://relay.nostr.bandPublished at
2023-06-09 12:51:56Event JSON
{
"id": "2f840c346cfe5df08d82156e644663326173cefce9149cbad37f3158c7f00890",
"pubkey": "4f997ada0ccce84db93180733cd252d74ed4728acbc55b77b60145eaed8bfdb1",
"created_at": 1686315116,
"kind": 1,
"tags": [
[
"e",
"78a32d72dcdf53fc7825d2199a7418e154e0b4a7bac55be2436fb720eca822fe",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2018-10-31\n📝 Original message:\nGood morning dev-lightning community,\n\nLast 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.\nDiscussing with the people of the community, I could define better the problem that I'm focusing on and have some ideas for the solution.\nI'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.\n\n\nTo 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.\n\nIdea: The main idea of the design is using the other connected nodes as a back-up of own recent status.\nIf 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.\nIn this way, if A loses the last transactions, she may ask the information to the other connected node and update the status.\n\nI 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.\n\n\nThank you in advance,\nMargherita Favaretto\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181031/95a78dac/attachment.html\u003e",
"sig": "35ef99f99f34b0a896c989006b939ed785ee2b4a4f6fc5da3fa37c2dba884fda9eee25d17547196beb967d5241f513910fd5615f59796a861c03488098e1c10c"
}