Revuo Monero Issue 246: August 17 - 26, 2025. revuo-xmr.com/weekly/issue-246

<j​ohn_r365:monero.social> matrix.monero.social/_matrix/media/…ero.social/ZrFCHYzhVouaixpRosrZXXwT

<j​ohn_r365:monero.social> matrix.monero.social/_matrix/media/…ero.social/ZWqGYiwdapggJkalkIhJkDVk

<j​ohn_r365:monero.social> CfB tweet: x.com/c___f___b/status/1960127265012142271

<j​ohn_r365:monero.social> I know this is old by ~13 hours, but I'm just catching up on news. Is it correct that Qubic are acting "ethically" with their re-orgs to avoid causing problems with exchanges?

<s​yntheticbird:monero.social> there is no ethics behind it

<s​hortwavesurfer2009:monero.social> Low latency things are affected most. Think exchanges and stuff like that. But the regular peer-to-peer economy isn't necessarily all that affected by this. Because it takes you longer to get products shipped in the mail, then it does to get confirmations.

<m​onerobull:matrix.org> Gate the type of exchange to send contract killers after you if you fuck with them

<m​onerobull:matrix.org> right now there is no big company with nearly infinite money on his ass, just some monero people

<m​onerobull:matrix.org> if he fucks over an exchange they could sue him into the ground

<a​lexandre:uii.pt> not so much for in person transactions tho

<f​iatdemise:matrix.org> I remember for a couple days before applying correct settings, someone was running the miner on the XMRChat server. Qubic is open source. Just throwing out an idea that it might be worthwhile to look for vulnerabilities. Would be hilarious if we could take over some Qubic miners. github.com/qubic

<o​frnxmr:xmr.mx> I remember that :P

<o​frnxmr:xmr.mx> I dont think qubic's node is publicly accessible. Their miners dont have to run nodes either

their miners are closed source in C# and just connect to a websocket run by pools

which for xmr case, point to stratum

<f​iatdemise:matrix.org> The only have 1 node?

qubic node != computor != pool

a qubic node can exist without being a computor

and multiple "computors" can exist in one node

their miner program effectively listens on a websocket for instructions, including downloading random binaries by provided URL and instantly executing them on the local computers

from what was observed these were xmr or their qubic actual miners

<r​brunner7:monero.social> Downloading random binaries and execute them on its own ... say again, which class of programs this reminds me of :)

<o​frnxmr:xmr.mx> Windows update /s

Binaries for v0.18.4.2 are now available at getmonero.org

vtnerd full-time 2025 q3 is now fully funded! ccs.getmonero.org/proposals/vtnerd-2025-q3.html @luigi1111

<s​yntheticbird:monero.social> finally

<s​yntheticbird:monero.social> congrats

thx n1oc

<s​yntheticbird:monero.social> thx n1oc

<j​effro256:monero.social> Vulnerability disclosure report: monero-project/monero #10059

<r​ucknium:monero.social> Thanks, jeffro256 . Was this found by a HackerOne report, or in FCMP wallet re-factoring? If you run your own node locally, the privacy impact is zero, right?

unless someone is inspecting your network, I guess

how does this interact with pruned trusted nodes? do these make upstream calls?

<r​brunner7:monero.social> 7 year old bug? That's a bit disheartening how long this survived.

<r​ucknium:monero.social> DataHoarder: IIRC, wallets always request pruned versions of txs. Pruned nodes never need to ask unpruned nodes for data to serve wallet requests.

<j​effro256:monero.social> This was pointed out by jberman to me in a DM. It baffled me, so I dug a bit deeper to find out how it actually works (or doesn't lol) and what triggers it. Then I made a PR to get rid of it. I would ask jberman , but I bet he saw it doing wallet work for FCMP++. If you run your own node locally, there could be a privacy impact really only if someone had a packet inspection softwa<clipped message>

<j​effro256:monero.social> re running on your machine without your consent. If using a trusted remote node, with SSL, then someone can inspect packets over the network. If using a trusted remote node with SSL, but without key authentication, someone could MitM your SSL connection and listen to the packets that way.

<j​effro256:monero.social> DataHoarder: yeah it's the exact same with pruned nodes, trusted or untrusted

👍

<j​effro256:monero.social> I need to double check, but if you're running a bootstrap wallet in GUI, I think someone rando with public RPC available gets your outgoing tx history

<j​effro256:monero.social> B/c your bootstrap node will pass the RPC request on to a random node

<j​effro256:monero.social> I wonder if the LionLink spy nodes got spoonfed tx histories this way

<o​frnxmr:monero.social> ofrnberman

<j​berman:monero.social> It was in logs that ofrnxmr shared when debugging another bug in FCMP++ fwiw

<j​effro256:monero.social> Nice

<b​oog900:monero.social> is this bug always triggered on a wallets second load after being restored?

<j​effro256:monero.social> If you look at the second paragraph of the technical explanation section, it has some more details. You have to have restored the wallet keys file as well, not just the wallet cache. But if you restored the wallet keys file, then yes, it will trigger every time

<r​ucknium:monero.social> From moneronet.info , it seems that the spy nodes in the LionLink AS don't have RPC enabled, but Digital Ocean and Hetzner ones do.

<r​ucknium:monero.social> By the way, I enabled downloading the node table there as a CSV file.

<b​oog900:monero.social> yeah I didn't understand if the wallet had to be saved in a weird state for it to be hit or not

<j​effro256:monero.social> sgp_: just continuing the convo here for cleanliness. As for whether or not it has been exploited, since it it a data leak, it is more or less impossible to know whether it has been exploited unless the exploiters tell us it has. However, any basic packet inspection software would pick up this data leak if it was recording. So, if you're using an untrusted remote node for RPC, the<clipped message>

<j​effro256:monero.social> n the answer is: probably.

<j​effro256:monero.social> Due the the Ciphertrace leaked video, we know that their spy nodes are at least monitoring the RPC endpoints for transaction submission (`/sendrawtransaction`), I don't know why they wouldn't also be monitoring the `/gettransactions` endpoint

<m​onerobull:matrix.org> Remote nodes turn out to be a privacy nightmare #503

<p​lowsof:matrix.org> cc moneromooo , who asks that we add "this is probably a spy node" when adding a remote node via the cli

<l​m:matrix.baermail.fr> Rucknium: moneroconsensus.info causes some kind of memory leak/cpu high usage on client side if you zoom out/init makes the browser try to refresh the image for every zoom %. Had to restart my computer :d

<l​m:matrix.baermail.fr> Rucknium: moneroconsensus.info causes some kind of memory leak/cpu high usage on client side if you zoom out/in. It makes the browser try to refresh the image for every zoom %. Had to restart my computer :d

<o​frnxmr:monero.social> #alwayshasbeen

<l​m:matrix.baermail.fr> that was fast !

<r​ucknium:monero.social> Louis-Marie: Sorry. Maybe I need to set `execOnResize = FALSE` rstudio/shiny #2373

<k​arakter:envs.net> it would be funny for if the server gets compromised

<k​arakter:envs.net> it would be funny if the server gets compromised

<m​onerobull:matrix.org> send out some malware that bricks the $10k servers, oopsie

<k​arakter:envs.net> that would kill rented rigs business