--- Log opened Fri Aug 28 00:00:01 2020
00:00 -!- jonatack [~jon@37.164.15.34] has joined #c-lightning
00:52 -!- liberliver [~Thunderbi@2a01:c23:5c46:bc00:a2af:bdff:fe37:2d32] has joined #c-lightning
01:17 -!- sr_gi [~sr_gi@static-75-213-224-77.ipcom.comunitel.net] has joined #c-lightning
02:02 < m-schmoock> hmm.... so chained plugin hooks are called in parallel :D  just found that out by writing my tests which were not getting stable. Always thought the plugins are asked one by one
02:03 < m-schmoock> anyway, thats a solvable challenge
02:04 -!- kexkey [~kexkey@89.36.78.166] has quit [Ping timeout: 265 seconds]
02:05 < m-schmoock> I think the hook code is done, its now just how to test precise correct behaviour which is a bit troublesome if we cant make predictions on what plugin gets called first
02:07 -!- jonatack [~jon@37.164.15.34] has quit [Read error: Connection reset by peer]
02:39 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning
03:14 <@cdecker> Wait what? They should not get called in parallel, that was not how I designed the hooks...
03:26 < m-schmoock> hm
03:29 < m-schmoock> sometimes my test fails because plugin 3 in the hook got deserialized first
03:29 < m-schmoock> maybe the execution is serial but the order is undefined?
03:30 <@cdecker> Should be the same order the plugins were registered
03:30 <@cdecker> (unless someone changed the semantics of the hooks...)
03:30 < m-schmoock> i.e. my logs can be:
03:30 < m-schmoock> b'2020-08-28T08:52:08.232Z INFO plugin-openchannel_hook_reject.py: reject on principle'
03:30 < m-schmoock> b"2020-08-28T08:52:08.232Z DEBUG lightningd: openchannel_hook rejetcs and says 'reject on principle'"
03:30 < m-schmoock> b'2020-08-28T08:52:08.233Z INFO plugin-openchannel_hook_accept.py: accept on principle'
03:30 < m-schmoock> b'2020-08-28T08:52:08.233Z INFO plugin-openchannel_hook_accepter.py: reject for a reason'
03:30 < m-schmoock> which should not be possible when the order is defined 
03:31 < m-schmoock> not sure if you looked at the testcase
03:31 <@cdecker> Not yet, but on mytodo list for today
03:32 < m-schmoock> cdecker: should I add a  not_in_log() function to the test utils?
03:32 < m-schmoock> currently I need to raise into a timeout to check thath
03:33 <@cdecker> What's wrong with `not l1.daemon.is_in_log`?
03:33 < m-schmoock> actually nothing :D
03:34 < m-schmoock> I think that was because I was missing the start offset in that function before
03:34 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 244 seconds]
03:34 < m-schmoock> what I needed (once) was a not_in_log() with a start offset
03:35 <@cdecker> Right, kind of ugly that wait_for_log, is_in_log etc, have hidden state (offset)
03:36 < m-schmoock> should we have a stateful is_in_log() as well called maybe  was_in_log()  or something
03:37 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #c-lightning
03:37 < m-schmoock> also my change seems to have valgrind issue
03:37 < m-schmoock> maybe I fix that first
03:38 < m-schmoock> because that can cause unstable behaviour
03:46 < m-schmoock> cdecker: wait with a review until I'm done with valgrind issue
03:51 <@cdecker> Gotcha
03:59 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
04:00 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
04:04 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 260 seconds]
04:09 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
04:13 -!- queip [~queip@unaffiliated/rezurus] has joined #c-lightning
04:14 < m-schmoock> cdecker: the is_in_log()  has a start offset feature, but theres no way to get the pointer result of the last is_in_log() result to utilize that
04:14 < m-schmoock> should is_in_log return the log position instead of the matched log?
04:15 < m-schmoock> alternatively we can add a was_in_log that uses an internal state lite wait_for_logs
04:17 < m-schmoock> *like
04:18 < m-schmoock> it could use the same state `logsearch_start` var
04:32 <@cdecker> Yeah, currently the caller has to reach into the daemon log index to get the current position (which makes this super weird), but ideally it'd return a wrapper object that we can still treat like a string, but also has the offset annotation
04:33 <@cdecker> That way we'd hopefully not break any existing callers, but allow for future users to extract that kind of information
04:33 < m-schmoock> why not att a was_in_log that does exactly that like wait_for_logs but without the waiting?
04:33 < m-schmoock> *Add
04:34 < m-schmoock> anyway, theres a bit room for improvement :D
06:30 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
06:53 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning []
06:53 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning
06:54 -!- shesek [~shesek@unaffiliated/shesek] has joined #c-lightning
07:08 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
07:08 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
07:08 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
07:08 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
07:18 < darosior> Got a weird error with latest lightningd and sauron: error: bad response to estimatefees (bad 'result' field), response was {"jsonrpc": "2.0", "id": 7, "error": {"code": -32600, "message": "Error while processing estimatefees: '5'"}}
07:18 < darosior> Although the request is {\"jsonrpc\":\"2.0\",\"id\":7,\"method\":\"estimatefees\",\"params\":{}}
07:28 < darosior> Why did we drop io logging of incoming commands to plugins ? Or didn't we have it ?
07:30 < zmnscpxj> -32600 is invalid request.  Seems some weird data was pushed into the socket somewhere somehow?
07:31 < zmnscpxj> "Error while processing" seems to be in pyln-client code, so you are using a python plugin, and it is the python plugin which is failing?
07:31 < darosior> Yep, sauron is the Python Bitcoin backend for Esplora
07:32 < darosior> Debugging it currently (restored the possibility to log as IO for plugins..)
07:33 < zmnscpxj> looks like something in the sauron code? this triggers in set_exception method
07:34 < zmnscpxj> Which is either an exception being raised in Python, or explicitly called if the Python code is written as callback/async
07:36 < darosior> Yep, but this 5 is weird as we normally log the actual exception
07:37 < zmnscpxj> nothing prevents Python from throwing a string containing the text '5'?
07:39 < zmnscpxj> hmmm, we lift the exception to a string via `str(exc)`.
07:39 < zmnscpxj> maybe it is some custom exception that overrides `__string__`?
07:40 < zmnscpxj> `__str__` I mean
07:43 < darosior> Hmm yeah but the sauron code did not change much... I already reverted cdecker's last change and i still experience the same error. Hmmm
07:45 < darosior> Got it
07:45 < zmnscpxj> what was it?
07:46 < darosior> Lol the API of blockstream.info unexpectedly change, and stopped returning estimates for a 5 blocks target
07:46 < darosior> And... I was assuming it would not change
07:46 < zmnscpxj> ok lol
07:46 <@cdecker> LOL, so a NoSuchKeyError :-)
07:46 < darosior> Precisely :)
07:46 <@cdecker> Whose content really is the key that you were looking for ^^
07:46 < zmnscpxj> NoSuchKeyError stringifies to the key?
07:47 < zmnscpxj> lol
07:47 < darosior> But without the actual exceptiono name
07:47 < zmnscpxj> haha
07:47 < darosior> Now that we know "what", going to look for "WHY?" ^^
07:48 < darosior> Ok, nice it actually works on mainnet
07:48 < darosior> https://blockstream.info/api/fee-estimates
07:48 < darosior> But on testnet the API is different https://blockstream.info/testnet/api/fee-estimates
07:51 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
08:23 <@cdecker> fwiw I think whatever is deployed for testnet will later roll out to the mainnet instance, so we can use the testnet version to make sure we don't break in the future. If testnet broke we should address it for both networks
08:28 -!- melande1 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
08:29 -!- melande1 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
08:32 -!- kexkey [~kexkey@89.36.78.166] has joined #c-lightning
08:38 < darosior> I don't think so, I think it's just that fee estimation buckets are not filled for testnet and that they don't return the field instead of returning `null` https://github.com/lightningd/plugins/pull/142
08:39 < darosior> But i asked shesek in MP
08:40 <@cdecker> Great, thanks for checking
08:49 <@cdecker> I managed to totally overwhelm Travis with my plugin fix PRs...
09:03 -!- melande1 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
09:03 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
09:14 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
09:15 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
09:16 < darosior> Achievement unlocked
09:17 <@cdecker> Ok, officially giving up on coverage inside of plugins, the coverage stuff is clobbering itself all the time or not flushing to disk on travis
09:17 <@cdecker> Too bad, it was a neat idea, but getting it to work reliably is frustrating as hell :-)
09:24 < darosior> Btw did you already try Github actions ?
09:25 < darosior> They are *great* (at least from my experience, way better ux with GA than Travis)
09:40 -!- vincenzopalazzo [~vincent@host-79-26-113-47.retail.telecomitalia.it] has joined #c-lightning
09:50 <@cdecker> Yeah, might want to migrate sooner or later, but need to find some time to do that :-)
10:08 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
10:10 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
10:13 < shesek> cdecker, darosior, the fee estimation api skips targets when there's not enough information to provide an estimate. its a known limitation that esplora loses its fee_estimates.dat data when re-deploying, which makes fee estimation temporarily unavailable, which is probably the cause that they're currently unavailable on testnet.
10:14 < shesek> (there's a mechanism in place for fetching the mempool.dat from a live instance when a new instance is deployed, but its not possible for the fee_estimates because there's no rpc command to persist it to disk like for the mempool)
10:17 < darosior> Thanks for the head up shesek !
10:20 < shesek> if someone wants to PR a "savefeeestimates" rpc to bitcoin core, I could fix this. :)
10:22 < darosior> #shesekfixesthis
10:23 < darosior> I've been touching the fee estimation quite a lot, if there is conceptual ACK i could give it a shot
10:23 < darosior> Do you have an open ticket ?
10:30 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #c-lightning
10:32 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
10:32 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
10:33 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
11:15 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
11:17 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
11:34 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
11:50 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
12:04 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
12:05 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
12:44 -!- liberliver1 [~Thunderbi@2a01:c22:ac19:500:a2af:bdff:fe37:2d32] has joined #c-lightning
12:45 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
12:46 -!- liberliver [~Thunderbi@2a01:c23:5c46:bc00:a2af:bdff:fe37:2d32] has quit [Ping timeout: 260 seconds]
12:46 -!- liberliver1 is now known as liberliver
13:26 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
13:27 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
13:30 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
13:31 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
14:03 -!- lxer [~lx@ip5f5bf473.dynamic.kabel-deutschland.de] has joined #c-lightning
14:11 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
14:11 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
15:09 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning []
15:09 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning
15:26 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
15:27 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
15:41 -!- lxer [~lx@ip5f5bf473.dynamic.kabel-deutschland.de] has quit [Ping timeout: 265 seconds]
15:55 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
15:57 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
15:58 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
16:00 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
16:00 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
16:01 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
16:31 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
16:32 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
17:14 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
17:17 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
17:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
17:39 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
18:15 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
18:16 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
18:20 < shesek> darosior, I thought that I saw a ticket for this some time ago, but I can't seem to find it now
18:20 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds]
18:21 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning
18:21 < shesek> I think that I probably misremembered
18:28 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
18:30 < shesek> hmm, giving this fee estimation issue some more thought, the longer block duration targets being available while the shorter ones aren't might indicate a different cause. its the longer durations that require more historical data to produce results, so not persisting feeestimates.dat should result in the exact opposite behavior
18:30 < shesek> I will investigate this some more
19:10 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
19:11 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
19:19 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 264 seconds]
20:01 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
20:02 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
20:03 -!- sr_gi [~sr_gi@static-75-213-224-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
20:03 -!- sr_gi [~sr_gi@static-75-213-224-77.ipcom.comunitel.net] has joined #c-lightning
20:16 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
20:19 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
20:41 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
21:22 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
21:23 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
22:02 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
22:03 -!- fiatjaf [~fiatjaf@2804:7f2:2a84:b2d3:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 240 seconds]
22:05 -!- fiatjaf [~fiatjaf@2804:7f2:2a84:b2d3:ea40:f2ff:fe85:d2dc] has joined #c-lightning
22:08 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
22:11 -!- kexkey [~kexkey@89.36.78.166] has quit [Ping timeout: 240 seconds]
22:12 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #c-lightning
22:18 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer]
22:18 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #c-lightning
22:24 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
22:25 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
22:53 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
23:27 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
23:28 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
23:31 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning []
23:31 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning
23:39 -!- melande2 [~melande@gateway/tor-sasl/melande] has quit [Remote host closed the connection]
23:40 -!- melande2 [~melande@gateway/tor-sasl/melande] has joined #c-lightning
--- Log closed Sat Aug 29 00:00:02 2020