akumaigorodski
How is your pathfinding better?
In the readme you mention that your pathfinding is better. How did you evaluate that?
It's due to a particular MPP splitting strategy and some fundamental tradeoffs.
A strategy is "divide and conquer": payment starts with a set of as large parts as possible and then each part gets roughly divided in half when the need arises.
Tradeoffs are that all local channels and management of outgoing payment parts run within a single thread. Also path finding is done in such a way that it can only process one route request at a time while other parts without an assigned route wait in a queue. This means that library can effectively process one part at a time while others wait for their turn.
Upside here is that more fine-grained MPP control becomes possible, a few examples:
-
it's possible to always know exactly how much usable balance is left in each local channel at all times which simplifies splitting logic a lot.
-
when many parts are already in-flight library can reliably exclude certain already utilized remote channels from further path finding simply because it knows that remaining capacity there won't allow for another part of given size.
-
when an enabled remote channel returns a temporary failure it is assumed that channel can not route a given amount right now, but possibly can still process another part with smaller amount, so it's not yet fully excluded from further path finding for smaller parts. This effectively probes a network capacities within a short time frame and plays well with chosen splitting strategy.
Downside is obviously a dramatically reduced performance which I think is a reasonable compromise given targeted use cases.
Would it be possible with IMMORTAN to give users an exact total (incl. fees) before a payment is triggered? (Accepting that a small number of payments would fail and have to be re-quoted.)
@xanoni
Accepting that a small number of payments would fail and have to be re-quoted
This is the problem here: it's never known how many initially picked routes will fail and then be retried with higher fees, could easily be a lot instead of a few.
The only sure thing is setting a total fee limit as some absolute amount of SAT, capping that limit to current average chain fee seems like a good idea, that's the current approach in a wallet.
Got it. Some people are unhappy if they don't know in advance exactly what they are paying. I think this expectation management is for the wallet UX expert to handle. I'm not one of them, but there could be different psychological effects depending on whether you show a range, an expected value, just the maximum, etc.