Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-14 📝 Original message: A practice that is widely ...
📅 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>;
📝 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>;