Closed m-schmoock closed 5 years ago
Nice catch!
It looks like getroute
provides a route through the incoming channel, but outgoing direction. The incoming and outgoing channels should be excluded in the correct direction. Or both direction for sure.
@m-schmoock What do you think, the payment went through the last channel twice, back and forth? And the incoming channel balance remained the same because the last two hops nullified each other? Or the payment simply skipped the last two hops, and shortened the route?
I'm thinking about sendinvoiceless
. What would happen if someone tries to send an invoiceless payment to node C through A->B->C->B->A circular route? May node B think it is easier to skip C from the route?
@gallizoltan If sendinvoiceless
is (in current form) correct, was also what I was thinking about. I dont know if the 'skipping of intermideates' is somehow the software default.
I can only tell that rebalance ended up effectively in using another channel scid_effective_in
(of mine), because it got first in the route at my node, instead of scid_intended_in
[ME] --- scid_out --- [NODE1] --- scid_effective_in --- [ME] --- some_scid --- [NODE2] --- scid_intended_in --- [ME]
When trying around with the rebalance plugin I discovered that it sometimes constructs / tries incorrect routes in a way that the payment gets delivered to one of my channels (no money lost), but it gets shifted into the wrong channel.
As the logs show below, my node (
02a2c53bc475cb92e4ab2f38a5bca56df695034ce90ad78c2f47c05911e3f79e41
) appears twice in the route. The rebalanced amount is shifted to the first channel occurence of my node along the route (574212x277x1
), not the destination (567180x2077x1
).Same here: