--- Log opened Sun Sep 26 00:00:18 2021
01:17 -!- nathanael [~nathanael@user/nathanael] has quit [Quit: connection reset by purr]
01:17 -!- nathanael [~nathanael@user/nathanael] has joined #c-lightning
01:26 < cdecker[m]> Could be an option, but afaik recognizing our external ip can not be done reliably without using an external service, DNS is likely more flexible and allows for things like migrations and fail over better
02:03 -!- kexkey [~kexkey@static-198-54-132-171.cust.tzulo.com] has quit [Ping timeout: 252 seconds]
02:05 -!- kexkey [~kexkey@static-198-54-132-155.cust.tzulo.com] has joined #c-lightning
05:30 -!- jonatack [jonatack@user/jonatack] has joined #c-lightning
08:36 < mschmoock> cdecker[m]: what do you think about adding the IP address a node connected from to the init message of the responder so that there is no external service except the peers themselfs to ask for that info?
08:38 < cdecker[m]> Would have to think about it, if the peer were to lie to us it shouldn't be a problem since they can't mitm the connection, but they could do traffic analysis on an encrypted connection anyway. So there are some considerations to think through before going with that proposal
08:41 < mschmoock> yes, but we could make the logic in a way that we only broadcast a node_announcement update when a certain threshold of peers respond with the same IP address
08:42 < mschmoock> like one third or at least two or whatever comes first (to handle for nodes with less channels)
08:48 < cdecker[m]> Sure, that's a workaround, but requires some logic again, and if you have multiple interfaces (rare) you wouldn't settle on an IP. Not saying no, but want to consider the edge cases 😇
08:50 < mschmoock> I know its not bright, but an effective plug and play option to think about
10:00 < cdecker[m]> Totally agree, if it doesn't lock us in further down the road
10:38 -!- ufotofu [~ufotofu@149.248.16.17] has joined #c-lightning
11:54 -!- HelloShitty [~psysc0rpi@bl20-171-222.dsl.telepac.pt] has quit [Read error: Connection reset by peer]
11:56 -!- HelloShitty [~psysc0rpi@bl20-171-222.dsl.telepac.pt] has joined #c-lightning
15:39 -!- kexkey [~kexkey@static-198-54-132-155.cust.tzulo.com] has quit [Read error: Connection reset by peer]
17:01 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 252 seconds]
17:15 -!- belcher [~belcher@user/belcher] has joined #c-lightning
18:56 -!- rusty [~rusty@203.221.41.134] has joined #c-lightning
22:48 -!- Netsplit *.net <-> *.split quits: jonasschnelli
22:48 -!- Netsplit over, joins: jonasschnelli
22:54 -!- Netsplit *.net <-> *.split quits: sword_smith, ufotofu, warren
22:54 -!- ikke_sword_smith [sword_smit@bitcoinfundamentals.org] has joined #c-lightning
22:55 -!- Netsplit over, joins: ufotofu
22:56 -!- Netsplit over, joins: warren
22:56 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #c-lightning
22:57 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 276 seconds]
23:02 < openoms[m]> mschmoock do you often see more than 2 seconds delays with Tor nodes? Some nice measurements here: https://twitter.com/SeverinAlexB/status/1442138426740981761?s=19
23:02 < cdecker[m]> Sorry, I find it's in my nature to play devil's advocate :-)
--- Log closed Mon Sep 27 00:00:19 2021