# 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:** 3
**Author:** ![harding](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/harding/32/925_2.png) [@harding](https://delvingbitcoin.org/u/harding)\ **Post date:** [November 5, 2024, 10:14am UTC](https://delvingbitcoin.org/t/a-fast-scalable-protocol-for-resolving-lightning-payments/1233/3 "2024-11-05T10:14:19Z")
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. Even with unconditional fees, OPR would seem to create an incentive for an attacker to create disruptions within the network. Defending against such attacks could become a centralizing factor (e.g. in the same way that many popular websites use CloudFlare today because it’s one of the few services big enough to survive cheap-to-perform DDoS attacks). > [@JohnLaw](#): > > If we assume the average incremental latency required to resolve an HTLC is 100 milliseconds and the average payment traverses 11 hops, each HTLC will be resolved an average of 600 milliseconds after it’s created. If each node fails (due to a crash, delay, or protocol error) randomly 10 times a day, thus causing it to lose the value of all unresolved HTLCs, that node will lose the value of one out of every 14,400 HTLCs. Therefore, increasing the routing fee by 1/14,400 = 0.007% of the HTLC value per node (and thus 0.077% per payment) will cover the cost of node failures that cause HTLC failures. If the risk-free interest rate is 2% per annum, then we would expect the forwarding fee in a mature system to approach 0.00000004% per hop for a 600 ms average settlement time (`2 / (86400 / 0.6) / 365.25`), or 0.0000004% per payment assuming 11 hops. The OPR fee is 5 orders of magnitude higher. [Lightning Network Statistics | 1ML - Lightning Network Search and Analysis Engine - Bitcoin mainnet](https://1ml.com/statistics) 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. That does not count the costs of non-accidental failures (i.e. attacks) or the costs of preventing attacks. > [@JohnLaw](#): > > The security of all known Lightning payment protocols breaks down when the incremental cost of resolving a payment on-chain exceeds the value of the payment. One theoretical solution, [proposed years ago](https://docs.google.com/presentation/d/1G4xchDGcO37DJ2lPC_XYyZIUkJc2khnLrCaZXgvDN0U/edit?pref=2&pli=1#slide=id.g85f425098_0_195), is for low-value payments to be encapsulated in higher-value outputs using probabilistic payments. For example: when it would cost $10 in onchain fees to settle an HTLC, Alice offers Bob a $100 HTLC with an HTLC-Success transaction that gives him a 1% chance of being able to claim it onchain (the other 99% of the time, Alice reclaims the money). Bob accepts that and forwards $1 to Carol (perhaps also using a probabilistic payment). If the HTLC is settled offchain (either success or failure), then the $100 output is reallocated $1 to Bob and $99 to Alice. If it goes onchain, then Bob gets his 1% chance at $100 (i.e., an expected value before fees of $1) which will cost him $10 in fees if he’s successful; in the other 99% of the time, Alice gets her $100 back (expected value $99) by paying $10 in fees. Probabilistic payments are possible today on Elements-based sidechains using `OP_DETERMINISTIC_RANDOM`. It’s my belief (possibly ill-informed) that there’s been minimal work in this direction due to HTLC settlement cost griefing not being perceived as a major problem at present. > [@JohnLaw](#): > > all payments are resolved within seconds (as compared to hours for the current protocol), [Opportunistic overpayments](https://bitcoinops.org/en/topics/redundant-overpayments/) also has this property for _almost_ all payments. If, in your proposal, the burn output is expected to be a multiple of the maximal OPR HTLC amount, then the same amount of funds could be used instead for an refundable overpayment that would significantly increase the odds of rapid payment success. Most discussion about overpayments that I’m aware of has preferred a PTLC-based mechanism, which is something that’s still being developed for LN. --- _[View the full topic](https://delvingbitcoin.org/t/a-fast-scalable-protocol-for-resolving-lightning-payments/1233)._