--- Log opened Mon Jul 05 00:00:57 2021 00:47 -!- rusty [~rusty@203.221.41.134] has quit [Ping timeout: 272 seconds] 00:55 -!- reallll is now known as belcher 00:57 -!- lxer [~lx@ip5f5bf666.dynamic.kabel-deutschland.de] has joined #c-lightning 02:35 < aechu> c-lighting crashed due to the pay plugin crashing. Can I safely report the stacktrace on github without leaking private information? I see a lot of hexadecimal numbers before the method names, do they mean anything? 02:36 < cdecker[m]> Yep, we should never print any keys or secrets, and the stacktrace is safe for sure (it just contains a list of call points that are static in the binary). If you're unsure feel free to encrypt and share privately with the devs 02:42 < aechu> https://pastebin.pl/view/raw/0a16dc97 02:45 < aechu> I posted the stacktrace in a paste with 1 week expiry, hope it helps! 02:50 < cdecker[m]> Looks like that is reported and tracked as #4461 (https://github.com/ElementsProject/lightning/issues/4461) and a potential fix in #4581 (https://github.com/ElementsProject/lightning/pull/4581) though I'll need to look into whether they are the same 02:57 < cdecker[m]> Do you happen to have any logs that indicate we dropped a routehint somewhere? 03:01 < aechu> I'm not sure what to look for in that regard, but I'm not seeing anything obvious like that. There are a lot of "no path found", and the payment is split up. And I see that the cltv is too large many times. 03:02 < aechu> And also fee is too large 03:03 < cdecker[m]> Yeah, fee too large is us being noisy when filtering ludicrous channels, we tuned that down for the next release. 03:04 < cdecker[m]> You can likely just `grep -i routehint logfile` that'll show all logs related to routehints 03:07 -!- kon__ [~kon@p200300d4a714b100f8a2d4fa720343b3.dip0.t-ipconnect.de] has joined #c-lightning 03:08 < aechu> I can't see a single entry for routehint in the logfile 03:11 < cdecker[m]> Probably just saying that one is being used then, was wondering if we were modifying the array on the fly which could lead us to accessing an uninitialized member 03:11 < cdecker[m]> Will dig deeper 03:12 -!- kon__ [~kon@p200300d4a714b100f8a2d4fa720343b3.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 03:13 -!- kon__ [~kon@p50882d99.dip0.t-ipconnect.de] has joined #c-lightning 03:16 -!- rusty [~rusty@103.93.169.121] has joined #c-lightning 04:07 < aechu> is there a way to avoid lightning-cli pay from splitting up the payment? It seems that regardless of the size of the invoice, it gets split up 04:08 < cdecker[m]> It splits at two different levels: presplit splits the amount roughly equal sized chunks (above a certain size) so all payments look the same, and adaptive splitting where we split based on what we learn in the network. Adaptive splitting is required for large payments to work at all, while presplit is a privacy enhancement (and a speedup) 04:08 < cdecker[m]> Currently you can't disable them unless you fork the pay plugin 04:10 < aechu> I see. So if the recipient has more than 1 channel, it's impossible to route everything through just 1? 04:20 < cdecker[m]> It's possible if you're ok with dropping one level lower to the `sendpay` API instead of allowing `pay` to compute and track HTLCs. It gives you full control over what happens and what routes are taken, so lilely you want to use that. `pay` is the high-level API for users that don't need that kind of control. 04:23 < aechu> that's great, thank you! 04:26 -!- lxer [~lx@ip5f5bf666.dynamic.kabel-deutschland.de] has quit [Ping timeout: 252 seconds] 04:28 -!- jasan [~j@tunnel625336-pt.tunnel.tserv1.bud1.ipv6.he.net] has quit [Quit: jasan] 04:42 -!- rusty [~rusty@103.93.169.121] has quit [Quit: Leaving.] 04:42 -!- rusty [~rusty@103.93.169.121] has joined #c-lightning 04:47 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 252 seconds] 05:11 -!- jasan [~j@tunnel625336-pt.tunnel.tserv1.bud1.ipv6.he.net] has joined #c-lightning 05:34 < aechu> how should I pass the route argument to the sendpay api? Would it work if I issue `lightning-cli sendpay -k route="[....],[....]" payment_hash=....` ? 05:41 -!- kanzure [~kanzure@user/kanzure] has joined #c-lightning 05:46 -!- _aj__ is now known as _aj_ 05:47 -!- _aj_ [aj@cerulean.erisian.com.au] has quit [Changing host] 05:47 -!- _aj_ [aj@user/aj/x-5857768] has joined #c-lightning 06:03 < aechu> sorry to bother you. I managed to issue the command now, but I keep getting WIRE_TEMPORARY_CHANNEL_FAILURE. Is there something I can do about it? Or a way to see more details on the failure? 06:07 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has quit [Quit: ZNC 1.8.0 - https://znc.in] 06:18 < darosior> aechu: means that a node on your route is unable to forward the payment (either it doesn't have sufficient liquidity on its end, or next one on the path is down). There is nothing you can do as nodes are free to not maintain decent liquidity or to not stay up. Generally it's tried to not have too specific errors to (try to) prevent too effective 06:18 < darosior> probing. 06:28 < aechu> darosior: I see. That makes sense. So even though getroute provides a route, it doesn't mean that the route will actually work? Any suggestions on what I should do to get the payment through? Would it help to try a smaller payment? 06:30 < darosior> Basically what `pay` is doing :p. Try all possible routes (possibly by splitting the payment in multiple parts): there are different methods there, and we can't yet know which one is the best 06:34 < darosior> The JIT and rebalance plugin may give simpler instances of sendpay usages, i think 06:34 * darosior (does `rebalance` still use sendpay actually?) 06:36 < aechu> I see.. pay wasn't working for me either, so I must have some bad channels 07:09 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection] 07:10 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #c-lightning 07:36 -!- lxer [~lx@ip5f5bf666.dynamic.kabel-deutschland.de] has joined #c-lightning 08:09 -!- ufotofu [~ufotofu@155.138.192.175] has quit [Changing host] 08:09 -!- ufotofu [~ufotofu@user/ufotofu] has joined #c-lightning 08:40 < aechu> would it be possible to close a channel setting my own fee suggestion? the estimates are suggesting over 3000 perkb but the mempool is clearing 1000 sat/vB transactions now 09:05 < nathanael> aechu: hmm, i am reading lightning-feerates(7) and it says for commans like lightning-withdraw(7) or lightning-fundchannel(7) you can provide preferred feerates, but it says nothing about closing a channel 09:05 < nathanael> i am interested in that too 09:45 < nathanael> just got `feerate estimate for min_acceptable hit floor 253` in my debug logs 09:51 < cdecker[m]> Closing is special because it requires that both parties agree to the feerate, so there is no way to unilaterally just set a feerate 09:59 -!- rusty [~rusty@103.93.169.121] has joined #c-lightning 10:03 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 240 seconds] 10:03 < nathanael> cdecker[m]: even if both parties know each other? 10:05 < nathanael> (sorry i guess thats why you wrote unilaterally) 10:05 < nathanael> is it then possible to set a "starting" fee? 10:09 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 10:40 < fiatjaf> nathanael: in theory if both parties agree they can do anything with the funds that are in a channel, in practice only what is described in the protocol 10:44 < nathanael> fiatjaf: reading the bolts is on my list 10:45 < fiatjaf> nathanael: no need to read them, just read the c-lightning docs 10:45 < nathanael> that too 10:47 < nathanael> my lightning node finished syncing, now i am unsure about setting up tor or just use the clearnet 11:35 -!- Netsplit *.net <-> *.split quits: sword_smith, ufotofu, michaelfolkson, niftynei, _aj_, gijswijs, willcl_ark 11:40 -!- Netsplit over, joins: willcl_ark, michaelfolkson, _aj_, ufotofu, gijswijs, niftynei, sword_smith 11:59 < darosior> Re the closing fee it's been a requested feature to be able to set the starting bid. See the issue tracker for discussions 12:46 -!- rusty [~rusty@103.93.169.121] has joined #c-lightning 14:17 -!- kon__ [~kon@p50882d99.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 14:27 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning 15:23 -!- lxer [~lx@ip5f5bf666.dynamic.kabel-deutschland.de] has quit [Ping timeout: 252 seconds] 16:43 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 252 seconds] 16:46 -!- rusty [~rusty@103.93.169.121] has joined #c-lightning 16:47 -!- aechu [~major@gateway/tor-sasl/major] has quit [Ping timeout: 244 seconds] 16:48 -!- aechu [~major@gateway/tor-sasl/major] has joined #c-lightning 17:08 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 240 seconds] 17:25 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 268 seconds] 17:38 -!- belcher [~belcher@user/belcher] has joined #c-lightning 21:06 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #c-lightning 21:07 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 244 seconds] 23:52 -!- jasan [~j@tunnel625336-pt.tunnel.tserv1.bud1.ipv6.he.net] has quit [Ping timeout: 246 seconds] 23:54 -!- rusty [~rusty@103.93.169.121] has joined #c-lightning 23:55 -!- jasan [~j@adsl-dyn213.78-98-68.t-com.sk] has joined #c-lightning --- Log closed Tue Jul 06 00:00:58 2021