You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When using #PickhardtPayments to send a payment, the fees for each resulting route need to be paid on top of the actual amount. This isn't taken into consideration when looking for routes, which is why (for expensive routes) the resulting routes might not be suitable.
A similar problem exists when sending amounts that cannot be expressed using the quantization amount, e.g. sending 14,000sat with the quantization amount set to 5,000sat. In this example, the algorithm would try to find routes for two "units" (each worth 5,000sat) and, if such routes are found, add the remaining 4,000sat to one of them.
To avoid this issue, currently the (assumed available) capacity of each channel is reduced by one "unit" (quantization amount), so that a bit of leeway exists for fees and rounding issues.
Describe the solution you'd like
Instead, it could be a better idea to artificially inflate the requested amount. In the example above, when sending out 14,000sat with the quantization amount set to 5,000sat, we could search for routes that can be used to send out 15,000sat instead. If such routes are found, we can adapt the amount(s) before sending out the actual payment(s).
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
When using #PickhardtPayments to send a payment, the fees for each resulting route need to be paid on top of the actual amount. This isn't taken into consideration when looking for routes, which is why (for expensive routes) the resulting routes might not be suitable.
A similar problem exists when sending amounts that cannot be expressed using the quantization amount, e.g. sending 14,000sat with the quantization amount set to 5,000sat. In this example, the algorithm would try to find routes for two "units" (each worth 5,000sat) and, if such routes are found, add the remaining 4,000sat to one of them.
To avoid this issue, currently the (assumed available) capacity of each channel is reduced by one "unit" (quantization amount), so that a bit of leeway exists for fees and rounding issues.
Describe the solution you'd like
Instead, it could be a better idea to artificially inflate the requested amount. In the example above, when sending out 14,000sat with the quantization amount set to 5,000sat, we could search for routes that can be used to send out 15,000sat instead. If such routes are found, we can adapt the amount(s) before sending out the actual payment(s).
The text was updated successfully, but these errors were encountered: