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
When estimating route fees through probing, the isLSP function is called to decided if the destination node is being serviced by a Lightning Service Provider. In such case, the probe is performed to the LSP.
The documentation of such function reads,
// isLSP checks if the route hints indicate an LSP. An LSP is indicated with
// true if the destination hop hint in each route hint has the same node id,
// false otherwise....
Muun Wallet invoices currently show 2 route hints with different node ids. Lightspark seems to have had a similar issue as reported in a comment. Evidently, several LSP use multiple public nodes to route payments to their users. Thus, the requirement that the last node id of each route hint is the same is too demanding. I strongly suggest not returning False in this case.
(since this was the intended behaviour of this function, I'm opening this as a discussion and not a bug report)
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
When estimating route fees through probing, the isLSP function is called to decided if the destination node is being serviced by a Lightning Service Provider. In such case, the probe is performed to the LSP.
The documentation of such function reads,
Muun Wallet invoices currently show 2 route hints with different node ids. Lightspark seems to have had a similar issue as reported in a comment. Evidently, several LSP use multiple public nodes to route payments to their users. Thus, the requirement that the last node id of each route hint is the same is too demanding. I strongly suggest not returning False in this case.
(since this was the intended behaviour of this function, I'm opening this as a discussion and not a bug report)
Beta Was this translation helpful? Give feedback.
All reactions