[Lightning-dev] The problem of false positives for double spend attacks
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
Re: [Lightning-dev] Commitment Transaction Format Update Proposals?
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. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
