--- Log opened Thu Sep 10 00:00:14 2020
00:12 < rusty> ... so close to rc1!
00:25 < m-schmoock>  o/
00:28 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]
00:28 -!- reallll [~belcher@unaffiliated/belcher] has joined #c-lightning
00:32 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
00:32 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
00:32 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
00:39 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
00:48 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds]
00:48 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
00:48 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning
00:50 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
00:56 -!- skme9 [~skme9@2402:3a80:6bd:e69f:6493:9128:6bde:2c5d] has quit [Ping timeout: 244 seconds]
00:57 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
01:07 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning []
01:08 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning
01:15 -!- skme9 [~skme9@2402:3a80:6bd:e69f:6493:9128:6bde:2c5d] has joined #c-lightning
01:19 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
01:21 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #c-lightning
01:27 -!- ixaeon [~ixaeon@2601:641:c000:2986::4] has joined #c-lightning
01:31 -!- reallll is now known as belcher
01:35 < az0re> So, WTFis going on here?  I am trying to rebalance my channels with the rebalance plugin.  I've already modified rebalance.py to use a riskfactor of 10.  When I do a `getroute` between the nodes of the incoming SCID and the outgoing SCID in the amount I want to rebalance, I get a 4-node route with a total fee of 8.4%.  However, when I run the `rebalance` command--even when specifying a maxfee of 10%--I cannot actually rebalance.  I get 
01:35 < az0re> "rebalance failed" and in the lightningd console output, lots of stuff like: "htlc 152 failed from 3th node with code 0x1007 (WIRE_TEMPORARY_CHANNEL_FAILURE)" and "lightningd: Sending XXXmsat over 6 hops to deliver XXXmsat"
01:36 < zmnscpxj> remote failure
01:36 < zmnscpxj> something is wrong on some node along the channel
01:36 < zmnscpxj> along the route I mean
01:36 < zmnscpxj> since it is a remote failure, we cannot do anything
01:36 < az0re> How can I see which node that is and exclude it from routing entirely?
01:37 < zmnscpxj> "failed from 3th node"
01:37 < zmnscpxj> 0 is us
01:37 < az0re> Right, but I don't see any indication of what route exactly is being tried, so I don't know which one is the 3rd node
01:37 <@cdecker> It should exclude and retry automatically, though adding some debugging output to the rebalance plugin is a good idea
01:38 < az0re> Also the riskfactor should be (needs to be?) changed to reflect the value chosen elsewhere
01:40 <@cdecker> az0re:you could just add a `print(route)` after this line https://github.com/lightningd/plugins/blob/master/rebalance/rebalance.py#L180 until we add decent printing of the route
01:40 < az0re> So what is the solution for me to rebalance these channels?  Give it a longer retry timeout?
01:41 < az0re> cdecker: Thanks, will do
01:41 <@cdecker> It might just not be possible given the channel balances (not enough capacity to do a rebalance) but increasing the retry timeout might cause it to try more routes
01:42 <@cdecker> That being said, if the rebalance returns before the timeout it means that it tried all routes it could, and then increasing the timeout won't help
01:42 < az0re> I'm not sure; I didn't time it
01:42 <@cdecker> You could also split the rebalance in smaller attempts that stand a better chance to succeed
01:42 < az0re> It definitely took a long time, maybe 60s, I dunno
01:43 < az0re> Well, I also made the change suggested by fiatjaf to redefine MPP_TARGET_SIZE to 100 million in plugins/libplugin-pay.c
01:43 < az0re> Maybe that is a problem here?
01:43 < zmnscpxj> not sure if that matters
01:44 < zmnscpxj> since rebalance is a separate program
01:45 < az0re> I guess it does sendpay directly instead of using the pay plugin
01:47 < az0re> cdecker: looking more closely, it does have erring_node and erring_channel in the output
01:48 <@cdecker> Indeed the MPP size is only relevant for the `pay` plugin, it doesn't affect the rebalance plugin
01:48 < az0re> Well, hot damn.  Using a longer retry timeout did the trick.
01:48 <@cdecker> Rebalance doesn't support MPP (yet)
01:48 <@cdecker> Awesome az0re
01:48 < az0re> Thanks a lot zmnscpxj and cdecker
01:48 <@cdecker> Anytime ^^
01:49 < az0re> Now that I have a few channels and some inbound capacity... hey, this shit is pretty cool
01:49 < az0re> Bootstrapping is a real bitch, though
01:50 < zmnscpxj> yes, bootstrap is a bitch
01:50 < zmnscpxj> and our contrib/bootstrap-node.sh is broken and contains nodes that no longer exist
01:50 < az0re> Oh, and it did the rebalance for ~1% fee total
01:51 < az0re> I guess `getroute` doesn't try to do any fee minimization?
01:51 < zmnscpxj> getroute minimizes fees
01:51 < zmnscpxj> but if the most minimal-fee routes are not working, you can only exclude them
01:51 < zmnscpxj> which means you end up having more fees
01:52 < zmnscpxj> than the minimal-fee route (which are not working, as mentioned)
01:52 < az0re> I don't understand
01:52 < zmnscpxj> getroute returns the smallest fee route given your exclusion set
01:52 < az0re> So just suddenly int he span of a few minutes a node happened to come online that enabled me to get 1% instead of 8.4%?
01:52 < zmnscpxj> so you start with an empty exclusion set
01:53 < zmnscpxj> you get the route with the smallest fee
01:53 < zmnscpxj> but some channel in-between fails
01:53 < zmnscpxj> so you exclude that channel
01:53 < az0re> But when I did getroute, it said 8.4%
01:53 < darosior> cdecker: re the timer for `feeadjuster` but there is already gossipd's timer ?
01:53 < zmnscpxj> then you getroute again, with that channel excluded
01:53 < az0re> I got a _lower_ fee in the actual rebalance
01:53 < zmnscpxj> maybe you have route randomization?
01:53 < darosior> Sorry to insist but want to be sure with my understanding
01:54 < az0re> So getroute did not return me the lowest fee route, not at all
01:54 < zmnscpxj> *shrug*
01:54 < az0re> zmnscpxj: Sounds like something I want, but I don't know how to check.  Anyway my intuition is that adding randomization should only increase my fee, not dramatically reduce it
01:54 < zmnscpxj> do you mean using a direct getroute?
01:55 < zmnscpxj> because direct getroute has randomization by default
01:55 < zmnscpxj> supposedly
01:55 < zmnscpxj> and most plugins that use it disable the randomization
01:56 < az0re> Ahhhh I see
01:56 < m-schmoock> yes rebalance and drain must be rewritten for MPP
01:56 < m-schmoock> thats on my list for rainy days
01:56 < zmnscpxj> yes, welcome to rewriting them in C
01:56 < az0re> Yes, C is an interesting choice...
01:56 < m-schmoock> rebalance might be a good idea as a shipped default plugin
01:57 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has joined #c-lightning
01:57 < m-schmoock> but on the other side it has benefits to ship as little as possible
01:57 < zmnscpxj> In theory it helps us port more easily
01:57 < az0re> m-schmoock: Yes, I think so.  At least I was surprised when `rebalance` was not a command.  I found it quickly in the plugins repo, though
01:58 < m-schmoock> i have been maintaining it for a while. but they both need polish
01:58 < m-schmoock> sorry for that
01:58 < az0re> no worries
01:59 < zmnscpxj> we could have exposed bits and pieces of MPP as commands so that rebalance and drain can remain in python-land, but *shrug* that is more complicated
01:59 < m-schmoock> drain has its own chunking which is a very clumsy way of MPP ;)
02:00 -!- vincenzopalazzo [~vincent@host-82-60-201-14.retail.telecomitalia.it] has joined #c-lightning
02:00 < zmnscpxj> could also do similar chunking in rebalance as well
02:00 < m-schmoock> yes also possible
02:00 < m-schmoock> chunking can even be improved a little bit I think
02:00 < m-schmoock> but I waited with this to see whats with the MPP stuff so maybe its pointless
02:01 < m-schmoock> yay   siren alter duck and cover indoctrination going on here :D
02:01 < m-schmoock> lets keep all the little children in fear
02:01 < zmnscpxj> huh?
02:01 < m-schmoock> nothing special
02:01 < m-schmoock> they test the sirens
02:02 < zmnscpxj> ....
02:02 < m-schmoock> and tell the kids to put on masks before going out
02:02 < m-schmoock> german way of securing the masses :D
02:34 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
02:34 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #c-lightning
02:37 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds]
02:38 -!- skme9_ [~skme9@2402:3a80:6bd:e69f:6493:9128:6bde:2c5d] has joined #c-lightning
02:42 -!- skme9 [~skme9@2402:3a80:6bd:e69f:6493:9128:6bde:2c5d] has quit [Ping timeout: 260 seconds]
02:58 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has quit [Ping timeout: 258 seconds]
03:09 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
03:23 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
03:37 -!- mode/#c-lightning [+o rusty] by ChanServ
03:37 -!- rusty changed the topic of #c-lightning to:  #c-lightning is: Next meeting here @8PM UTC Monday 21 Sep!  Chat about the C-lightning implementation: https://github.com/ElementsProject/lightning https://lists.ozlabs.org/listinfo/c-lightning  Current Version: https://github.com/ElementsProject/lightning/releases/tag/v0.9.1rc1 Logs at http://gnusha.org/c-lightning/
03:38 -!- mode/#c-lightning [-o rusty] by rusty
03:45 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
04:00 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
04:01 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
04:35 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
04:35 < m-schmoock> is it known that when I start lightningd wihtout --daemon that theres currently no stdout logging and the executable is completely silent?
04:36 < m-schmoock> shouldnt the log output be reflected to stdout as well without --daemon ?
04:41 < vincenzopalazzo> m-schmoock: I noted also this event, and I discovered that when you have enabled the log file the stout is silent! I started to look at the code, but I'm too slowly in this period.
04:42 < m-schmoock> then can I disable the logfile ??
04:42 < vincenzopalazzo> if you remove the log file propriety, the node start to write on console
04:42 < m-schmoock> ah its in my config
04:43 < vincenzopalazzo> I noted this event, can you confirm this event?
04:43 < m-schmoock> yes when I dont have a logfile stdout works
04:43 < vincenzopalazzo> Do you think that it is a correct behavior? 
04:43 < m-schmoock> question is if we should always also log to stdout when we dont have --daemon
04:44 < m-schmoock> I think without --daemon it should always log to stdout but thats something we can discuss
04:46 < vincenzopalazzo> yes, I agree with you, I think that without --daemon is correct have the print debug in a both of place (console and file), but my dev experience is too shorty to say, !Oh this is wrong! :-)
05:05 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Quit: ZNC 1.7.5 - https://znc.in]
05:05 -!- alko89 [~alko89@unaffiliated/alko89] has joined #c-lightning
05:42 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning
06:37 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]
07:00 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning
07:02 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #c-lightning
07:13 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
07:13 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning
07:53 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
07:53 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #c-lightning
08:12 -!- fiatjaf [~fiatjaf@2804:7f2:2a83:c857:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 272 seconds]
08:14 -!- fiatjaf [~fiatjaf@2804:7f2:2985:8437:ea40:f2ff:fe85:d2dc] has joined #c-lightning
09:03 -!- rotarydialer [~rotarydia@unaffiliated/rotarydialer] has quit [Ping timeout: 240 seconds]
09:11 < darosior> b64_decode from common/base64 will always return an empty array
09:12 < darosior> (or maybe it's null -- anyway its tal_count is 0)
09:12 -!- fiatjaf [~fiatjaf@2804:7f2:2985:8437:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 260 seconds]
09:12 < darosior> We don't use it, so maybe it's fine to remove it ?
09:13 -!- rotarydialer [~rotarydia@unaffiliated/rotarydialer] has joined #c-lightning
09:14 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning []
09:14 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning
09:14 -!- fiatjaf [~fiatjaf@2804:7f2:2a85:a36c:ea40:f2ff:fe85:d2dc] has joined #c-lightning
09:50 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning
09:53 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
09:53 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
09:54 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #c-lightning
10:31 -!- skme9_ [~skme9@2402:3a80:6bd:e69f:6493:9128:6bde:2c5d] has quit [Remote host closed the connection]
10:31 -!- skme9_ [~skme9@2402:3a80:6bd:e69f:6493:9128:6bde:2c5d] has joined #c-lightning
11:05 -!- skme9_ [~skme9@2402:3a80:6bd:e69f:6493:9128:6bde:2c5d] has quit [Ping timeout: 244 seconds]
11:08 -!- skme9_ [~skme9@2402:3a80:6bd:e69f:6493:9128:6bde:2c5d] has joined #c-lightning
11:25 -!- skme9_ [~skme9@2402:3a80:6bd:e69f:6493:9128:6bde:2c5d] has quit [Remote host closed the connection]
11:38 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
12:07 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has quit [Remote host closed the connection]
12:08 -!- k3tan [~pi@gateway/tor-sasl/k3tan] has joined #c-lightning
12:31 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
12:35 -!- sr_gi [~sr_gi@static-240-45-224-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
12:36 -!- sr_gi [~sr_gi@static-240-45-224-77.ipcom.comunitel.net] has joined #c-lightning
12:53 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Remote host closed the connection]
13:06 < darosior> Wow some research was put into the naming for this one ^^
13:07 < darosior> Didn't get it without the explanations
13:57 -!- vincenzopalazzo [~vincent@host-82-60-201-14.retail.telecomitalia.it] has quit [Remote host closed the connection]
14:43 -!- az0re [~az0re@gateway/tor-sasl/az0re] has joined #c-lightning
15:07 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
15:08 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #c-lightning
15:48 -!- az0re [~az0re@gateway/tor-sasl/az0re] has quit [Quit: Leaving]
15:59 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
15:59 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #c-lightning
16:01 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #c-lightning
16:21 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
16:45 -!- sr_gi [~sr_gi@static-240-45-224-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
16:46 -!- sr_gi [~sr_gi@static-240-45-224-77.ipcom.comunitel.net] has joined #c-lightning
17:09 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning
17:11 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
17:14 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 265 seconds]
17:19 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
17:23 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Client Quit]
17:40 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has left #c-lightning []
17:40 -!- blockstream_bot [blockstrea@gateway/shell/sameroom/x-zzgbwiizjmpgirfq] has joined #c-lightning
17:43 < fiatjaf> az0re, yes, that's it
17:43 < fiatjaf> (sorry, I forgot about answering you completely)
17:43 < fiatjaf> (then other things happened that prevented me from answering until now)
17:50 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning
17:54 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 256 seconds]
18:06 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
18:06 < rusty> niftynei: tb1qfztuw65wjhnpthwj5jy9e7krwu85tz5x2rfzkt Maybe me rich! BNwahahahaha!
18:08 <@niftynei> dc337042a80af773ce54f98fa046a7444e52be19cb06d125763108184eefc382
18:10 < rusty> https://blockstream.info/testnet/tx/dc337042a80af773ce54f98fa046a7444e52be19cb06d125763108184eefc382
18:13 < rusty> niftynei: Woah, you just doxxed yourself as a testnet miner!
18:14 <@niftynei> woops
18:14 <@niftynei> busted
18:25 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #c-lightning
18:26 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning
18:33  * rusty tries to multifundchannel 100 nodes at a time on testnet...
18:33 < rusty> rusty@builder:~$ lightning-cli -o multifundchannel `cat /tmp/nodelist` 
18:36 < rusty> No surprise, it failed to connect to some.  Ok, round 2!
18:36 < zmnscpxj> ...is that not what min_channels is for?
18:37 < rusty> $ lightning-cli multifundchannel `cat /tmp/nodelist` null null null 1
18:37  * rusty waits...
18:37 < rusty> I'm feeding it the first 100 nodeids from `listnodes`.
18:39 < rusty> zmnscpxj: exactly!
18:40 < rusty> zmnscpxj: SUCCESS!  4 channels opened out of 100!
18:41 < zmnscpxj> ok
18:41 < zmnscpxj> 7->8 minutes?
18:41 < rusty> https://blockstream.info/testnet/tx/f6e2317d0f6206fc602dbb7ede8f6368d9094b3f69f3404bf7a0ce37b384bc55
18:42 < rusty> zmnscpxj: no, it only took about 3 minutes!
18:42 < zmnscpxj> oh ok
18:42 < rusty> (I was typing in here as I did it)
18:42 < rusty> zmnscpxj: to be fair, a whole pile of failures was because we didn't have an address to connect to for the node.
18:44 < rusty> zmnscpxj: ok, so why not try every node on the network!
18:44 < zmnscpxj> sure, you have 50 BTC anyway
18:44 < rusty> -bash: /home/rusty/bin/lightning-cli: Argument list too long
18:44 < rusty> ... that's why!
18:44 < zmnscpxj> bwahahahaha
18:45 < rusty> ... I just have to write my JSON manually and feed it in I guess.
18:45 < zmnscpxj> just write a little C code to make a JSON-RPC call
18:45 < rusty> ... I can do it in shell, but I want to see the response.
18:46 < zmnscpxj> I mean, opening a channel to every node on the network, not like that makes your node central to the network or anything right
18:49 < rusty> zmnscpxj: hey, you created this weapon of mass centralization! :)
18:49 < zmnscpxj> yes, that was my plan all along rusty
18:49 < zmnscpxj> and it is too late
18:49 < zmnscpxj> multifundchannel is merged
18:50 < zmnscpxj> bwahahahahahahaha
18:50 < zmnscpxj> now my plans for world re-optimization shall continue apace!!!!
18:52 < rusty> zmnscpxj: OK, now in python:
18:52 < rusty> >>> import pyln.client
18:52 < rusty> >>> rpc = pyln.client.LightningRpc('/home/rusty/.lightning/testnet/lightning-rpc')
18:52 < rusty> >>> help(rpc.multifundchannel)
18:53 < rusty> with open('/tmp/nodelist', 'r') as f:
18:53 < rusty> ...     import json
18:53 < rusty> ...     dsts=json.loads(f.read())
18:53 < rusty> >>> rpc.multifundchannel(destinations=dsts, minchannels=1)
18:53 < rusty> And now we wait!
18:53 < rusty> Hmm, I should have added the tor proxy support, can't connect to any of the tor only nodes.
18:54 < rusty> 1700 nodes is a nice stress test.
19:15 < rusty> Still waiting, some are taking a long time to timeout it seems
19:17 < rusty> https://github.com/ElementsProject/lightning/pull/4038 will give us an rc2 I think.
19:26 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
19:43 < rusty> Still waiting, not sure why
20:00 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning
20:05 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 258 seconds]
20:40 < rusty> LOL!  
20:40 < zmnscpxj> still waiting?
20:40 < rusty> Yes, waiting on 03244564ea00f2d5fe631568ebb4bf029e54a61e9cd056c64ec9697370a192d729
20:41 < rusty> zmnscpxj: seems like it's not responding, and we're not timing out for some reason.
20:42 < rusty> connectd.c:547:	/* FIXME: Timeout */
20:43 < rusty> Actually,t his is 587.  Same FIXME tho
20:48 < rusty> Hmm, will implement and test timeout, then release rc2 I think.
20:48 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
20:56 -!- sr_gi [~sr_gi@static-240-45-224-77.ipcom.comunitel.net] has quit [Read error: Connection reset by peer]
20:56 -!- sr_gi [~sr_gi@static-240-45-224-77.ipcom.comunitel.net] has joined #c-lightning
22:24 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 2.7.1]
22:42 -!- mdunnio [~mdunnio@208.59.170.5] has joined #c-lightning
22:47 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 265 seconds]
23:26 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #c-lightning
--- Log closed Fri Sep 11 00:00:15 2020