On Mon, Nov 22, 2021 at 7:53 AM ZmnSCPxj <zmnsc...@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
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
