[Lightning-dev] Recovering protocol for Lightning network

Johan Torås Halseth johanth at gmail.com
Thu Nov 1 10:26:09 UTC 2018

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.


On Thu, Nov 1, 2018 at 12:59 AM Margherita Favaretto <s170065 at student.dtu.dk>

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

More information about the Lightning-dev mailing list