{"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-21\n📝 Original message:\nA potential downside of a dedicated probe message is that it could be used\nfor free messaging on lightning by including additional data in the payload\nfor the recipient. Free messaging is already possible today via htlcs, but\na probe message would lower the cost to do so because the sender doesn't\nneed to lock up liquidity for it. This probably increases the spam\npotential. I am wondering if it is possible to design the probe message so\nthat it is useless for anything other than probing. I guess it is hard\nbecause it would still have that obfuscated 1300 bytes block with the\nremaining part of the route in it and nodes can't see whether there is\nother meaningful data at the end.\n\nOn Thu, Oct 14, 2021 at 9:48 AM Joost Jager \u003cjoost.jager at gmail.com\u003e wrote:\n\n\u003e A practice that is widely applied by lightning wallets is to probe routes\n\u003e with an unknown payment hash before making the actual payment. Probing\n\u003e yields an accurate routing fee that can be shown to the user before\n\u003e execution of the payment.\n\u003e\n\u003e The downside of this style of probing is that for a short period of time,\n\u003e liquidity is locked up. Not just the sender's liquidity, but also liquidity\n\u003e of nodes along the route. And if the probe gets stuck for whatever reason,\n\u003e that short period may become longer.\n\u003e\n\u003e But does this lock up serve a purpose at all? Suppose there would be a\n\u003e liquidity probing protocol message similar to `update_add_htlc`\n\u003e (`probe_htlc`?) that would skip the whole channel update machinery and is\n\u003e only forwarded to the next hop if the link would be able to carry the htlc.\n\u003e Won't this work as well as the current probing without the downsides? Nodes\n\u003e can obviously reject these probes because they are distinguishable from\n\u003e real payments (contrary to unknown hash probing where everything looks the\n\u003e same). However if they do so, senders won't use that route and the routing\n\u003e node misses out on routing fees.\n\u003e\n\u003e Another problem of the lightning network is its susceptibility to channel\n\u003e jamming. Multiple options have been proposed (see also\n\u003e https://github.com/t-bast/lightning-docs/blob/master/spam-prevention.md),\n\u003e but they all come with downsides.\n\u003e\n\u003e Personally I incline towards solutions that involve deterring the attacker\n\u003e by making them pay actual satoshis. Lightning itself is payment system and\n\u003e it seems that paying for the payments is a natural solution to the problem.\n\u003e Several iterations of this idea have been proposed. One of my own that\n\u003e builds on an earlier idea by t-bast is described in\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-February/002958.html\n\u003e .\n\u003e\n\u003e The main criticism that this proposal has received is that it deteriorates\n\u003e the user experience for honest users when multiple payment routes need to\n\u003e be attempted. Every attempt will have a cost, so the user will see its\n\u003e balance going down by only just trying to make the payment. How bad this is\n\u003e depends on the attempt failure rate. I expect this rate to become really\n\u003e low as the network matures and senders hold routing nodes to high\n\u003e standards. Others however think otherwise and consider a series of failed\n\u003e attempts part of a healthy system.\n\u003e\n\u003e Custodial wallets could probably just swallow the cost for failures. They\n\u003e typically use one pathfinding system for all their users and are therefore\n\u003e able to collect a lot of information on routing node performance. This is\n\u003e likely to decrease the payment failure rate to an acceptably low level.\n\u003e\n\u003e For non-custodial nodes, this may be different. They have to map out the\n\u003e good routing nodes  all by themselves and this exploration will bear a cost.\n\u003e\n\u003e So how would things work out with a combination of both of the proposals\n\u003e described in this mail? First we make probing free (free as in no liquidity\n\u003e locked up) and then we'll require senders to pay for failed payment\n\u003e attempts too. Failed payment attempts after a successful probe should be\n\u003e extremely rate, so doesn't this fix the ux issue with upfront fees?\n\u003e\n\u003e Joost\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211021/2730142c/attachment.html\u003e"}