A Fast, Scalable Protocol For Resolving Lightning Payments

[JohnLaw]

@harding

I think OPR needs some sort of unconditional fees to work.

In the current LN protocol, the party that creates a payment only pays forwarding fees if the payment is successful. Unsuccessful payments, and HTLCs designed to fail (called probes), cost their creator nothing.

However, if that model was adopted by OPR, then Mallory could send a constant stream of probes through Bob to random endpoints. Each of those endpoints would fail the probes (because they wouldn’t know the payment preimage) in the normal case, but it would occasionally be the case that there would be a problem downstream and a penalty payment would propagate back to Mallory.

I’m afraid I’m not following you here. What do you mean by a “penalty payment”?

Do you mean the case where Bob does not get the hash preimage but Bob fails to provide a timely update_fail_htlc message? In this case, the HTLC fails with the OPR protocol (even though Bob didn’t explicitly fail it quickly).

As long as Bob eventually realizes that he failed to resolve the HTLC by its expiry, he will realize that the HTLC failed and he will agree to refund the HTLC to Mallory.

However, in this case Mallory only gets back the funds Mallory put in the burn output (namely the HTLC payment amount and Mallory’s matching funds), and Bob’s matching funds for this HTLC are returned to Bob. Thus, there is no penalty payment from Bob to Mallory.

@harding

Even with unconditional fees, OPR would seem to create an incentive for an attacker to create disruptions within the network.

Mallory would never attack Bob in this manner, as Mallory would never benefit from such an attack.

It’s true that someone outside of the channel partners could mount a DOS attack on a channel in order to make a payment fail. Such an attack would be an attack on lightning (and not an attempt to steal funds), as it would fail a payment and it would make one of the routing nodes lose the value of the payment (they would pay in the channel in which they offered the HTLC, but would not collect in the channel in which they were offered the HTLC).

I see your point about the potential to rely on high-availability infrastructure (like CloudFlare) to be able to prevent such attacks. It’s hard to fully quantify the tradeoffs between the need for high availability with OPR versus the current lightning protocol. On the one hand, OPR is more susceptible to such attacks, given its very short expiries. On the other hand, the amount at risk with OPR could be much smaller if OPR replaces a single large HTLC with a stream of tiny, fast HTLCs.

@harding

says the current median percentage fee (not factoring in the base fee) is “0.000072 sat/sat”, or 0.0072% per hop, or 0.08% per payment assuming 11 hops, so OPR accidental routing failures is roughly expected to double the routing cost over the current system or 10,000x increase the cost over a (very theoretical) expected floor.

Thanks for the data and analysis.

Yes, the numbers I gave are much higher in terms of relative fees, but the base fees are quite important when considering small payments. The OPR protocol should have much lower base fees (especially if on-chain feerates increase), as there is never an on-chain fee required to resolve an OPR payment.

In any case, I think it’s quite possible that a user would choose to pay an additional $0.01 in order to guarantee that their $10.00 payment will be resolved within seconds, rather than hours.