lightningd / plugins

Community curated plugins for core-lightning
BSD 3-Clause "New" or "Revised" License
269 stars 129 forks source link

rebalance creating incorrect routes #17

Closed m-schmoock closed 5 years ago

m-schmoock commented 5 years ago

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).

2019-05-06T21:27:34.579Z plugin-rebalance.py Estimating optimal amount 708740000msat
2019-05-06T21:27:34.785Z plugin-rebalance.py Invoice payment_hash: b1cc486a533865738b13f3662ec7218083e32b8c2575b3ee7d5e12b6d678e87c
2019-05-06T21:27:34.821Z plugin-rebalance.py Sending 708747066msat over 5 hops to rebalance 708740000msat
2019-05-06T21:27:34.821Z plugin-rebalance.py Node: 030995c0c0217d763c2274aa6ed69a0bb85fa2f7d118f93631550f3b6219a577f5, channel: 566627x2814x0, 708747066msat
2019-05-06T21:27:34.821Z plugin-rebalance.py Node: 03dab87ff8635982815c4567eb58af48f9944d11c56beb12b91e1049aaea06e187, channel: 567237x2798x0, 708746358msat
2019-05-06T21:27:34.821Z plugin-rebalance.py Node: 02a2c53bc475cb92e4ab2f38a5bca56df695034ce90ad78c2f47c05911e3f79e41, channel:  574212x277x1, 708744941msat
2019-05-06T21:27:34.821Z plugin-rebalance.py Node: 0214ec84c84827dd4911de56d2ecb77d367c6f24c658b8acfe4826b01968e45594, channel: 567180x2077x1, 708741707msat
2019-05-06T21:27:34.821Z plugin-rebalance.py Node: 02a2c53bc475cb92e4ab2f38a5bca56df695034ce90ad78c2f47c05911e3f79e41, channel: 567180x2077x1, 708740000msat
2019-05-06T21:27:34.825Z lightningd(23061): Sending 708747066msat over 5 hops to deliver 708740000msat
2019-05-06T21:27:58.052Z lightningd(23061): Resolved invoice 'Rebalance-5f20fcab-fbab-4cb6-8913-df49b423d03e' with amount 708740000msat

Same here:

2019-05-06T21:20:17.644Z plugin-rebalance.py Estimating optimal amount 708739000msat
2019-05-06T21:20:17.819Z plugin-rebalance.py Invoice payment_hash: 99ea0a4780439704a8b906a004d12d4771bee0b0c0e25a7ae40c59105d323185
2019-05-06T21:20:17.859Z plugin-rebalance.py Sending 708746066msat over 5 hops to rebalance 708739000msat
2019-05-06T21:20:17.859Z plugin-rebalance.py Node: 030995c0c0217d763c2274aa6ed69a0bb85fa2f7d118f93631550f3b6219a577f5, channel: 566627x2814x0, 708746066msat
2019-05-06T21:20:17.859Z plugin-rebalance.py Node: 02247d9db0dfafea745ef8c9e161eb322f73ac3f8858d8730b6fd97254747ce76b, channel: 567267x1939x0, 708745358msat
2019-05-06T21:20:17.859Z plugin-rebalance.py Node: 02a2c53bc475cb92e4ab2f38a5bca56df695034ce90ad78c2f47c05911e3f79e41, channel: 573948x2183x0, 708743941msat
2019-05-06T21:20:17.859Z plugin-rebalance.py Node: 0214ec84c84827dd4911de56d2ecb77d367c6f24c658b8acfe4826b01968e45594, channel: 567180x2077x1, 708740707msat
2019-05-06T21:20:17.859Z plugin-rebalance.py Node: 02a2c53bc475cb92e4ab2f38a5bca56df695034ce90ad78c2f47c05911e3f79e41, channel: 567180x2077x1, 708739000msat
2019-05-06T21:20:17.862Z lightningd(23061): Sending 708746066msat over 5 hops to deliver 708739000msat
2019-05-06T21:20:31.089Z lightningd(23061): Resolved invoice 'Rebalance-2ea19a98-27e7-4b7e-a484-69d396f53995' with amount 708739000msat
gallizoltan commented 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.

https://github.com/lightningd/plugins/blob/c70367b231f98781a6b99b9150943cb3bf308f22/rebalance/rebalance.py#L149

gallizoltan commented 5 years ago

@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?

m-schmoock commented 5 years ago

@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]