A Fast, Scalable Protocol For Resolving Lightning Payments

[JohnLaw]

@morehouse

All lightning implementations today will force close in this case even though it’s not cost effective (though they might not claim the HTLC output on chain), and for good reason. If Bob adopts a policy of “forgiving” small HTLCs in an attempt to stay off chain, it enables Alice to steal Bob’s entire channel balance one small HTLC at a time.

Yes, it makes sense that all lightning implementations prevent theft of small HTLCs, even when it’s not cost effective. As you point out, this is required to avoid becoming a sucker who can be slowly cheated out of their funds. As a result, the lightning protocol is fairly secure, even for small payments.

It seems the main benefits of the OPR protocol are its speed and scalability. I probably should have emphasized those benefits, rather than security for small payments, in the post and paper. Thanks for your feedback.

@morehouse

OPR actually makes this problem worse. Because Bob’s cost of force closing is higher with OPR (due to burned fees), there is a larger incentive for Bob to forgive small HTLCs that Alice refuses to resolve before expiry

Actually, with the OPR protocol, choosing to stay off-chain (rather than force closing) in no way leads to accepting the incorrect resolution of an HTLC. That type of logic (having to go on-chain for resolve an HTLC in one’s favor) applies to the current lightning protocol, but not to the OPR protocol.

@morehouse

Since networks are inherently unreliable, can’t an attacker easily lie about the actual time the message was sent? How does a node distinguish between occasional network lag and a malicious peer?

Yes, an attacker can lie. However, with the OPR protocol they have absolutely no incentive to do so (and will actually be penalized if they do so).

There’s no reason for a peer to be malicious (unless they’re griefing while self-griefing, which should be very rare).

The more relavent question is how both non-malicious peers can agree on whether or not an HTLC was resolved. A number of techniques for doing this are presented in the post at the end of the Burned Funds section.

@morehouse

Even if everyone is honest, I fear that the higher complexity of determining success/failure will lead to implementation bugs and more force closes, which are extra costly with OPR.

OPR never requires a forced close, even if the peers fail to agree on the resolution of an HTLC. In such a case, they can keep the channel open and process additional HTLCs.

When they finally close the channel, they can create a cooperative close that returns their base funds and only burns the single HTLC on which they disagreed. As a result, the OPR protocol strictly improves scalability, as it completely eliminates the need to resolve HTLCs on-chain.

@morehouse

To properly disincentivize cheating, the amount of funds each party contributes to the burn output must always be higher than the total value of outstanding HTLCs (otherwise users could profit from force closing without forwarding preimages).

Users can never profit from force closing a channel with the OPR protocol (as long as their peer follows the protocol and avoids being bullied, as described in the post). With the OPR protocol, neither the offerer nor the offeree receives the HTLC’s funds if they force close the channel with a peer that has not agreed on the HTLC’s resolution. Therefore, there is no such minimum burn contribution that’s required to secure the channel.