<s​tnby:kernal.eu> 37.27.0.0/16 belongs to Hetzner. But isnt your own node on Hetzner too 😉

node3 is hetzner, and in another range

ive handed over 345 potential malicious nodes over for investigation

37.187.74.171 is node3

so im certain the 37.27 node you list will be added to a banlist , thanks, and hopefully the others. all they do is purchase more ip's but we can try

<g​ingeropolous:monero.social> moneroworld much sus. but original homepage

<g​ingeropolous:monero.social> much html skilz

kewbit, I wish there also was a place to buy virtual hats for Monero. I know there are some marketplaces like this that accept BTC already.

<n​yx:nyxmr.top> *virtual* hats?

<n​yx:nyxmr.top> why not physical hats

<n​eromonero1024:monero.social> as in, nft???

<n​ihilist:nowhere.moe> How do you even detect the malicious nodes in the first place ?

neromonero1024, kinda, but without the redundancy of the blockchain since they're in a particular game anyway - innovation!

<n​eromonero1024:monero.social> I'm assuming it's by looking at the ownership of the ip address?

<n​eromonero1024:monero.social> I'm assuming it's by looking at the ownership of the ip address?

<n​eromonero1024:monero.social> edit: honestly, I'd also like to know the details

<k​ewbit:matrix.org> Not sure about hat but I’ve for all 4 minecon capes on my account 😂

<k​ewbit:matrix.org> Not sure about hats but I’ve for all 4 minecon capes on my account 😂

As a child, I thought I would get a legit Minecraft license as an adult. But with Microsoft account and shenanigans like chat control - I guess this is not happening, staying a pirate)

<k​ewbit:matrix.org> m.youtube.com/watch?v=wsO-Td0hqXo - If you were wondering about your full node spec

So... Were some nodes using hijacked addresses or what?

<k​ewbit:matrix.org> 🤷‍♂️

<n​ihilist:nowhere.moe> ah i think that's from this article digilol.net/blog/chainanalysis-malicious-xmr.html

<3​21bob321:monero.social> proxying

<d​ufebo98:monero.social> one of these can prevents Chainalysis from compromising your privacy. Running your own node/using tor/FCMP++

<n​ononynous:monero.social> Is there stats to know what percentage of monero transactions are broadcasted/relayed over Tor ?

<n​ononynous:monero.social> I tried to make something tricky before but it's not fully reliable

<n​ononynous:monero.social> On torrc I open 2 socks proxy

<n​ononynous:monero.social> One normal and one with OnionTrafficOnly

<n​ononynous:monero.social> On monerod I do --proxy (proxy-1) --tx-proxy tor,(proxy2)

<n​ononynous:monero.social> Node network traffic is routed over tor but can use exit nodes, when it's for transaction relaying it forces to only use hidden services to relay transactions

<n​ononynous:monero.social> I wanted to use proxy-2 for basic node traffic but it wasn't fully reliable

<n​ononynous:monero.social> But if all nodes were using tx-proxy, it could make dandelion++ over killed because it's wrapped in tor

<n​ononynous:monero.social> But if all nodes were using tx-proxy, it could make dandelion++ overkilled because it's wrapped in tor

<p​reland:monero.social> cointelegraph.com/news/chainalysis-leak-monero-traceability

<p​reland:monero.social> Lul

<p​reland:monero.social> matrix.monero.social/_matrix/media/…ero.social/gisLVsbVehwSsCpOrJWWKfOb

<p​reland:monero.social> Also which one of y’all forgot to check their email lol

Best they could think of is to send a DM to Monero twitter account

Or worse, Discord

<p​reland:monero.social> “We are excited to announce that we completely dropped the ball and allowed disinformation about the currency to spread”

lol

we can neither disallow or allow people to spread lies

<s​tnby:kernal.eu> Owner of captaincanaryllc.com / 185.218.124.120 contacted me. We managed to verify it's not a proxy. Either a false positive or proxy is rotating over multiple nodes in a round robin.

<b​asses:matrix.org> protos.com/no-moneros-privacy-didnt…-suddenly-break-in-this-viral-video

