--- Log opened Tue May 28 00:00:25 2019
00:50 -!- darosior [6dbe8dc1@gateway/web/freenode/ip.109.190.141.193] has joined #c-lightning
01:23 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
01:36 < m-schmoock> cdecker: what exact meanings does the listchannels attribue  channel['active'] have. Can I use it to filter locally connected channels that are know to be currently offline? Or do I have to use the listpeers peer['connected'] attribute for this?
01:46 -!- ulrichard [~richi@dzcpe6300borminfo01-e0.static-hfc.datazug.ch] has joined #c-lightning
02:16 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined #c-lightning
02:17 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 256 seconds]
02:26 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
03:11 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
03:11 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
03:20 -!- spinza [~spin@155.93.246.187] has joined #c-lightning
03:48 <@cdecker> m-schmoock: active means that the channel is not disabled, i.e., it was confirmed, has capacity, is connected (for nodes that announce disconnections) and isn't shutting down yet
03:56 -!- spinza [~spin@155.93.246.187] has quit [Ping timeout: 268 seconds]
04:40 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #c-lightning
04:47 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #c-lightning
05:16 -!- ghost43_ is now known as ghost43
05:57 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has quit [Ping timeout: 248 seconds]
06:00 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has joined #c-lightning
06:05 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has quit [Ping timeout: 244 seconds]
06:06 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has joined #c-lightning
06:38 < m-schmoock> cdecker: thx. so when a remote channel has an offline peer, the other one will update it to 'active' = False ?
06:49 <@cdecker> It should
06:50 <@cdecker> To clarify: if A and B have a channel open, and B goes offline, then A will mark the direction A->B as disabled and may send an update telling about that to the network
06:51 < m-schmoock> ah, so node will still try to use B->A ß
06:51 < m-schmoock> or is at least the CLN router 'smart enough' to guess that the other directio will also be inactive?
06:54 <@cdecker> Yep, if B doesn't send a disabling update that direction is still active, but if you think one step further you'll see that you should not have any way of reaching B in a route in the first place
06:55 <@cdecker> That would require a node C exists, that is the previous hop in the route that still forwards a payment to B
06:55 <@cdecker> But C should have disabled as well
06:55 <@cdecker> Due to broadcast timing it isn't really this clear cut, but worst thing that happens is that the payment reaches B or C which fails it immediately
07:34 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #c-lightning
07:59 -!- ulrichard [~richi@dzcpe6300borminfo01-e0.static-hfc.datazug.ch] has quit [Remote host closed the connection]
08:58 -!- trueptolemy [2e11295f@gateway/web/freenode/ip.46.17.41.95] has joined #c-lightning
09:06 -!- trueptolemy [2e11295f@gateway/web/freenode/ip.46.17.41.95] has quit [Ping timeout: 256 seconds]
09:07 -!- trueptolemy [2e11295f@gateway/web/freenode/ip.46.17.41.95] has joined #c-lightning
09:09 < trueptolemy> cdecker: how do you think that if we can only load one sig(node sig/ coin sig) from DB?
09:12 < trueptolemy> should we treat this case as internal error by calling channel_internal_error()? or just ignore this error and wait for new announce sigs to save
09:13 <@cdecker> We should probably just forget the signatures and hope they send new ones
09:13 <@cdecker> It's not a critical failure and not worth it to spend onchain funds over
09:14 <@cdecker> (also it is unlikely to ever happen since we make sure to set them both in the setter, my comment is mostly for defense in depth and future cases where this pattern is really insecure)
09:14 < trueptolemy> thank you! your reply is in time and so quickly :)
09:15 < trueptolemy> and another question: tal_free NULL is invalid?
09:18 < darosior> trueptolemy:  * tal_free - free a tal-allocated pointer.  * @p: NULL, or tal allocated object to free.
09:19 < darosior> ccan/ccan/tal/tal.h
09:19 < darosior> ;)
09:19 <@cdecker> :-)
09:19 -!- darosior [6dbe8dc1@gateway/web/freenode/ip.109.190.141.193] has quit [Quit: Page closed]
09:23 < trueptolemy> darosior: Thank you :) 
09:25 -!- booyah_ is now known as booyah
09:26 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Quit: WeeChat 2.4]
10:30 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
10:51 < trueptolemy> cdecker: ping :-) ...I changed the load func and now pr#2619 passes Travis CI
11:46 < trueptolemy> quit
11:46 -!- trueptolemy [2e11295f@gateway/web/freenode/ip.46.17.41.95] has quit [Quit: Page closed]
12:02 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has joined #c-lightning
12:26 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #c-lightning
12:55 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
12:59 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
13:01 -!- nibbier [~quassel@mx01.geekbox.info] has joined #c-lightning
13:04 < nibbier> hi again. I was here about this problem once before, my clightningd does start, launches a bunch of sub processes, but then continues to do nothing. here is debug log level: https://pastebin.com/xw17RG5U
13:06 < nibbier> strace -p 2797 -f: restart_syscall(<... resuming interrupted restart_syscall ...>   -  and that's it, stays there for ages. 9735/tcp stays closed, lightning-cli can't connect either
13:09 < nibbier> all processes seem to be sleeping
13:11 < nibbier> I had this before 0.7.0, upgraded to 0.7.0 and now to latest git.... 
13:16 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 252 seconds]
13:21 < nibbier> and every new start of clightningd sets last_processed_block back by 15 blocks
13:33 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #c-lightning
13:43 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has joined #c-lightning
13:56 -!- cltrbreak_MAD2 [~ctrlbreak@156.34.88.119] has joined #c-lightning
13:58 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
13:59 -!- ctrlbreak_MAD [~ctrlbreak@156.34.88.119] has quit [Ping timeout: 244 seconds]
14:03 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
14:27 -!- spinza [~spin@155.93.246.187] has joined #c-lightning
14:34 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 258 seconds]
15:15 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...]
15:17 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
15:22 < jb55> I guess that means updates_complete isn't getting called which updates that var in the db
15:23 < jb55> so it's getting stuck on a block?
15:23 < jb55> nibbier: does it always stop at Adding block 556232 ?
15:24 < jb55> finished bitcoin-cli getblock 0000000000000000000792462058beaad41d9e1328daf44ddb9f739176b586be false (12910 ms) looks sketch
15:32 -!- spinza [~spin@155.93.246.187] has joined #c-lightning
15:36 < nibbier> jb55: it prints that, but does not seem to be anything. if I ctrl-c and start again, it goes back 15 blocks.
15:37 < nibbier> if I run the command manually it takes about 2-3s
15:37 < jb55> nibbier: what about 00000000000000000005db1ddad8e0a56aadabe98666bf0c975c7ca92d86d3bd
15:38 < nibbier> 1.4s
15:38 < jb55> hmm
15:39 < jb55> nibbier: just for sanity: bitcoin-cli getblock 0000000000000000000792462058beaad41d9e1328daf44ddb9f739176b586be 0 | sha256sum
15:39 < nibbier> my database was polluted with 850k entries all exactly: INSERT INTO db_upgrades VALUES(87,'v0.6.1rc2-26-g3372228'); - I cleared the table and set the current version at -1
15:40 < jb55> ah
15:40 < nibbier> but did not change anything :(
15:40 < nibbier> e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
15:40 < jb55> nibbier: that's different than mine =/
15:40 < nibbier> wtf? but output might differ slightly in formatting, order of lines...
15:41 < nibbier> ab829ce494d3855c6bbc2947e6c8c221fdee19845044a53b02e0bf8ac4a69bc7
15:41 < jb55> nibbier: what about bitcoin-cli getblock 0000000000000000000792462058beaad41d9e1328daf44ddb9f739176b586be 0 | xxd -r -p | sha256sum
15:42 < nibbier> jb55: the 0 after the block hash breaks my bitcoin-cli
15:42 < jb55> nibbier: what version is your bitcoind?
15:42 < nibbier> 0.17.1
15:42 < nibbier> don't tell me M(
15:44 < jb55> resetting the current version might be a bad idea, it would try to re-run the older migration commands
15:44 < nibbier> jb55: I only included the -1 line with the current version string
15:44 < nibbier> but it was not connected to my problem, I can just copy back the old database again...
15:45 < nibbier> bitcoind is also 17.1
15:45 < nibbier> 0.17.1
15:46 < nibbier> jb55: so what would the extra parameter 0 do in the getblock call? is this required by recent c-lightning versions?
15:50 < jb55> nibbier: it the verbosity level, it gets the block as hex
15:52 < nibbier> okay, so clightning won't call it with 0... but you are right, why does it take 13s when called by lightningd and only 2-3s when called on the cli
15:52 < jb55> nibbier: does false instead of 0 work?
15:53 < nibbier> yes: b3555a7c19adcf465996112c4075cb22a7069f9548a902653965742b8ff6c87b
15:53 < jb55> yeah I get that
15:56 < nibbier> just started again, the line about the long wait for the block does not show up again, goes straight to "adding block 556082..."
15:56 < nibbier> the bitcoind is not local, so it might have been 12s at a certain time....
16:06 < nibbier> I created an issue... thanks for your input
17:12 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning
17:25 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
17:52 -!- spinza [~spin@155.93.246.187] has quit [Ping timeout: 248 seconds]
19:40 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
19:42 < rusty> nibbier: your bitcoind took almost 13 seconds to answer "getblock".  We're probably waiting for it to respond?
20:57 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has joined #c-lightning
20:59 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 268 seconds]
21:41 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #c-lightning
22:20 -!- jtimon [~quassel@181.61.134.37.dynamic.jazztel.es] has quit [Ping timeout: 258 seconds]
22:33 -!- ulrichard [~richi@dzcpe6300borminfo01-e0.static-hfc.datazug.ch] has joined #c-lightning
23:13 -!- Eagle[TM] [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 245 seconds]
--- Log closed Wed May 29 00:00:26 2019