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
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___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
