From joost.jager at gmail.com Fri Dec 17 08:31:15 2021 From: joost.jager at gmail.com (Joost Jager) Date: Fri, 17 Dec 2021 09:31:15 +0100 Subject: [Lightning-dev] Route reliability<->fee trade-off control parameter In-Reply-To: <1SrBJFZslCIQiYwJe3BaIAFL42rIC6jhOoqtw3gCXjdh-axfuRCHg4sq9uwKCnBF6_eh0PrnEjx_b7S4frQJP9yEowBGsKQ_bUuilZ1aDA8=@protonmail.com> References: <0100017d3f96460a-73915c56-dc1e-4338-8d51-7f00d255c356-000000@email.amazonses.com> <1SrBJFZslCIQiYwJe3BaIAFL42rIC6jhOoqtw3gCXjdh-axfuRCHg4sq9uwKCnBF6_eh0PrnEjx_b7S4frQJP9yEowBGsKQ_bUuilZ1aDA8=@protonmail.com> Message-ID: On Mon, Nov 22, 2021 at 7:53 AM ZmnSCPxj 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: