Stefan Richter [ARCHIVE] on Nostr: 📅 Original date posted:2021-11-22 📝 Original message: I also don't believe ...
📅 Original date posted:2021-11-22
📝 Original message:
I also don't believe putting a choice of more or less seconds expectation
in the UI makes for a great user experience. IMHO the goal should just be:
give the user an estimate of fees necessary to succeed within a reasonable
time. Maybe give them an option to optimize for fees only if they are
really cheap and don't care at all if the payment succeeds.
Cheers
Stefan
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
schrieb am Mo., 22. Nov. 2021, 00:53:
> Good morning Dave,
>
> > If LN software speculatively chooses a series of attempts with a similar
> > 95%, accounting for things like the probability of a stuck payment (made
> > worse by longer CLTV timeouts on some paths), it could present users
> > with the same sort of options:
> >
> > ~1 second, x fee
> > ~3 seconds, y fee
> > ~10 seconds, z fee
> >
> > This allows the software to use its reliability scoring efficiently in
> > choosing what series of payment attempts to make and presents to the
> > user the information they need to make a choice appropriate for their
> > situation. As a bonus, it makes it easier for wallet software to move
> > towards a world where there is no user-visible difference between
> > onchain and offchain payments, e.g.:
> >
> > ~1 second, w fee
> > ~15 seconds, x fee
> > ~10 minutes, y fee
> > ~60 minutes, z fee
>
> This may not match ideally, as in the worst case a forwarding might be
> struck by literal lightning and dropped off the network while your HTLC is
> on that node, only for the relevant channel to be dropped onchain days
> later when the timeout comes due.
> Providing this "seconds" estimate does not prepare users for the
> possibility of such black swan events where a high fee transaction gets
> stalled due to an accident on the network.
>
> On the other hand, humans never really handle black swan events in any
> reasonably way anyway, and 95% of the time it will probably achieve that
> number of estimated seconds or less.
> Even the best onchain estimators fail when a thundering herd of
> speculators decides to trade Bitcoin based on random crap from the
> noosphere.
>
> The processing to figure out a payment plan also becomes significant at
> the "seconds" level, especially if you switch to mincostflow rather than
> shortestpath.
> This means the CPU speed of the local node may become significant, or if
> you are delegating pathfinding to a trusted server, the load on that
> trusted server becomes significant.
> Sigh.
>
> Why not just ask for a fee budget for a payment, and avoid committing
> ourselves to paying within some number of seconds, given that the seconds
> estimate may very well vary depending on local CPU load?
> Would users really complain overmuch if the number of seconds is not
> provided, given that we cannot really estimate this well?
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211122/60a58188/attachment.html>;
📝 Original message:
I also don't believe putting a choice of more or less seconds expectation
in the UI makes for a great user experience. IMHO the goal should just be:
give the user an estimate of fees necessary to succeed within a reasonable
time. Maybe give them an option to optimize for fees only if they are
really cheap and don't care at all if the payment succeeds.
Cheers
Stefan
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org>
schrieb am Mo., 22. Nov. 2021, 00:53:
> Good morning Dave,
>
> > If LN software speculatively chooses a series of attempts with a similar
> > 95%, accounting for things like the probability of a stuck payment (made
> > worse by longer CLTV timeouts on some paths), it could present users
> > with the same sort of options:
> >
> > ~1 second, x fee
> > ~3 seconds, y fee
> > ~10 seconds, z fee
> >
> > This allows the software to use its reliability scoring efficiently in
> > choosing what series of payment attempts to make and presents to the
> > user the information they need to make a choice appropriate for their
> > situation. As a bonus, it makes it easier for wallet software to move
> > towards a world where there is no user-visible difference between
> > onchain and offchain payments, e.g.:
> >
> > ~1 second, w fee
> > ~15 seconds, x fee
> > ~10 minutes, y fee
> > ~60 minutes, z fee
>
> This may not match ideally, as in the worst case a forwarding might be
> struck by literal lightning and dropped off the network while your HTLC is
> on that node, only for the relevant channel to be dropped onchain days
> later when the timeout comes due.
> Providing this "seconds" estimate does not prepare users for the
> possibility of such black swan events where a high fee transaction gets
> stalled due to an accident on the network.
>
> On the other hand, humans never really handle black swan events in any
> reasonably way anyway, and 95% of the time it will probably achieve that
> number of estimated seconds or less.
> Even the best onchain estimators fail when a thundering herd of
> speculators decides to trade Bitcoin based on random crap from the
> noosphere.
>
> The processing to figure out a payment plan also becomes significant at
> the "seconds" level, especially if you switch to mincostflow rather than
> shortestpath.
> This means the CPU speed of the local node may become significant, or if
> you are delegating pathfinding to a trusted server, the load on that
> trusted server becomes significant.
> Sigh.
>
> Why not just ask for a fee budget for a payment, and avoid committing
> ourselves to paying within some number of seconds, given that the seconds
> estimate may very well vary depending on local CPU load?
> Would users really complain overmuch if the number of seconds is not
> provided, given that we cannot really estimate this well?
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211122/60a58188/attachment.html>;