ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-24 📝 Original message: Good morning Margherita, ...
📅 Original date posted:2018-10-24
📝 Original message:
Good morning Margherita,
There are no possible double-spend attacks on Lightning Network.
You cannot double-spend your funds unless the other end of the channel agrees to the double-spending. And what will happen is that the other end of the channel will in fact effectively lose money. Assuming the other end is rational and has no interest in helping you, they would not agree to a double-spend. If they are rational and are interested in helping you, they will ask for a invoice and give you the money using existing invoice-payment mechanisms.
So, please consider to focus on other things, like an atomic multipath protocol that supports contingent payment (pay for secret) protocol, or trustless watchtowers. Or do you refer to publication of revoked commitment transactions?
Further, the "trusted" in "trusted remediation" is a severe negative and is unlikely to be accepted.
If the problem you are trying to solve, is the inadvertent publication of revoked commitment transactions, then the correct solution is not to have revocable transactions in the first place, i.e. eltoo. While it can be argued that it would take time for needed features of eltoo to appear on the blockchain layer (SIGHASH_NOINPUT_UNSAFE), it would also take time to implement "trusted remediation", by which time the problem could be solved by switching over to eltoo.
Sincerely,
AmkG
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, October 24, 2018 6:18 AM, Margherita Favaretto <s170065 at student.dtu.dk> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181024/0f701dd5/attachment.html>;
📝 Original message:
Good morning Margherita,
There are no possible double-spend attacks on Lightning Network.
You cannot double-spend your funds unless the other end of the channel agrees to the double-spending. And what will happen is that the other end of the channel will in fact effectively lose money. Assuming the other end is rational and has no interest in helping you, they would not agree to a double-spend. If they are rational and are interested in helping you, they will ask for a invoice and give you the money using existing invoice-payment mechanisms.
So, please consider to focus on other things, like an atomic multipath protocol that supports contingent payment (pay for secret) protocol, or trustless watchtowers. Or do you refer to publication of revoked commitment transactions?
Further, the "trusted" in "trusted remediation" is a severe negative and is unlikely to be accepted.
If the problem you are trying to solve, is the inadvertent publication of revoked commitment transactions, then the correct solution is not to have revocable transactions in the first place, i.e. eltoo. While it can be argued that it would take time for needed features of eltoo to appear on the blockchain layer (SIGHASH_NOINPUT_UNSAFE), it would also take time to implement "trusted remediation", by which time the problem could be solved by switching over to eltoo.
Sincerely,
AmkG
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, October 24, 2018 6:18 AM, Margherita Favaretto <s170065 at student.dtu.dk> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181024/0f701dd5/attachment.html>;