04:55:15 <midipoet> why are so many nodes "unreachable"? is that just a config/port setting they have not activated?
05:23:56 <plowsof> To make your node reachable, you have to do an extra step of opening / forwarding ports in your router. Some ISP's in EU dont even let users host public services neither but i presume the main reason is it requires people to do something other than start monerod   
06:30:16 <midipoet> might be a stupid question, but can a node be both "unreachable" and a "spy node"? or is "reachable" a prerequisite for "spying"?
07:03:18 <sech1> Spy nodes don't make outgoing connections, they prefer incoming connections because of D++
07:03:23 <sech1> so they are all reachable
07:07:40 <midipoet> thanks
15:07:00 <m-relay> <r​ucknium:monero.social> midipoet: The way that we are detecting/defining spy nodes excludes unreachable nodes. The network crawler sends pings to nodes. If their `peer_id` response in pings is inconsistent with their claimed `peer_id` in the p2p handshake, then they are considered spy nodes. The network crawler doesn't directly ping nor handshake the unreachable nodes. And like sech said, we observe that<clipped mess
15:07:01 <m-relay> <r​ucknium:monero.social>  the spy nodes do not initiate connections (i.e. create outbound connections), anyway. Unreachable nodes only initiate connections.
15:08:23 <m-relay> <r​ucknium:monero.social> The estimate of the number of unreachable nodes is rough. It is based on counting all of the IP addresses that reachable nodes share with the crawler during the handshake. It is hard to know how accurate that is.
15:08:52 <m-relay> <r​ucknium:monero.social> Some research on the bitcoin network suggests that 80-90% of bitcoin nodes are unreachable.
15:11:58 <m-relay> <r​ucknium:monero.social> You can also try to guesstimate the number of unreachable nodes by counting the number of inbound connections of a reachable node. AFAIK, most reachable Monero nodes have more than 100 connections. If every node uses the default number of outbound connections (12), then that would imply a much higher number of unreachable nodes than the moneronet.info webapp counts.
15:12:42 <m-relay> <r​ucknium:monero.social> Or, you could set up a large number of reachable nodes and try to enumerate all the IP addresses that connect to you over a period of time, avoiding double-counting.
15:13:53 <m-relay> <b​oog900:monero.social> Those unreachable addresses are addresses that once where reachable but are no longer or are addresses that are being injected by bad peers. This is the only way for them to be in nodes address books.
15:13:53 <m-relay> <b​oog900:monero.social> The real number of unreachable nodes that have always been unreachable is much higher.
15:13:58 <m-relay> <r​ucknium:monero.social> AFAIK, the best estimate of the number of unreachable nodes on the bitcoin network came from data analysis of an addressbook-packing attack. Hard to reproduce! (And undesirable)
15:14:36 <m-relay> <b​oog900:monero.social> Also I am pretty sure someone is injecting unreachable node addresses into the network, see jhendrix's research.
15:15:26 <m-relay> <r​ucknium:monero.social> ^ This is one reason why this isn't ready to share on social media. Problems with data quality that will hopefully be fixed.
15:16:42 <m-relay> <b​oog900:monero.social> Those unreachable addresses are addresses that once were reachable but are no longer or are addresses that are being injected by bad peers. This is the only way for them to be in nodes address books.
15:16:43 <m-relay> <b​oog900:monero.social> The real number of unreachable nodes that have always been unreachable is much higher.
16:35:04 <sech1> I just had a thought... Given a sheer number of spy nodes - if they start dropping transactions in the stem phase, it can seriously disrupt the network...
16:39:14 <m-relay> <b​oog900:monero.social> The embargo timer covers that, it should only add around 40s of delay to a black holed tx
16:42:34 <m-relay> <b​oog900:monero.social> This PR decreases the 40s for most txs but for some it would be longer: https://github.com/monero-project/monero/pull/9295
17:12:23 <sech1> Then why is this PR still not merged...
17:13:15 <sech1> ah, some changes were requested
17:16:54 <m-relay> <v​tnerd:monero.social> I disagree on the changes being needed, but I guess it doesn't follow the paper 100% if the precision is seconds
17:18:20 <m-relay> <v​tnerd:monero.social> The issue: i would need to redesign how the embargo is detected, and stored
17:24:00 <m-relay> <b​oog900:monero.social> yeah it doesn't really matter too much it just means more txs are going to be fluffed early (17.5%) than the amount we wanted (10%)
17:24:39 <m-relay> <b​oog900:monero.social> although the other thing requested was changing the fluff timers to the exponential distribution too
18:02:14 <m-relay> <v​tnerd:monero.social> I must've missed that recommendation, not sure its for the best. Will respond in thread then