Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-17 📝 Original message: On Mon, Nov 22, 2021 at ...
📅 Original date posted:2021-12-17
📝 Original message:
On Mon, Nov 22, 2021 at 7:53 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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.
>
I like the idea of providing the user with such choices, similar to how for
example Uber presents its options. But I also agree with Z that it is
probably impossible to get a number of seconds there that comes close to
the actual time it would take.
For LND, I am currently proposing a fuzzy "time preference" parameter that
is vaguely indicative of the time that the payment is expected to take (
https://github.com/lightningnetwork/lnd/pull/6024). On the UI level this
can either be surfaced as a slider or the cost for three predefined values
for time preference can be shown:
Slow: 10 msat
Normal: 150 msat
Fast: 4000 msat
> 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?
>
A fee budget indeed expresses the time preference indirectly. But how does
the user know what a reasonable value is to set this to? It is depend on
network conditions. They may accidentally set it to a value that is too low
and get an unexpectedly slow payment.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211217/745a7613/attachment.html>;
📝 Original message:
On Mon, Nov 22, 2021 at 7:53 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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.
>
I like the idea of providing the user with such choices, similar to how for
example Uber presents its options. But I also agree with Z that it is
probably impossible to get a number of seconds there that comes close to
the actual time it would take.
For LND, I am currently proposing a fuzzy "time preference" parameter that
is vaguely indicative of the time that the payment is expected to take (
https://github.com/lightningnetwork/lnd/pull/6024). On the UI level this
can either be surfaced as a slider or the cost for three predefined values
for time preference can be shown:
Slow: 10 msat
Normal: 150 msat
Fast: 4000 msat
> 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?
>
A fee budget indeed expresses the time preference indirectly. But how does
the user know what a reasonable value is to set this to? It is depend on
network conditions. They may accidentally set it to a value that is too low
and get an unexpectedly slow payment.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211217/745a7613/attachment.html>;