<r​brunner7:monero.social> I am trying to rewrite `bool node_server<t_payload_net_handler>::make_new_connection_from_peerlist(network_zone& zone, bool use_white_list)`

<r​brunner7:monero.social> It iterates over either the list of known white peers, or known gray peers, and builds a list of candidates to choose from later

<r​brunner7:monero.social> The list of candidates is a list of indexes into the peer lists that are managed by the `peerlist_manager` class.

<r​brunner7:monero.social> It later picks peers out of those lists again, using the indexes.

<r​brunner7:monero.social> I claim that's *not* clean, quite in principle. The peerlists are dynamic, there are methods like `peerlist_manager::remove_from_peer_gray` that will invalidate any indexes that you "put away".

<r​brunner7:monero.social> That's why internally the peerlist manager only modifies the lists under protection of a lock.

<r​brunner7:monero.social> There is *no* lock that protects the whole of `make_new_connection_from_peerlist`.

<r​brunner7:monero.social> If my analysis is correct, what do people here knowing more about this stuff than me think? Is there an easy method to handle this that is clean? If not, can we risk to neglect the problem and claim that it's super improbable that some other thread makes our indexes invalid in just the same hundredths of a second?

<r​brunner7:monero.social> After all, the code is like that for many years, and it looks like we did not run into problems with it, or at least no recognizable problems ...

It can be a race between selecting an index, then using it and some other thread updating peer lists

But the worst it can do is select some other adjacent peer

There are bounds checks in those functions anyway

Actual access to peer lists is guarded by locks in all cases. It's just indices that can get out of date.

<r​brunner7:monero.social> Yes, I came to the same conclusion what can happen: Every leap year you don't get the peer you want, and if you are careful not to access behind current list length, it won't ever really crash. But I will sink now entire work days into improving this, coming up with a better selection algorithm avoiding spy nodes, and if there is a reasonable way to deal with this cleanly, well, n<clipped message>

<r​brunner7:monero.social> ow is the time to do so :)

<r​brunner7:monero.social> One simple approach that I brainstormed just now is a counter in the peer list manager, counting list modifications, and if that counter changes "on the way" in my method, I just throw my indexes away and start again.

The proper way is to get actual peers instead of indices, and not care if the list changes after it

More resource and CPU intensive though

<r​brunner7:monero.social> Do I have to copy those peers? Will they get released if they are removed from the lists? I would guess so.

<r​brunner7:monero.social> I could of course just put away what I need to know about those peers, it's not that much info, I could make a little separate strudct for that.

<r​brunner7:monero.social> *struct

yes, you will need to copy the data you need

<r​brunner7:monero.social> Ok, thanks, maybe I will try something along these lines

<j​osejesussanchezrueda:matrix.org> hi

<s​yntheticbird:monero.social> epic name

<j​osejesussanchezrueda:matrix.org> hi

<j​osejesussanchezrueda:matrix.org> :)

<j​osejesussanchezrueda:matrix.org> Hablas en español¿?

<s​yntheticbird:monero.social> no sorry it's an english only channel

<j​osejesussanchezrueda:matrix.org> ok

<j​osejesussanchezrueda:matrix.org> Mining Power Monitoring Issue with supportxmr.com?

<j​osejesussanchezrueda:matrix.org> Hello,

<j​osejesussanchezrueda:matrix.org> I've recently set up a PC to mine Monero and would like to monitor its mining power. However, I'm having trouble accessing the statistics on supportxmr.com. The site seems to be giving me issues or not loading properly.

<j​osejesussanchezrueda:matrix.org> Could you please guide me on how I can check my hashrate and mining performance? Are there alternative ways to monitor my miner’s performance if the website is down?

<j​osejesussanchezrueda:matrix.org> Thanks in advance for your help!

<o​frnxmr:xmr.mx> Monero Support or Monero Mining

<o​frnxmr:xmr.mx> The the mining channel first

<o​frnxmr:xmr.mx> Try* the

jeffro256: reminder regarding 9916 for release

.merge+ 9910 9909 9908

Added

.merge+ 9920

...

<o​frnxmr:xmr.mx> Lol, why'd it say "..."

<j​effro256:monero.social> Passive aggressive PR bot

.merges

<b​inarybaron:matrix.org> Does wallet2.h or wallet2_api.h have support for adding another keypair to an existing wallet to sweep a single utxo to the „main“ keypair of the same wallet?

<j​effro256:monero.social> Like importing an enote so you can spend it from another wallet? Not AFAIK