rich1.0npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxhttps://nostr.ae/npub1aslmpzentw224n3s6yccru4dq2qdlx7rfudfnqevfck637cjt6esswfqmxnjumphttps://nostr.ae📅 Original date posted:2021-10-21 📝 Original message: A potential downside of a dedicated probe message is that it could be used for free messaging on lightning by including additional data in the payload for the recipient. Free messaging is already possible today via htlcs, but a probe message would lower the cost to do so because the sender doesn't need to lock up liquidity for it. This probably increases the spam potential. I am wondering if it is possible to design the probe message so that it is useless for anything other than probing. I guess it is hard because it would still have that obfuscated 1300 bytes block with the remaining part of the route in it and nodes can't see whether there is other meaningful data at the end. On Thu, Oct 14, 2021 at 9:48 AM Joost Jager <joost.jager at gmail.com> wrote: > 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/20211021/2730142c/attachment.html>