-
m-relay
<hbs:matrix.org> Hi, how can change suggestions be made to the Monero repo wiki on GitHub?
-
m-relay
<ofrnxmr:xmr.mx> Make suggestions on monero-project/meta issues
-
m-relay
<syntheticbird:monero.social> RFC from devs/maintainers, also people that were following dev meetings long time ago.
-
m-relay
<syntheticbird:monero.social> Over Tor/I2p, monerod cannot identify the origin of incoming connections. The normal mechanism on internet is to advertise your port, which monerod will then ping to assess the peer availability. This is easy on internet since you know the IP address of a peer that is communicating to you. To compensate that on anonymous networks, monerod is instead inserting its own anonymous add<clipped message>
-
m-relay
<syntheticbird:monero.social> ress into timed sync responses in order to be actually found. So you wait for around 60 sec, receive a request, grab some white peers for the response and insert your own on the way.
-
m-relay
<syntheticbird:monero.social> I couldn't but pay attention to this detail. Monerod is inserting its own anonymous address at every timed sync response. So over a period of time, you can by elimination, identify the anonymous address of that incoming connection. My first question is: Was this possibility kept on purpose? or in other words Are we fine with peers identifying our anonymous address this way? I woul<clipped message>
-
m-relay
<syntheticbird:monero.social> d assume that it would be better to have control over that.
-
m-relay
<syntheticbird:monero.social> Thus, it came to my mind that it may be saner to insert the address once in the white peerlist at start and leave it to the peer selection to do its job when requesting some peers to send. This fixes this potential "issue", at the price of possibly fingerprinting Cuprate nodes over Monerod nodes as long as impl differs.
-
m-relay
<syntheticbird:monero.social> Thoughts? Did I miss something that would explain the current status quo? At my understand it was because of ease of implementation, but i wanted to at least bring light on this.
-
moneromooo
By "anonymous address" you mean onion or i2p address ?
-
m-relay
<syntheticbird:monero.social> yes
-
moneromooo
Does it put in its IP address if it does not have one ?
-
m-relay
<einliterflasche2:matrix.org> Hey guys, still writing a rust wrapper around wallet2_api here :) what are the thread-safety requirements for WalletManager and Wallet? I understand that because Wallet uses thread local storage, it must be accessed from a single thread. But can I spawn a thread for each Wallet? or do I need to run all ffi access over a single thread?
-
moneromooo
Does it put in its IP address if it does not have an anonymous address ?
-
m-relay
<einliterflasche2:matrix.org> Hey guys, still writing a rust wrapper around wallet2_api here :) what are the thread-safety requirements for WalletManager and Wallet? I understand that because Wallet uses thread local storage, it must be accessed from a single thread. But can I spawn a thread for each Wallet? or do I need to run all ffi access over a single thread
-
moneromooo
wallet2 is not really designed for more than one wallet at a time. It *should* be fine, but would need auditing. Maybe someone already did though. And wallet2_api is based on wallet2.
-
m-relay
<syntheticbird:monero.social> moneromooo: If the zone isn't public (meaning tor or i2p) it won't try to intepret any incoming peer as possibly join able. Moreover i'm not sure what IP address you would be refering since you can't have access to it, it would be tor daemon ip address that monerod sees
-
moneromooo
Well, it might have access to it from peers. Can't recall. If it doesn't do this, then that answers my question. I don't really have an opinion on adding one's tor/i2p address atm.
-
m-relay
<syntheticbird:monero.social> understood
-
m-relay
-
m-relay
<ofrnxmr:xmr.mx> This requires a change to wallet code
-
m-relay
<hbs:matrix.org> is that directed to me?
-
m-relay
<ofrnxmr:xmr.mx> hbs ignore. I was thinking about address labels