This situation forces Bob into a dilemma where he must decide whether to put an HTLC-success transaction on-chain, which might not be cost-effective if the transaction cost exceeds the payment value. The current practice across all lightning implementations is to force close in such scenarios, despite the inefficiency, primarily to prevent exploitation whereby a party could incrementally steal the entire channel balance through unaddressed small HTLCs. Furthermore, the introduction of Output Power Reduction (OPR) exacerbates this problem by increasing the cost associated with force closing due to burned fees, thereby creating a stronger incentive for Bob to overlook small unresolved HTLCs, which poses a significant risk to his channel balance.

The methodology for determining the resolution of an HTLC involves verifying whether the required hash preimage was provided prior to the HTLC’s expiration. Nodes attempt to maintain accuracy in this process through time-stamped logs of hash preimages sent or received, relying on synchronized clocks among channel partners to mitigate discrepancies due to clock skew. However, the inherent unreliability of networks introduces challenges in distinguishing between genuine network delays and potential malicious actions by peers, raising concerns about the increased complexity leading to implementation errors and an uptick in force closures, especially problematic under OPR due to higher costs.

On the usability front, the OPR protocol offers a notable improvement by ensuring the resolution of payment attempts within seconds, significantly enhancing the user experience compared to the potential hours-long wait associated with the current Lightning protocol. Nevertheless, this comes at the cost of stringent capital requirements that demand users to have a balance equal to or greater than the payments they wish to receive, a stipulation aimed at discouraging cheating by making the funds at risk in a force close scenario exceed the value of outstanding HTLCs. Such requirements are particularly burdensome for casual users, who may already find the 1% reserve requirement frustrating, indicating a trade-off between improved transaction efficiency and accessibility for less frequent users.