--- Log opened Wed Feb 03 00:00:34 2021
00:16 -!- liberliver [~Thunderbi@x4dbf3f91.dyn.telefonica.de] has joined #c-lightning
01:05 -!- rny [~rny@gateway/tor-sasl/renlord] has quit [Remote host closed the connection]
01:06 -!- rny [~rny@gateway/tor-sasl/renlord] has joined #c-lightning
01:22 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
01:24 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
01:56 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 258 seconds]
02:30 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 268 seconds]
02:31 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
02:37 -!- cryptoso- [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #c-lightning
02:37 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Quit: %bye%]
03:25 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
04:10 -!- belcher_ is now known as belcher
04:54 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-qtzfkbumkrmirmay] has quit [Remote host closed the connection]
04:56 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-oxixcxvxfplyortj] has joined #c-lightning
04:57 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
05:21 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
05:25 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
05:25 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #c-lightning
05:38 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]
05:38 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
05:40 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]
05:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
06:13 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]
06:13 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
06:59 -!- liberliver1 [~Thunderbi@dynamic-089-012-226-086.89.12.pool.telefonica.de] has joined #c-lightning
07:01 -!- liberliver [~Thunderbi@x4dbf3f91.dyn.telefonica.de] has quit [Ping timeout: 258 seconds]
07:01 -!- liberliver1 is now known as liberliver
07:05 -!- kexkey [~kexkey@static-198-54-132-92.cust.tzulo.com] has joined #c-lightning
07:18 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-oxixcxvxfplyortj] has left #c-lightning []
07:18 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-oxixcxvxfplyortj] has joined #c-lightning
07:23 -!- SunGrass [b905a564@185.5.165.100] has joined #c-lightning
07:27 < SunGrass> I am trying to pay an invoice, but using `lightning-cli pay` I keep getting an error like `"code": 210, "message": "Ran out of routes to try after 58 attempts: see `paystatus`", ... ` which is strange to me as I know there is a path
07:29 < SunGrass> I can confirm that the path is there using `lightning-cli getroute`, so I dont really see why this is failing. I am using v0.9.3. Am I just an idiot doing it wrong? Or is this a common issue?
07:57 <@cdecker> Having a path, and the path having sufficient balances in the right direction are two different things
07:58 <@cdecker> As you can see from the output `pay` has tried 58 different paths with differing amounts and splits, but there simply was not enough capacity in the channels to transfer the entire amount
07:59 <@cdecker> Hence it chose to report a failure and let the user know that the payment is unlikely to ever succeed with the current balances
08:00 <@cdecker> fwiw `getroute` doesn't have balance information to compute a route, so it'll make decisions purely on the total capacity (sum of both endpoint's balance) and any information that we learnt while trying to pay (if we hit against the balance we remember and will only try with smaller parts for the remainder of the pay instance)
08:13 < SunGrass> But, I am trying to make a simple payment from Alice to Carol via Bob. All of them are my nodes and I happen to know the capacities are sufficient.
08:14 < SunGrass> Well, at least I was fairly sure ... I guess I need to try again
08:15 <@cdecker> If all these nodes are yours can you share `lightning-cli listpeers` outputs for all of them on a pastebin or as a new issue on Github? That way we could walk through the debugging steps together
08:22 < SunGrass> Thats a very nice offer, thank you. I cant do it right now though. Can you give me a hint what I would be looking for?
08:23 <@cdecker> My first step would have been to draw up the network graph on paper, annotate the balances in the channels, and then step through the payment manually. Usually these things end up being minor oversights.
08:26 < SunGrass> I see, I will try that myself when I get the time. Thanks a lot for the help.
08:26 <@cdecker> Anytime, let me know how it's going or if you need any hints
09:06 < SunGrass> Arh, so I think I have a clue. Looking at the `listpeers` result just now I see `"spendable_msatoshi": 0,` on the channel I was thinking would be the outgoing channel from A. I guess that could explain it. Although I dont fully understand, because there all the balance is on that side. The channel is very small though (600000sats). Maybe it is
09:06 < SunGrass> simply too small to make a payment work?
09:08 <@cdecker> 600k sats should be plenty to make some smaller payments, there isn't anything that would consume that much liquidity from your channels (there's the 1% reserve value + the onchain fee for the funder, these funds have to stay with the funder, but everything else should be possible to transfer).
09:09 <@cdecker> Are you capturing the logs? We might be able to get some more insight from those
09:10 < SunGrass> Unfortunately not. TBH, I rage quit and closed the channel :P
09:10 <@cdecker> Hm, then we can still try the paystatus command which lists each attempt that was made, and why it failed
09:13 < SunGrass> That just says:
09:13 < SunGrass> {
09:13 < SunGrass>                "strategy": "Initial attempt",
09:13 < SunGrass>                "start_time": "2021-02-03T16:40:14.873Z",
09:13 < SunGrass>                "age_in_seconds": 1867,
09:13 < SunGrass>                "end_time": "2021-02-03T16:40:15.024Z",
09:13 < SunGrass>                "failure": {
09:13 < SunGrass>                   "code": 205,
09:13 < SunGrass>                   "message": "Call to getroute: Could not find a route"
09:13 < SunGrass>                }
09:13 < SunGrass>             },
09:13 < SunGrass>             {
09:13 < SunGrass>                "strategy": "Still have 9 attempts left",
09:13 < SunGrass>                "start_time": "2021-02-03T16:40:15.024Z",
09:13 < SunGrass>                "age_in_seconds": 1866,
09:13 < SunGrass>                "end_time": "2021-02-03T16:40:15.127Z"
09:13 < SunGrass>             },
09:13 < SunGrass>             {
09:13 < SunGrass>                "start_time": "2021-02-03T16:40:15.127Z",
09:13 < SunGrass>                "age_in_seconds": 1866,
09:13 <@cdecker> Yeah, don't paste it here, you're going to get kicked by freenode
09:14 < SunGrass> Uh, sorry
09:14 <@cdecker> This is a good place to paste things: https://0bin.net/
09:15 < SunGrass> My point was it just repeats this over and over from "strategy": "Still have 9 attempts left"
09:15 <@cdecker> Hm, that's indeed not very helpful
09:15 < SunGrass> and then something about: "message": "Call to getroute: Could not find a route"
09:16 <@cdecker> It should have split the payment into 2 parts after that initial attempt which failed to find a route
09:17 < SunGrass> Actually this last message is mysterious because, as I said, `getroute` does in fact find a route. But maybe I am misinterpreting.
09:17 <@cdecker> So those are the results from internal `getroute` calls with channels that we know dont have sufficient balance excluded. The usual response to that is to either split or give up
09:18 <@cdecker> That includes by the way our local channels: if you are A and have a channel funded by B to A, then A will exclude the A->B channel because all the capacity is on B's side (A cannot transfer anything if only B has funds in the channel)
09:21 < SunGrass> Wait, I misspoke before, that channel A->B had a capacity of 60,000sats not 600,000sats.
09:22 <@cdecker> Still shouldn
09:22 <@cdecker> t be a problem
09:22 <@cdecker> Fees are not that high atm (or 1/2 hour ago which paystatus indicates is the time you tried)
09:24 < SunGrass> Ok, then its strange again. I specifically set up the channels so that A funds a channel to be with 60,000sats, C funded a channel with B of 100,000sats and C sends 50,000 sats to B. So if I am understanding correctly capacities/balances should not be an issue.
09:26 < SunGrass> Sorry i meant "A funds a channel to B with 60,000sats"
09:26 <@cdecker> Could it be that you sent 50k millisatoshis when you were intending to send 50k satoshis when rebalancing the channel C->B? That'd be a common mistake since on-chain we use satoshis, whereas off-chain we use millisatoshis
09:28 < SunGrass> No, I specifically send the 50,000sats, because I wanted to channel to be perfectly balanced and checked this was the case (using the summary plugin)
09:28 <@cdecker> Hm, that's strange indeed then
09:29 < SunGrass> Why would the `listpeers` call indicate `spendable_msatoshi` to be 0 btw.?
09:31 <@cdecker> It computes the amount based on how many funds you have on your side, then subtract the on-chain fee (commitment transaction + HTLC transactions) or the reserve if that is larger. So it might actually be that the fees were too high and the funder (A) could not add an HTLC without having to dip into the on-chain fee reserve
09:31 <@cdecker> This all gets a lot easier once we have anchor-outputs which are currently being specced btw, since that removes the need to keep fees ready
09:32 < SunGrass> That sounds like a relief
09:32 <@cdecker> Yeah, the on-chain fees have always been a major pain. Still not as seamless as eltoo would have them, but getting closer to it
09:32 < SunGrass> precomputing fees must be hard. In particular with unusually large fees as of recently.
09:33 <@cdecker> Not computationally hard, but painful since it means we cannot use some of the liquidity allocated to channels, yes
09:33 < SunGrass> Anyway, I am leaning towards this explanation. I will try some other time with a larger channel.
09:34 <@cdecker> Sounds good, sorry I couldn't be of more help, but if you have any more information/questions let me know ^^
09:34 < SunGrass> Thank you so much. I really appreciate you taking the time.
09:51 -!- SunGrass [b905a564@185.5.165.100] has quit [Quit: Ping timeout (120 seconds)]
10:18 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #c-lightning
11:02 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
11:03 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #c-lightning
13:24 -!- liberliver [~Thunderbi@dynamic-089-012-226-086.89.12.pool.telefonica.de] has quit [Quit: liberliver]
13:24 -!- liberliver1 [~Thunderbi@dynamic-089-012-226-086.89.12.pool.telefonica.de] has joined #c-lightning
13:29 -!- liberliver1 [~Thunderbi@dynamic-089-012-226-086.89.12.pool.telefonica.de] has quit [Ping timeout: 276 seconds]
13:56 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]
13:56 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
14:03 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #c-lightning
14:11 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]
14:11 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
14:14 -!- satolite [~az0re@gateway/tor-sasl/az0re] has joined #c-lightning
14:14 -!- satolite [~az0re@gateway/tor-sasl/az0re] has quit [Client Quit]
14:16 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has quit [Quit: Lost terminal]
14:19 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Ping timeout: 268 seconds]
14:19 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #c-lightning
14:26 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services]
14:26 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
14:26 -!- vasild_ is now known as vasild
14:27 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Quit: Leaving]
15:31 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-oxixcxvxfplyortj] has left #c-lightning []
15:31 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-oxixcxvxfplyortj] has joined #c-lightning
16:35 -!- queip [~queip@unaffiliated/rezurus] has joined #c-lightning
17:11 -!- sr_gi [~sr_gi@static-6-109-229-77.ipcom.comunitel.net] has quit [Ping timeout: 256 seconds]
17:17 -!- sr_gi [~sr_gi@static-125-62-230-77.ipcom.comunitel.net] has joined #c-lightning
17:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
17:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #c-lightning []
17:58 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #c-lightning
18:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
20:23 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
22:01 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
22:01 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #c-lightning
23:28 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
23:28 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
23:47 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-oxixcxvxfplyortj] has left #c-lightning []
23:48 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-oxixcxvxfplyortj] has joined #c-lightning
--- Log closed Thu Feb 04 00:00:35 2021