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