Johan Torås Halseth [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-01 📝 Original message: Hi, Margherita, If you ...
📅 Original date posted:2018-11-01
📝 Original message:
Hi, Margherita,
If you haven't already, look into "data loss protection" as defined in the
BOLTs. It is similar to to what you are suggesting, with A being able to
tell B that it lost state for the A<->B channel, and if B is cooperative it
will help A recover its funds.
You can also look into watchtowers, and static and dynamic channel backups,
as they touch onto what you are describing.
Cheers,
Johan
On Thu, Nov 1, 2018 at 12:59 AM Margherita Favaretto <s170065 at student.dtu.dk>
wrote:
> 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.
> *I**f 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
> _______________________________________________
> Lightning-dev mailing list
> 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/20181101/0b2b32b3/attachment-0001.html>;
📝 Original message:
Hi, Margherita,
If you haven't already, look into "data loss protection" as defined in the
BOLTs. It is similar to to what you are suggesting, with A being able to
tell B that it lost state for the A<->B channel, and if B is cooperative it
will help A recover its funds.
You can also look into watchtowers, and static and dynamic channel backups,
as they touch onto what you are describing.
Cheers,
Johan
On Thu, Nov 1, 2018 at 12:59 AM Margherita Favaretto <s170065 at student.dtu.dk>
wrote:
> 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.
> *I**f 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
> _______________________________________________
> Lightning-dev mailing list
> 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/20181101/0b2b32b3/attachment-0001.html>;