# A Fast, Scalable Protocol For Resolving Lightning Payments **URL:** \ **Category:** Protocol Design\ **Tags:** lightning\ **Created:** [October 31, 2024, 10:45pm UTC](https://delvingbitcoin.org/t/a-fast-scalable-protocol-for-resolving-lightning-payments/1233 "2024-10-31T22:45:07Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![morehouse](https://delvingbitcoin.org/letter_avatar_proxy/v4/letter/m/df705f/32.png) [@morehouse](https://delvingbitcoin.org/u/morehouse)\ **Post date:** [November 4, 2024, 11:59pm UTC](https://delvingbitcoin.org/t/a-fast-scalable-protocol-for-resolving-lightning-payments/1233/2 "2024-11-04T23:59:52Z")
> [@JohnLaw](#): > > For example, if Alice uses the current Lightning protocol to offer an HTLC to Bob, and Bob fulfills the HTLC by providing the required hash preimage before its expiry, Alice is supposed to update the channel state off-chain to reflect the payment of the HTLC to Bob. However, if Alice fails to do so, Bob’s only recourse is to put an HTLC-success transaction on-chain. If the cost of putting the HTLC-success transaction on-chain exceeds the value of the payment, resolving the HTLC on-chain is more costly for Bob than allowing Alice to claim the payment. Therefore, Alice is incentivized to violate the protocol by not giving the payment’s funds to Bob off-chain, as she will receive those funds unless Bob acts against his immediate self-interest. 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. > [@JohnLaw](#): > > In order to determine if an HTLC was resolved successfully, a node has to determine if the required hash preimage was provided before the HTLC’s expiry. All hash preimage messages can include a time stamp recording when they were sent, and each node can keep a time-stamped nonvolatile log of each hash preimage that it sends or receives. This log can be used to determine the result of an HTLC, even if the node crashes when the HTLC was being resolved. Channel partners can keep their clocks synchronized by exchanging frequent time stamp messages, and the htlc\_expiry\_delta\_msec parameters can include a buffer for clock skew. 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. > [@JohnLaw](#): > > # Usability > > The OPR protocol’s guaranteed resolution of a payment attempt within seconds makes it much more attractive to casual users than the current Lightning protocol, which could require waiting hours to find out that a payment attempt failed. 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. --- _[View the full topic](https://delvingbitcoin.org/t/a-fast-scalable-protocol-for-resolving-lightning-payments/1233)._