Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-23 Thread Rusty Russell
Conner Fromknecht writes: > In light of this, and if I'm following along, it seems our hand is forced in > splicing via a single on-chain transaction. In my book, this is preferable > anyway. I'd much rather push complexity off-chain than having to do a > mutli-stage splicing pipeline. Agreed. A

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

2018-10-23 Thread 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. Assumi

[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 happenin

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 t