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. Besides, if Alice is unresponsive to HTLC claims for 5+ hours (i.e. the typical CLTV delta), she’s a poor channel partner even if she’s honest.
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.
Seems tricky. 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?
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.
Yes, this is good UX for casual users.
But the capital requirements of OPR are also quite bad UX for casual users. 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). This means that in order to receive payments, users must already have at least as much balance on their side of the channel as they want to receive. Casual lightning users already get frustrated by the 1% reserve requirement, so this new requirement is sure to cause even more frustration.