rich1.0npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxhttps://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxnjumphttps://nostr.ae📅 Original date posted:2021-10-14 📝 Original message: A practice that is widely applied by lightning wallets is to probe routes with an unknown payment hash before making the actual payment. Probing yields an accurate routing fee that can be shown to the user before execution of the payment. The downside of this style of probing is that for a short period of time, liquidity is locked up. Not just the sender's liquidity, but also liquidity of nodes along the route. And if the probe gets stuck for whatever reason, that short period may become longer. But does this lock up serve a purpose at all? Suppose there would be a liquidity probing protocol message similar to `update_add_htlc` (`probe_htlc`?) that would skip the whole channel update machinery and is only forwarded to the next hop if the link would be able to carry the htlc. Won't this work as well as the current probing without the downsides? Nodes can obviously reject these probes because they are distinguishable from real payments (contrary to unknown hash probing where everything looks the same). However if they do so, senders won't use that route and the routing node misses out on routing fees. Another problem of the lightning network is its susceptibility to channel jamming. Multiple options have been proposed (see also https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md), but they all come with downsides. Personally I incline towards solutions that involve deterring the attacker by making them pay actual satoshis. Lightning itself is payment system and it seems that paying for the payments is a natural solution to the problem. Several iterations of this idea have been proposed. One of my own that builds on an earlier idea by t-bast is described in https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-February/002958.html . The main criticism that this proposal has received is that it deteriorates the user experience for honest users when multiple payment routes need to be attempted. Every attempt will have a cost, so the user will see its balance going down by only just trying to make the payment. How bad this is depends on the attempt failure rate. I expect this rate to become really low as the network matures and senders hold routing nodes to high standards. Others however think otherwise and consider a series of failed attempts part of a healthy system. Custodial wallets could probably just swallow the cost for failures. They typically use one pathfinding system for all their users and are therefore able to collect a lot of information on routing node performance. This is likely to decrease the payment failure rate to an acceptably low level. For non-custodial nodes, this may be different. They have to map out the good routing nodes all by themselves and this exploration will bear a cost. So how would things work out with a combination of both of the proposals described in this mail? First we make probing free (free as in no liquidity locked up) and then we'll require senders to pay for failed payment attempts too. Failed payment attempts after a successful probe should be extremely rate, so doesn't this fix the ux issue with upfront fees? Joost -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211014/04750627/attachment.html>