<s​ofabox:monero.social> is there any estimate timeline for fcmp? when can we expect it, next 2 years?

<k​ewbit:matrix.org> What is fcmp?

<s​ofabox:monero.social> main advantage of fcmp is you know how ring signatures for xmr is 1 in 16?

<s​ofabox:monero.social> fcmp will make it 1 in billion something so statistical attacks almost impossible. increasing privacy

<k​ewbit:matrix.org> Interesting

<d​ave.jp:matrix.org> Within next 5 years

<3​21bob321:monero.social> Who is fcmp

<d​ave.jp:matrix.org> Fluffy crab money pony

<n​eromonero1024:monero.social> if 2 miners find blocks at the same time (both blocks are published to the network), then what's the tiebreaker rule?

<n​eromonero1024:monero.social> I always thought it was the block with higher diff that wins the race

<3​21bob321:monero.social> They arm wrestle

<j​effro256:monero.social> There is no tiebreaker. If the chains only differ by one block, they will have equal cumulative difficulty

<j​effro256:monero.social> Tiebreakers can reduce network stability. For example, if the tiebreaker rule was to use the block with the "lower" block ID or PoW hash, then miners, even "honest" ones, who have high network delay would cause frequent reorgs with high delay when they re-mined the top block while the rest of the network has moved onto the next block

<j​effro256:monero.social> Removing the tiebreaker incentives miners to have low block propagation times

<n​eromonero1024:monero.social> interesting

<n​eromonero1024:monero.social> in that case, wouldn't using the block timestamp (the timestamp in the block header) as the tiebreaker be better option?

<s​trawberry:monero.social> miners can game that by putting incorrect timestamps on their blocks

<s​trawberry:monero.social> you'd end up with timestamps being lower than they're supposed to be, but above the minimum value where they're likely to be accepted by most nodes

<o​hchase:envs.net> "if the chains only differ by one block, they will have equal cumulative difficulty", is this true all the time? If you had two new blocks, wouldn't it be possible one has a higher difficulty than the other making for one chain with a higher cumulative difficulty?

It's always true due to how difficulty adjustment works. There's a lag of at least 15 blocks before any differences can emerge.

<n​eromonero1024:monero.social> apparently, cumulative difficulty is not the summation of block diff but rather, the summation of network difficulty values the blocks had to overcome

<n​eromonero1024:monero.social> in this definition, both chains will have the same cumulative difficulty even though the summation of individual block diff is different

<o​hchase:envs.net> Okay, so my understanding is the important part is that the difficulty adjustment does not take into account the current block. So in a situation where both chains have diverged by one block, its impossible for those divergent blocks to affect cummulative difficulty because cummulative difficulty's definition excludes the current block. So this holds true if there is atleast a 1 b<clipped message>

<o​hchase:envs.net> lock lag when considering difficulty adjustment

<o​hchase:envs.net> i.e. without 1 confirmation have you even won really?

No, two different blocks at the top are equal until someone mines one more block

<o​hchase:envs.net> think we are saying same thing?

"No" was an answer to "have you won" question. So yes, the same thing.

<o​hchase:envs.net> lol i meant it in the meme way like do you even lift bro

Hello.

<o​hchase:envs.net> How do people monitor their public nodes, I'm thinking I might as well just parse access logs to see what rpc resources are being accessed? I don't see any other solutions existing, there is the get_info endpoint but that doesn't help me track the access only the nodes health

<3​21bob321:monero.social> As in people syncing?

<3​21bob321:monero.social> Or access to the server running the node?

<r​ucknium:monero.social> ohchase: Does this help? github.com/lalanza808/docker-monero-node

<m​c-on-mx:matrix.org> Anyone else having trouble reaching the Trocador site? According to their Reddit page, they were resolving a DDOS attack about a month ago. Is the site still down? I can't reach the site on Tor, clearnet or via their i2p or onion link.

<o​frnxmr:monero.social> Ddos is bad

<o​frnxmr:monero.social> Trocador.i2p works fine

<o​frnxmr:monero.social> matrix.monero.social/_matrix/media/…ero.social/BMgpixafMRzwfWpifJtaRKxr

<m​c-on-mx:matrix.org> Okay, this is a teaching moment for me! I don't know anything about i2p. I assumed it was like an onion address. I tried getting the Trocador i2p link from KYC.notme, but it didn't connect. Just now I tried the URL in the address bar of your screen shot, and it wouldn't connect. There must be something I don't get about i2p. Would you please school me on how to reach it?

<o​frnxmr:monero.social> are you on desktop or mobile?

<m​c-on-mx:matrix.org> Prefer desktop for this sort of thing

<m​c-on-mx:matrix.org> Matter of fact...I would first try to get connected on a Linux Mint desktop.

<o​frnxmr:monero.social> Youll have to install i2pd

<o​frnxmr:monero.social> up to you whether you prefer the version in the repo or want to keep up to date manually from git

<o​frnxmr:monero.social> If repo "sudo apt install i2pd"

<o​frnxmr:monero.social> Then after it starts up, change your browser proxy setting to 127.0.0.1:4447

<o​frnxmr:monero.social> its much easier from android.

<o​frnxmr:monero.social> install invizible,

<o​frnxmr:monero.social> in inviz, enable dnscrypt + i2p + vpn mode

<o​frnxmr:monero.social> then use any browser to visit any i2p domain

<m​c-on-mx:matrix.org> Wow - thanks so much for the tutorial! Much obliged 🤠 🍻

<o​hchase:envs.net> So i did see this, but looks to just be probing the restricted rpc endpoints. I wanted to track rpc access by endpoint / method if using base json rpc . I was playing around with ddosing my node, and had some good success. At the same time realized, I have limited to no visibility into what is being accessed with my public rpc. Is it one user constantly spamming the same block? etc

<o​hchase:envs.net> kinda, not to deanonymize but for monitoring. Would be nice to flag on weird requests and to monitor for any ddos

<r​ucknium:monero.social> ohchase: Maybe `nethogs`

<r​ucknium:monero.social> Maybe `wallet.rpc` and/or `wallet.wallet2` log categories: getmonero.org/resources/developer-g…/daemon-rpc.html#set_log_categories

<r​ucknium:monero.social> I have seen comments in the monero code that say "we won't print everything to log so that it's harder to see some private info by default". Of course, anyone could create custom log messages by modifying the code.

<o​hchase:envs.net> Thanks will take a look, I am using caddy as my reverse proxy so it looks to have Prometheus metrics integration integrated. Going to pursue trying to log the access at the reverse proxy level because why not 🤷

<o​hchase:envs.net> Thanks will take a look, I am using caddy as my reverse proxy so it looks to have Prometheus metrics integration. Going to pursue trying to log the access at the reverse proxy level because why not 🤷

<r​ucknium:monero.social> If your RPC is being DDoS by a malicious entity then you could solve it by closing the port or requiring username and password to access.

<o​hchase:envs.net> thank you, no real threat rn. Just for observability of my public node

<3​21bob321:monero.social> Cloudlfare?????

<3​21bob321:monero.social> Putting proxy infront probably will help

<o​frnxmr:monero.social> There is a grafana somewhre that shows the rpc connection types etc

<o​frnxmr:monero.social> lza_menace: do you have that public?