<b​asses:matrix.org> decent article but what is that?

<b​asses:matrix.org> >They recommended IP-obfuscating services like Dandelion.

<s​yntheticbird:monero.social> what

<s​yntheticbird:monero.social> dandelion is a vpn now?

greetings all! I'm reporting on the recent Chainanalysis training video that did a kiddy investigation with internal Chainanalysis tooling. This was picked up by CoinTelegraph which did terrible reporting on it (I don't think they even saw the video), and tried to make it seem like XMR is traceable. When watching the video its obvious tracing XMR

is almost impossible, and I'm hoping to do a better write up to set the record straight, including getting comments from you all. For those interested, the article will be posted on takebackourtech.org

You can find the video I'm referring to here: archive.org/details/chainalysis_XMR

I would appreciate any comments from the community or Monero contributors on the issue and the following questions:

- Given that Chainanalysis is running Monero nodes, one could assume the IRS and other entities are running Monero nodes in the hopes that people connect directly to them (or reverse proxying them), exposing their IP address. Is this a valid threat, and is there anyway to identify malicious nodes and get them blacklisted from the network?

- The video at around 20:00 minutes refers to the Chainanalysis tool ruling out decoy transaction using different heuristics, such as previously being spent. In the video, it ruled out many decoy outputs and the instructor says to 'ignore' those. How feasible is it for Chainanalysis to do this, and what heuristics might they be using?

Thank you in advance.

<r​ecanman:kernal.eu> Guest28 regarding the nodes question, this will help you: digilol.net/blog/chainanalysis-malicious-xmr.html

<r​ecanman:kernal.eu> Nodes are nodes and they cannot be identified unless they exhibit strnage behavior like what is mentioned here

<r​ucknium:monero.social> By the way, m-relay is a relay to Matrix. Look for the username inside the relay message

<r​ucknium:monero.social> What I didn't see in the video was any discussion of the false positive rate of these techniques. That's a big criticism I have about many blockchain surveillance companies, as a scientist: There is little evaluation of the uncertainty inherent in their findings. That can easily cause false accusations, just like people in the past were falsely accused based on unscientific analys<clipped message>

<r​ucknium:monero.social> is of arson patterns, ballistics, and bite marks in criminal forensics.

<r​ucknium:monero.social> To answer your first question:

<r​ucknium:monero.social> Spy nodes can play two roles. First, they can act as malicious remote nodes to de-anonymize users who do not run their own nodes and instead use remote nodes to submit transactions to the network. If users connect to those remote nodes without any proxy like a VPN, Tor, or I2P, then their home IP addresses can be exposed.

<r​ucknium:monero.social> Second, they can listen for transactions as they are relayed between nodes to try to find which node was the first one broadcast the transaction, which is the actual source node of the transaction. As the Chainalysis employee said, the Dandelion++ protocol implemented in Monero in 2020 made this type of de-anonymization attack much more difficult. There's an alternative to Dandeli<clipped message>

<r​ucknium:monero.social> on++ called Clover that could provide better privacy in certain cases. Myself and other Monero Research Lab researchers may evaluate Clover for possible implementation in Monero.

<r​ucknium:monero.social> No one needs permission to join the Monero network. It is decentralized. There is not a reliable way to know which nodes may be spy nodes if the spies decide to blend in, but Monero's node connection code tries to be connect to a diversity of IP addresses in the IP address space to avoid connecting to too many nodes that may be controlled by one entity.

<r​ucknium:monero.social> There are a couple of solutions to the remote node problem. First, users can run a node on their own computer instead of relying on a remote node that may be malicious. In the most recent version of the Monero GUI wallet, pruning was enabled by default ( github.com/monero-project/monero-gui/releases/tag/v0.18.3.4 ). Pruning cuts the required disk space to run a node in hal<clipped message>

<r​ucknium:monero.social> f. Before the change in the pruning default, I performed an analysis of the safety of having more pruned nodes on the network in Appendix B of github.com/Rucknium/misc-research/b…ck-marble-optimal-fee-ring-size.pdf

