📅 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>;
Johan Torås Halseth [ARCHIVE] /
npub1pp…hs2fw
2023-06-09 12:52:00
in reply to nevent1q…vqu0
Author Public Key
npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fwPublished at
2023-06-09 12:52:00Event JSON
{
"id": "9658f670e3016a53617d76d11b44372a90bcf179d00c5ee06d846e3066838719",
"pubkey": "0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f",
"created_at": 1686315120,
"kind": 1,
"tags": [
[
"e",
"a75f66839ec203951f2aaba4229ae9a7799bb02f8a7ec9686688afc6b75d99a0",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2018-11-01\n📝 Original message:\nHi, Margherita,\n\nIf you haven't already, look into \"data loss protection\" as defined in the\nBOLTs. It is similar to to what you are suggesting, with A being able to\ntell B that it lost state for the A\u003c-\u003eB channel, and if B is cooperative it\nwill help A recover its funds.\n\nYou can also look into watchtowers, and static and dynamic channel backups,\nas they touch onto what you are describing.\n\nCheers,\nJohan\n\nOn Thu, Nov 1, 2018 at 12:59 AM Margherita Favaretto \u003cs170065 at student.dtu.dk\u003e\nwrote:\n\n\u003e Good morning dev-lightning community,\n\u003e\n\u003e Last weekend, I had the opportunity to take part in \"LightningHackdayNYC\".\n\u003e It was an incredible event, thanks to all organizers, to all speakers and\n\u003e all people available to share all own knowledge.\n\u003e Discussing with the people of the community, I could define better the\n\u003e problem that I'm focusing on and have some ideas for the solution.\n\u003e I've created a project on GitHub:\n\u003e https://github.com/margheritafav/LightningNetworkProject , where you\n\u003e could find a draft of my research, and also you are welcome to add your\n\u003e comments and feedback.\n\u003e\n\u003e\n\u003e To recap, the aim of the project is realizing a recovering protocol for\n\u003e Lightning Network. As someone suggested me in the previous e-mails, Eltoo\n\u003e is already solving this problem in part. With Eltoo, the nodes are able to\n\u003e share the last status of the channel, so if one of the two nodes loses some\n\u003e information, it can simply ask to the other node to share the most recent\n\u003e status. Unfortunately, this mechanism doesn't include the case that the\n\u003e other node doesn't share the last transaction, but instead an older one,\n\u003e more favourable for own balance. My project aims to solve this particular\n\u003e issue and make the protocol more solid to face completely the case of a\n\u003e false positive node.\n\u003e\n\u003e Idea: The main idea of the design is using the other connected nodes as a\n\u003e back-up of own recent status.\n\u003e *I**f a node A is connected to a node B and a node C, for each\n\u003e transaction between A and B, A sends an encrypted information, regarding\n\u003e the last commitment transaction with B, to C. For each commitment\n\u003e transaction with C, A sends an encrypted information, regarding the\n\u003e last commitment transaction with C, to B.*\n\u003e In this way, if A loses the last transactions, she may ask the information\n\u003e to the other connected node and update the status.\n\u003e\n\u003e I think that this idea can solve the current lack in Eltoo and I'm\n\u003e planning to analyze more this solution in the next days. Any\n\u003e thoughts/suggestions are really appreciated to proceed in the wisest way\n\u003e and find a solution that can also cover all your needs. If someone of you\n\u003e is interested in this research, I'm available to share more details about\n\u003e the design of my idea and I'm open to discussion. Moreover, if someone is\n\u003e already working on this research topic, please not hesitate to write me for\n\u003e possible collaborations to work together.\n\u003e\n\u003e\n\u003e Thank you in advance,\n\u003e Margherita Favaretto\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181101/0b2b32b3/attachment-0001.html\u003e",
"sig": "730957cc8832cc3e957f206d09105379377f1d790a76b1279093a591669d3e781b1d4b1174b62d9808e3e8e2283d66b274d0b92d7c2fbfbf14551cd148e30e90"
}