Re: [Lightning-dev] The problem of false positives for double spend attacks

[Margherita Favaretto]

Good morning,


Thanks for the reply to my email and for the very helpful suggestions.

Eltoo is a very attractive solution and I've already spent the last days 
studying it.


With the regards of your queries, I’m trying to solve the inadvertent 
publication of revoked commitment transactions, and a remediation that can 
avoid the channel termination penalty.

My solution aims to keep the remediation inside the Lightning network, avoiding 
time and cost of an additional on-chain transaction.

I’m looking forward to finding more into the Eltoo documentation, and the 
possibilities provided by contingent payments.


Margherita


Da: lightning-dev-boun...@lists.linuxfoundation.org 
 per conto di Alejandro 
Ranchal Pedrosa 
Inviato: mercoledì 24 ottobre 2018 10:37:36
A: lightning-dev@lists.linuxfoundation.org
Oggetto: Re: [Lightning-dev] The problem of false positives for double spend 
attacks


Hi Margherita,


can you be a bit more specific about what you mean by double-spend attacks?. A 
double-spend is not an attack that can be performed acting solely on the 
Lightning Network, and as far as I know there are no nodes being banned because 
of this.


If there are nodes that are being banned for tampering or sending wrong 
information on the p2p Lightning Network (such as changing 
channel_announcements or creating others that are wrong) is something I am not 
completely sure (maybe in some implementations? or is it specified in BOLT). In 
any case, this is not a double-spending attack.


Best,


Alejandro.


On 24/10/2018 00:18, 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

___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] The problem of false positives for double spend attacks

[Alejandro Ranchal Pedrosa]

Hi Margherita,


can you be a bit more specific about what you mean by double-spend 
attacks?. A double-spend is not an attack that can be performed acting 
solely on the Lightning Network, and as far as I know there are no nodes 
being banned because of this.



If there are nodes that are being banned for tampering or sending wrong 
information on the p2p Lightning Network (such as changing 
channel_announcements or creating others that are wrong) is something I 
am not completely sure (maybe in some implementations? or is it 
specified in BOLT). In any case, this is not a double-spending attack.



Best,


Alejandro.


On 24/10/2018 00:18, 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 wantsto 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
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] The problem of false positives for double spend attacks

[ZmnSCPxj via Lightning-dev]

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