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

2018-10-23 Thread Margherita Favaretto
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 

Thank you in advance,

Margherita Favaretto

Lightning-dev mailing list

Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

2018-10-23 Thread Rusty Russell
Jim Posen  writes:
> Instead of leaving an extra output for CPFP, is it not sufficient to just
> sign all inputs with ANYONECANPAY and expect the sender to make an exact
> output for the fees input? It would require an extra tx assuming they don't
> already have a properly sized UTXO handy (which they may!), but I believe
> CPFP would require that as well. Am I missing something?

Yeah, that would change the txid which the HTLC txs rely on :(

> I'm a fan of the symmetric delays because it simplifies the game theory
> analysis, but I don't think the delays need to be the same for both
> participants (max of `to_self_delay` for both sides), just that the delay
> is applied equally regardless of who publishes the commitment tx. Like your
> `to_self_delay` can be what I specify and vice versa, what's the reason for
> taking the max?

If you don't take the max, you're back into the Game Theory.  Your delay
is short, mine is long, so I want you to drop to chain please.

Also, there's a fairness argument: if you want me to suffer a long
delay, you should too.

Lightning-dev mailing list