Peter R. Rizun, Chief Scientist at Bitcoin Unlimited, is receiving significant publicity (c.f. also) for identifying the flaw in Lightning Networks (LN) that it will be unable to securely process transactions that are less than the on-chain transaction fees.

I wrote in a comment on Peter’s blog:

Peter, thanks for popularizing my long-standing criticism of LN. For example, on Feb 9 (a month before you wrote this blog), I wrote in my blog “Lightning Network must FAIL, if it succeeds”:

The problem remember from the prior section is that whatever block size (or more generally speaking, the on-chain transaction capacity limit) chosen, it must be immutable else as I explained in the prior section, the Nash Equilibrium that gives Bitcoin its value is lost. Eventually the chosen immutable block size (aka on-chain transaction capacity limit) will be exceeded by on-chain transaction demand and incessantly drive transaction fees higher until eventually transaction fees will be too high for most people to even afford to issue a transaction to open and close a channel on-chain. The transaction fee will greater than their Bitcoin balance.

Note I have refuted the “Probabilistic Payments” proposal. And I refuted Gregory Maxwell’s claim that the game theory disincentivizes the thefts.

Here is the content of above mentioned “Probabilistic Payments” refutation:

Probabilistic payments won’t work for the same math reason that non-pooled mining doesn’t work— variance. Users could be waiting weeks, months, and eventually years to ever get paid anything. Especially given BTC is going to $1 million within 4 years. Peter Rizun is repeating a long-standing criticism I have made against LN.

To unpack that more, note that if ratio of the LN payment amount to the minimum on-chain transaction fee becomes very large (e.g. 10,000+) then the variance in terms of number of payments required before the payee receives anything can be quite high.

Also here’s the content of the refutation of Gregory Maxwell:

and an attaker would have to burn quite a bit more in fees to trigger it

Incorrect. The losing routing party also loses more on-chain fees than the value of the micropayment lost if they decide to close the channel. Also given the need for channel liquidity, the little guys just have to eat these thefts as a cost of being accepted to channel with a Mt. Box node. Given the microtxn is hidden in the fee, there’s no way to even objectively prove malfeasance.

Essentially AFAICS there’s no incentives compatibility at all for transactions valued at less than (or even slightly greater than) the on-chain transaction fees involved with opening and closing the channel. Because neither counterparty to the channel has an incentive to lose those fees (to penalize their counterparty for malfeasance) and incur more fees to open a replacement channel.

To unpack that more, the attacker has to spend fees to open a channel on-chain. Ditto the counterparty to the channel. If the attacker doesn’t credit funds that were hidden in the fee, both the attacker and the counterparty would lose a larger amount than the theft if their channel is closed on-chain. So neither have an incentive to close the channel. Also the counterparty to a Mt. Box node needs the liquidity of that Mt. Box node, so will not gain anything and will actually lose more by attempting to penalize the attacker.