@sickpig
This. Unless we're willing to go down the rabbithole of convoluted gmax workarounds like freezing timelocks, you can't have Lightning unless you're sure that the necessary transactions can be confirmed within a sufficient time. A successful Lightning Network would increase the incentive to tx spam Bitcoin on a level that we can't even comprehend yet
That could means that LN is exposed to spam attacks in a manner normal transactions are not.
For example if LN was used for a high value payment and the LN receiver only has one day to confirm the transaction, then the LN sender can be motivated to spam the network filling blocks until the nlocktime expires. As has been shown with the spam tests, an attacker for <$1000 can generate enough fee paying transactions to clog the network for a few days.
The reason this is not common, is there is no financial incentive to spam today, the spammer is simply burning money. But an LN motivated race creates a new incentive to spam the network. The LN receiver (if I am understanding this correctly) can not increase fees on the LN transaction in order to give it priority. The LN payer sets the fee in the LN transaction, and after the LN receiver receives and accepts a transaction the LN payer could use spam to make the fee they included too low.
The only real solution to this is to reduce the effectiveness of spam attacks on LN by, wait for it, increasing block sizes. Large block sizes significantly increase the cost of a spam attack, negating it's effectiveness.
Now that I think about it, this is probably why the BS devs are pushing "replace fee" functionality. Replace by fee damages zero-confirm transactions, but enables an LN receiver to increase the fee paid if they need a quick confirmation during a spam attack.
If this line of thinking is accurate, then the BS devs are working to break zero-confirm transactions in order to solve a flaw in LN. That is horrible.
