David A. Harding [ARCHIVE] on Nostr: 📅 Original date posted:2021-11-20 📝 Original message: On Mon, Nov 15, 2021 at ...
📅 Original date posted:2021-11-20
📝 Original message:
On Mon, Nov 15, 2021 at 04:25:26PM +0100, Joost Jager wrote:
> Reliability is a property of a route that can
> be expressed as a probability. The probability that a route will be
> successful.
I don't think users care about the abstract concept of reliability
that's being returned by the pathfinding code here. What users care
about is "how long will it take for my payment to make the point-of-sale
terminal turn green so I can walk away with my warm beverage?"
This is basically analogous to the fee optimization question that
onchain wallets have been asking users for years: how many blocks do you
want to wait for [the first] confirmation? The way that's presented to
users in software like Bitcoin Core is,
2 blocks (~20 minutes), x fee
6 blocks (~60 minutes), y fee
36 blocks (~6 hours), z fee
etc...
The onchain estimates in Bitcoin Core are based[1] on a 95% threshold.
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
-Dave
[1] https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211120/dbb8d3d7/attachment.sig>;
📝 Original message:
On Mon, Nov 15, 2021 at 04:25:26PM +0100, Joost Jager wrote:
> Reliability is a property of a route that can
> be expressed as a probability. The probability that a route will be
> successful.
I don't think users care about the abstract concept of reliability
that's being returned by the pathfinding code here. What users care
about is "how long will it take for my payment to make the point-of-sale
terminal turn green so I can walk away with my warm beverage?"
This is basically analogous to the fee optimization question that
onchain wallets have been asking users for years: how many blocks do you
want to wait for [the first] confirmation? The way that's presented to
users in software like Bitcoin Core is,
2 blocks (~20 minutes), x fee
6 blocks (~60 minutes), y fee
36 blocks (~6 hours), z fee
etc...
The onchain estimates in Bitcoin Core are based[1] on a 95% threshold.
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
-Dave
[1] https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211120/dbb8d3d7/attachment.sig>;