{"type":"rich","version":"1.0","author_name":"npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","author_url":"https://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2021-10-14\n📝 Original message:\nA practice that is widely applied by lightning wallets is to probe routes\nwith an unknown payment hash before making the actual payment. Probing\nyields an accurate routing fee that can be shown to the user before\nexecution of the payment.\n\nThe downside of this style of probing is that for a short period of time,\nliquidity is locked up. Not just the sender's liquidity, but also liquidity\nof nodes along the route. And if the probe gets stuck for whatever reason,\nthat short period may become longer.\n\nBut does this lock up serve a purpose at all? Suppose there would be a\nliquidity probing protocol message similar to `update_add_htlc`\n(`probe_htlc`?) that would skip the whole channel update machinery and is\nonly forwarded to the next hop if the link would be able to carry the htlc.\nWon't this work as well as the current probing without the downsides? Nodes\ncan obviously reject these probes because they are distinguishable from\nreal payments (contrary to unknown hash probing where everything looks the\nsame). However if they do so, senders won't use that route and the routing\nnode misses out on routing fees.\n\nAnother problem of the lightning network is its susceptibility to channel\njamming. Multiple options have been proposed (see also\nhttps://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md),\nbut they all come with downsides.\n\nPersonally I incline towards solutions that involve deterring the attacker\nby making them pay actual satoshis. Lightning itself is payment system and\nit seems that paying for the payments is a natural solution to the problem.\nSeveral iterations of this idea have been proposed. One of my own that\nbuilds on an earlier idea by t-bast is described in\nhttps://lists.linuxfoundation.org/pipermail/lightning-dev/2021-February/002958.html\n.\n\nThe main criticism that this proposal has received is that it deteriorates\nthe user experience for honest users when multiple payment routes need to\nbe attempted. Every attempt will have a cost, so the user will see its\nbalance going down by only just trying to make the payment. How bad this is\ndepends on the attempt failure rate. I expect this rate to become really\nlow as the network matures and senders hold routing nodes to high\nstandards. Others however think otherwise and consider a series of failed\nattempts part of a healthy system.\n\nCustodial wallets could probably just swallow the cost for failures. They\ntypically use one pathfinding system for all their users and are therefore\nable to collect a lot of information on routing node performance. This is\nlikely to decrease the payment failure rate to an acceptably low level.\n\nFor non-custodial nodes, this may be different. They have to map out the\ngood routing nodes  all by themselves and this exploration will bear a cost.\n\nSo how would things work out with a combination of both of the proposals\ndescribed in this mail? First we make probing free (free as in no liquidity\nlocked up) and then we'll require senders to pay for failed payment\nattempts too. Failed payment attempts after a successful probe should be\nextremely rate, so doesn't this fix the ux issue with upfront fees?\n\nJoost\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211014/04750627/attachment.html\u003e"}