--- Log opened Tue Mar 03 00:00:12 2020 01:04 -!- lxer [~lx@ip5f5bf497.dynamic.kabel-deutschland.de] has joined #c-lightning 01:10 < lxer> who maintains lightningd/plugins ? 01:25 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 255 seconds] 01:46 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 256 seconds] 02:10 -!- Kostenko [~Kostenko@2001:8a0:7286:5900:583a:3291:ac93:cc79] has quit [Read error: Connection reset by peer] 02:17 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning 02:27 -!- x7268 [~ralph@110.150.129.62] has joined #c-lightning 02:44 -!- Kostenko [~Kostenko@2001:8a0:7286:5900:583a:3291:ac93:cc79] has joined #c-lightning 02:56 -!- mrostecki [mrosteckim@gateway/shell/matrix.org/x-kkcxrbfncavbwkwi] has quit [Quit: killed] 03:08 -!- k3tan [~ketan@unaffiliated/k3tan] has quit [Quit: WeeChat 2.7.1] 03:09 -!- k3tan [~ketan@unaffiliated/k3tan] has joined #c-lightning 03:20 -!- mrostecki [mrosteckim@gateway/shell/matrix.org/x-oveubravhwuoyanj] has joined #c-lightning 03:22 <@cdecker> lxer: I do :-) 03:22 <@cdecker> Need to merge a couple of PRs sometime this week 03:34 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has left #c-lightning [] 03:34 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has joined #c-lightning 03:41 -!- MasterdonX [~masterdon@45.64.186.133] has quit [Ping timeout: 256 seconds] 03:41 -!- MasterdonX [~masterdon@152.89.160.212] has joined #c-lightning 05:23 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 06:00 -!- rafalcpp [~racalcppp@ip-178-211.ists.pl] has quit [Read error: Connection reset by peer] 06:00 -!- rafalcpp_ [~racalcppp@ip-178-211.ists.pl] has joined #c-lightning 06:17 < darosior> fiatjaf: re bitcoin backend here is an example https://github.com/lightningd/plugins/pull/89 06:19 < darosior> cdecker: re https://github.com/ElementsProject/lightning/pull/3560 => I really start to think rpc_command wasn't a good idea.. 06:19 < zmnscpxj> too powerful? 06:19 < darosior> If we break the API anyway maybe we could just drop it ? 06:20 < darosior> zmnscpxj: I don't see any usecase actually 06:20 < darosior> I pushed it for wallet locking which turned out to be a bad idea for a plugin 06:20 < zmnscpxj> Monitoring use of `pay`, for example you could monitor how many times it is used, success rates, and so on. 06:21 < zmnscpxj> Or maybe monitor `sendpay` instead. 06:21 < darosior> Yeah 06:21 < zmnscpxj> Though monitoring *can* be done with just a notification 06:21 < darosior> Yep exactly there is sendpay_success / failure notifs for this 06:22 < zmnscpxj> In theory, you could also modify or decorate how the bitcoin backend works as well 06:22 < zmnscpxj> for example, you could have a plugin that also sends transactions by other means, by hacking `sendrawtx` 06:23 < zmnscpxj> or replace built-in commands 06:23 < zmnscpxj> e.g. replace `getroute`. 06:24 < zmnscpxj> it can do a lot of things, so we should probably restrict it or remove it, because Principle of Least Power 06:25 < zmnscpxj> Or make it more powerful by letting it hook-chain as well. 06:25 < zmnscpxj> because evil 06:25 < zmnscpxj> oops 06:25 < zmnscpxj> please do not read that 06:25 < zmnscpxj> ZmnSCPxj is a good human being. 06:32 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #c-lightning 06:35 < darosior> Oh that becomes interesting :D 06:35 < darosior> Ok I withdraw my request to remove it, if there are only good human beings using it :p 06:53 -!- kexkey [~kexkey@37.120.205.237] has joined #c-lightning 07:02 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds] 07:04 -!- jonatack [~jon@37.171.106.95] has joined #c-lightning 08:03 < vasild> darosior: during startup, if bcli cannot connect to bitcoind it would print a diagnostic on stderr and hang, not detaching from the terminal, even if lightningd --daemon is used 08:04 < vasild> is thig intended? 08:04 < vasild> seems to contradict with: 08:04 < vasild> --daemon Run in the background, suppress 08:04 < vasild> stdout/stderr 08:04 < zmnscpxj> maybe it should fail immediately? What was pre-0.8.1 behavior 08:04 < zmnscpxj> ? 08:05 < vasild> yes, either fail or keep retrying in the background (with diagnostics going to the log file). Good question - I do not know what pre-0.8.1 did, need to test 08:06 < vasild> I noticed this because during OS boot, when c-lightning is started from rc scripts, the current behavior hangs the entire OS boot process 08:20 < vasild> 0.8.0 would print the same diagnostic to stderr and would exit with status 1 08:20 < zmnscpxj> well, that is what we should probably do then. 08:25 < vasild> At least this, yes, to avoid hanging the OS boot. But I think there are two things that can be improved: never print to stdout/stderr when --daemon is given -- nobody will see those messages during e.g. OS boot on a remote server, whereas the log file can be easily inspected. And second - keep retrying for some time in the background to connect to bitcoind. 08:26 < zmnscpxj> What we do with --daemon is that we do not have the parent process exit immediately --- instead we keep the parent alive until the forked daemon child confirms initialization okay. 08:26 < zmnscpxj> if the child finds a problem, it reports to stderr and tells the parent to exit with a failure exit code 1 08:26 < vasild> hmm, maybe "never" is too strict - if we cannot fork() to detach from the terminal or cannot open the log file, then maybe printing to stderr is warranted 08:27 < zmnscpxj> the intent is that if you launch on the command line you immediately get informed of problems 08:27 < zmnscpxj> and in Linux, usually the startup is now systemd, which puts stdout/stderr in a log file accessible over journalctl 08:28 < vasild> well, ok, adjusting the --daemon description to not mention "suppress stdout/stderr" is also an option :) 08:28 < zmnscpxj> rc is the only option in BSD? 08:28 < zmnscpxj> or qualifying it with "after initialization", since we indeed do not print on stdout/stderr after the daemon child initializes 08:29 < vasild> yes 08:30 < vasild> "rc is the only option in BSD?" I do not know :-O, rc works fine for me. There is at least the classing inetd, maybe others too 08:31 < vasild> s/classing/classic/ 08:31 < zmnscpxj> well there is many option on Linux as well, though, everybody loves systemd now, non-lovers of systemd have now been forced to not exist 08:32 < vasild> :-D 08:32 < zmnscpxj> all hail systemd 08:32 < vasild> I think the current behavior would also hang the Linux systemd boot, right? 08:33 < zmnscpxj> yes as well 08:33 < zmnscpxj> if you make, say, multi-user or something dependent on lightningd.service 08:34 < zmnscpxj> if you do not make multi-user or some later target dependent on lightningd.service then lightningd.service is not started automatically 08:34 < zmnscpxj> so current behavior is bad, need to fix 08:34 < vasild> ack 08:35 < vasild> well, on freebsd I could workaround by not using the --daemon option, but to use the daemon(8) command https://www.freebsd.org/cgi/man.cgi?query=daemon and give it lightningd --options..., it will surely detach from the terminal 08:42 < vasild> https://github.com/ElementsProject/lightning/issues/3562 Do not hang at startup if cannot connect to bitcoind 08:43 < vasild> so that it does not get forgotten 08:43 < vasild> zmnscpxj: what about retrying in the background? 08:44 < zmnscpxj> the general sense is that it would be better, by default, to just fail hard 08:44 < zmnscpxj> the general assumption is that bitcoind is running in the same machine, so if bitcoind is not up, well, lightningd cannot be up either 08:45 < zmnscpxj> though now that we can replace bcli, in theory we could, for instance, have an alternative which retries in the background as well 08:46 < vasild> I wonder if during boot bitcoind is started and immediately after it c-lighting, would the bitcoind rpc be immediately available... 08:47 < zmnscpxj> it would not as well..... haha 08:47 < zmnscpxj> which is why lightningd does not let the parent exit immediately, it waits for its own RPC to be up before it lets the parent exit 08:47 < zmnscpxj> which is what systemd will consider as "the daemon has been started successfully" if the parent exited with 0 08:48 < zmnscpxj> I know I did some hackish thing on my setup, lemme dig.... 08:50 < vasild> so, bitcoind would detach and return 0 to the rc script, systemd or whatever, 0.0000001 seconds after that lightningd is started -- are you saying that lightnind may not be able to connect to bitcoind's rpc? 08:50 < zmnscpxj> https://zmnscpxj.github.io/activity/2020-01-30.html 08:50 < zmnscpxj> yes that can happen 08:50 < zmnscpxj> what I did was in that link 08:50 < vasild> so a retry in the background or foreground from lightningd is warranted 08:50 < zmnscpxj> I added an ExecStartPost entry to the bitcoind.service, which launches a simple script that just polls the bitcoin RPC until it succeeds 08:51 < zmnscpxj> but it affects all bitcoind-users, not just lightningd 08:51 < zmnscpxj> so bitcoind should be the one that changes, LOL 08:51 < zmnscpxj> in my case, I first noticed it when I made my JoinMarket maker a systemd daemon 08:52 < zmnscpxj> so either every bitcoind-using daemon polls, or we change the bitcoind.service so it does the polling before continuing the boot, which makes more sense to me 08:53 < zmnscpxj> and why do daemons exit their parents so fast anyway, it is not as if initialization is a timeless atomic action.... 08:54 < zmnscpxj> script should be portable to BSD as well, if you have some equivalent there. 08:56 < vasild> you did not consider modifying joinmarket to retry connecting to bitcoind rpc? :) 08:56 < zmnscpxj> Python code, so ---- 08:56 < zmnscpxj> hahahahahahaha 08:56 < vasild> :-D 08:59 < vasild> so you modified bitcoind startup script? 08:59 < zmnscpxj> yep 08:59 < vasild> hmm 08:59 < zmnscpxj> it benefits JoinMarket, ElectrumX, and LightningD, so ----- 09:21 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning 09:27 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning 09:34 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 255 seconds] 09:35 -!- jonatack [~jon@37.171.106.95] has quit [Read error: Connection reset by peer] 09:40 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning 10:18 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning 10:19 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Client Quit] 10:20 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds] 11:21 <@niftynei> darosior: one use case for the rpc_command hook is to always provide a close_to address for a channel 11:40 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #c-lightning 11:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 11:51 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has left #c-lightning [] 11:51 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has joined #c-lightning 11:58 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 12:07 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds] 12:22 < fiatjaf> darosior, zmnscpxj: I wrote a plugin that monitors sendpay calls and saves them. 12:22 < fiatjaf> https://github.com/fiatjaf/lightningd-gjson-rpc/tree/72f8541eea17e209eb21f3d2d82286a3242f7ba5/cmd/routetracker 12:22 < fiatjaf> but it's not very good as it saves routes even if they fail 12:23 < fiatjaf> I'm not writing a plugin that uses rpc_command to replace the getroute method with my custom routing logic 12:23 < fiatjaf> that will hopefully be able to use unannounced channels 12:29 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 12:39 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 12:43 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning 13:22 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 13:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit] 13:34 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds] 14:11 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 14:32 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 255 seconds] 14:53 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning 15:20 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning 15:23 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds] 15:30 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning 15:32 -!- rafalcpp_ [~racalcppp@ip-178-211.ists.pl] has quit [Excess Flood] 15:33 -!- rafalcpp_ [~racalcppp@ip-178-211.ists.pl] has joined #c-lightning 15:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning 16:02 -!- lxer [~lx@ip5f5bf497.dynamic.kabel-deutschland.de] has quit [Quit: Lost terminal] 16:08 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #c-lightning 16:11 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 16:44 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds] 16:52 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning 17:16 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning 17:27 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 17:50 < fiatjaf> how dumb would it be to use DFS for lightning routes? 19:37 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning 19:38 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 19:39 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 19:42 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #c-lightning 19:57 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has left #c-lightning [] 19:57 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zkjjaoqsjfattawp] has joined #c-lightning 20:01 < rusty> fiatjaf: ... not insane, but it might still have the "if you have to ask for directions, I know where you're going" problem? 20:08 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 272 seconds] 20:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 20:41 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer] 21:01 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds] 21:32 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning 22:31 -!- asoltys [~root@s207-81-214-2.bc.hsia.telus.net] has joined #c-lightning 22:58 -!- Kostenko [~Kostenko@2001:8a0:7286:5900:583a:3291:ac93:cc79] has quit [Ping timeout: 256 seconds] 23:12 -!- Kostenko [~Kostenko@2001:8a0:7299:1300:9318:2d6f:2006:e26b] has joined #c-lightning 23:17 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning 23:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 23:45 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning --- Log closed Wed Mar 04 00:00:12 2020