--- Log opened Tue Sep 14 00:00:07 2021
00:32 < vincenzopalazzo> rusty: But now we are faster :-) - 8%
00:58 < nathanael> rusty: 8% multiplied by an unidentified number of future compilations - maybe worth it
01:09 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 268 seconds]
02:41 -!- rusty [~rusty@103.93.169.121] has joined #c-lightning
03:27 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 268 seconds]
06:00 < mschmoock> cdecker[m]: is there are technical reason why we currently do not allow for two addresses to be announced of the same type but different value?
06:00 < mschmoock> I can imaginge good scenarios where this would be cool (i.e. ISP redundancy)
06:00 < mschmoock> and spec seems to allow, infact I think I have seen nodes on mainnet that do that
06:01 < mschmoock> lightningd/options.c  line 261
06:04 < cdecker[m]> iirc it's to keep the node_announcement small
06:06 < mschmoock> not a good reason imho
06:07 < mschmoock> will ask rusty about that, maybe he has a better reason :D
06:07 < cdecker[m]> Dunno, it's simple, and I usually prefer simple solutions that we can improve later, whereas simplifying complex things is way harder
06:08 < mschmoock> sure, but if spec and code allows for it, why abort with an error message? only people will use it that really need, so keeping it small 'in general' is not doing any good
06:09 < mschmoock> maybe we allow 2 addresses per IPv4 and IPv6 type. I dont see a reason for more tor or dns addresses (the latter I currently work on)
06:12 < mschmoock> client wise I think we are already compatible and simply try the next address if one fails
06:37 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
06:51 < cdecker[m]> Yep, we mix in locally added addresses and try them out in a loop, so having yet another source should not be an issue
07:43 -!- niftynei [~niftynei@2600:1700:d0e:284f:f12f:6544:4323:e403] has quit [Remote host closed the connection]
07:44 -!- niftynei [~niftynei@2600:1700:d0e:284f:4a10:1d0d:1711:ae17] has joined #c-lightning
11:40 -!- Victorsueca [~Victorsue@90.165.120.190] has quit [Read error: Connection reset by peer]
12:56 -!- rusty [~rusty@103.93.169.121] has joined #c-lightning
14:29 < vincenzopalazzo> hey rusty you are around?
14:31 < vincenzopalazzo> I have the following use case lightningd works -> stop -> plugin notify the shoutdown -> the no subscripted plugin will die -> during a shutdown a plugin needs to call another plugin that it already dies
14:31 < vincenzopalazzo> This issue https://github.com/ElementsProject/lightning/issues/4785
14:33 < vincenzopalazzo> What it the correct fix here? it is the job of the plugin stay alive (so make a subscription, but in this case we miss the order?) or we need inside lightnind change the order of the stuff?
14:44 -!- rusty [~rusty@103.93.169.121] has quit [Ping timeout: 252 seconds]
16:02 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #c-lightning
17:21 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 265 seconds]
17:33 -!- belcher [~belcher@user/belcher] has joined #c-lightning
17:50 -!- rusty [~rusty@203.221.41.134] has joined #c-lightning
22:39 -!- rusty [~rusty@203.221.41.134] has quit [Ping timeout: 252 seconds]
23:28 -!- rusty [~rusty@103.93.169.121] has joined #c-lightning
--- Log closed Wed Sep 15 00:00:08 2021