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@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