<r​ucknium:monero.social> If users cannot run their own node, they can use a proxy like Tor to connect to remote nodes. There are still some risks when using remote nodes like nodes lying about the necessary transaction fees, but at least a proxy will shield a user's IP address from the malicious node. Users can ask someone they trust to run a node for them, and only connect to that node.

<r​ucknium:monero.social> On the second question:

Can you run a node if you can't have it active 24/7? Like, only turn it on when you're actively using it?

BlueyHealer: yes, but it will take couple minutes to sync it up

<r​ucknium:monero.social> B​lueyHealer: Yes. But for best privacy it is good to have it running for as much time as you can so that an adversary cannot get more timing information.

or longer than a couple minutes depending on your hardware :D

<r​ucknium:monero.social> In their case study, a large consolidation transaction was helpful to Chainalysis to generate a hypothesis of which ring members were the real spend. They had information about transaction outputs sent by a single coin swapper, MorphSwap. Large consolidations are known to be risky with ring signatures when an adversary has a large amount of information about which outputs a single<clipped message>

<r​ucknium:monero.social> user owns. Chainalysis basically performs an Eve-Alice-EVE (EAE) attack, an attack that the Monero Research Lab has theorized. Chainalysis use the consolidation transaction for the first leg of the attack and then the IP address gathered by a malicious remote Monero node for the second leg.

Ah, okay. So it is fine if I run it like I run my torrents, whenever the laptop is on.

Thanks?

<r​ucknium:monero.social> Different transaction fees was at the top of their list of ways to distinguish transactions. I worked on fee uniformity a lot last year. I developed a formula for the privacy risk of the non-uniform fees, identified non-uniform fees in the blockchain data, and asked Exodus wallet to fix their non-standard Monero fees. Justin Berman fixed some fee uniformity issues in MyMonero a fe<clipped message>

<r​ucknium:monero.social> w years ago. Links:

s/?/!

<r​ucknium:monero.social> github.com/Rucknium/misc-research/b…-spend-with-fungibility-defects.pdf

<r​ucknium:monero.social> github.com/Rucknium/misc-research/tree/main/Monero-Nonstandard-Fees

<r​ucknium:monero.social> old.reddit.com/r/Monero/comments/17…sory_exodus_desktop_users_update_to

<r​ucknium:monero.social> mymonero/mymonero-core-cpp #36

<r​ucknium:monero.social> In the future, Monero could consider requiring standard fees by blockchain consensus rules. It's tricky because you're messing with economic forces. If you're clumsy when you do that, economic forces have a way of messing with _you_.

<r​ucknium:monero.social> END. Guest28: You can refer to me as Rucknium, a statistician with the Monero Research Lab.

rucknium, Thank you for that thoughtful and informative reply. I've captured it and will make sure your full response is included in the article.

Follow up: You mention the consolidation transactions, I just want to make sure i'm understanding this correctly. In this case MorphToken was cooperating with the attacker and shared its local Monero transactions that were related to this user. Because they could confirm that these outputs were previously spent, it helped identify the co-spends

made later on?

<r​ucknium:monero.social> In my opinion, the video isn't completely clear about this. Maybe there are three ways that the parent transaction outputs could have been labeled "MorphToken" (Sorry, I called it MorphSwap before).

<r​ucknium:monero.social> 1) (Least amount of info given to Chainalysis.) There was no formal relationship between Chainalysis and MorphToken. Chainalysis used its spy nodes to figure out which node was broadcasting MorphToken-related transactions. This kind of analysis would have a lot of error because of Dandelion++.

<r​ucknium:monero.social> 2) (Medium amount of info given to Chainalysis.) MorphToken told Chainalysis which transactions it sent, but did not give any other info. This would mean that Chainalysis would know which transaction outputs MorphToken was responsible for, but not which user they were sent to. So this would allow Chainalysis to narrow things down.

<r​ucknium:monero.social> 3) (Most info given to Chainalysis.) MorphToken collected a lot of information about swaps, including possible personally identification info about people like IP address and which coins they were swapping from. (i.e. if a cluster of bitcoin addresses were swapping frequently with Morphtoken, then likely the same user was swapping many times.) This info is possibly given to Chainalysis.