China just outlawed crypto transactions.

again?

china always bans bitcoin. Its not news

It's heartwarming to know this has happened in the past.

:0

But it gives me goose bumps everytime some country pushes more oppresssive regulations.

I know it's China, but...

puppy_boin[m]: I mean in the sense that if they have to try again is because it's not working.

True

Its like an episode of south park, instead of Kenny being killed, China bans crypto

I am pleased to announce that the analysis of the mid-2021 Monero transaction volume anomaly has now been published! This was a joint effort of isthmus, neptune, myself, jberman, and carrington.

Nice

> However in the case of a core wallet churning continuously through a primary address, both the “recipient” and the “change” output are sent to the same wallet, and may be combined later! Unless the anomaly exhibited extremely precise change control practices, it is likely that in many cases two outputs created by the same transaction would be consumed by the same or subsequent transactions.

Was not aware of this... How to protect against spending both the churn and its change in the same TX for regular churns? Would you need to use Feather Wallet coin control (instead of GUI Wallet) or would that just generate more churn change inputs that you can't spend with the churn?

Also what happens when you send the full amount from Wallet 1 to Wallet 2? (I use separate fresh wallets per use case.) Since Wallet 1 has no balance anymore, I guess 2 linked inputs are sent to Wallet 2?

anarkiocrypto: I am not sure. Best to ask in #monero-dev:monero.social

Guess I need Feather Wallet now. But thanks for your research and analysis.

<Rucknium[m]> "mitchellpkt.medium.com..." <- Is there a PDF of this analysis somewhere ?

ajs_[m]: sent you on some tunes for xmr.radio

a dl link through email

hope they help - let me know if any issues

Thanks midipoet

I'll upload the tracks later today

coolio

anarkiocrypto[m]: I believe sweep_single is your churn-friend

sethsimmons you can add this to the fungibility graveyard: translate.google.com/translate?sl=r…ranzaktsiyu-na-adres-obmennika-suex

jberman[m]: Would you mind posting the post-mortem on Reddit? I am sure people will have questions

Halver: Not at this time. I suppose you could print the webpage to PDF

I don't understand the following "However in the case of a core wallet churning continuously through a primary address, both the “recipient” and the “change” output are sent to the same wallet, and may be combined later! "

how is it "combined later" when if you constantly churn a wallet there is always a one input tx after everytime it receives a 2 output tx consisting of one real and one dummy zero value output

> I don't understand the following "However in the case of a core wallet churning continuously through a primary address, both the “recipient” and the “change” output are sent to the same wallet, and may be combined later! "... (full message at libera.ems.host/_matrix/media/r0/do…dc330372af1ea92800f36733fc95d75399e)

just catching up on the backlog there

anarkiocrypto: nioc It is possible that the article is incorrect about that. isthmus wrote the text of the article. I don't know enough about the reference wallet to say either way.

very easy to know if you use the wallet

My main contribution was for the "Question 2(b): Is the source one or more entities? Analyzing spend time distributions" section -- I suppose I am a specialist in that area at this point

No problem... but churn is very important for opsec reasons, so it should have been double checked with wallet devs...

> very easy to know if you use the wallet

I use the GUI wallet and don't look at xmrchain or other block explorers often, so I didn't know the details about churn. Thankful to know now.

I only use CLI and look at explorers

churning has not been well studied

I suppose we don't know at this time if the entity was self spending in the way which produces a dummy 0-value output, or in a way which produces two "valued" outputs which may be linked in future transactions from the same wallet

were they 1in/2out or 1+n in/2out ?

nioc: See miro.medium.com/max/700/0*fdp4kcX8P_Lbf96x

from the article

It appears that the entity's transactions were mostly 1in/2out and 2in/2out, with a lesser number of 3in/2out.

Rucknium[m]: thx, will read the entire thing when I have a clear head :)

nioc: It's a trip, for sure. The "Question 2(a): Is the source one or more entities? Analyzing input counts" section covers the issue from more angles.

Rucknium[m]: Source wallet sends a dummy output to a random address in case of a sweep_all

Thus if the entity churns via sweep_all, the statement is incorrect

dEBRUYNE: In that case, would you say that we could even narrow down the entity's modus operandi to the exact commands they were using with the reference wallet?

I have pinged isthmus about the possible inaccuracy in that part of the article.

Not necessarily, because on the blockchain both actions would look similar

dEBRUYNE: Which two actions?

maybe sweep_dust(?) sweep_all(?)

would this 'attack' be beneficial to an exchange to increase the number of outputs in their wallet(s)

Rucknium - Did the timestamps look random (e.g. 11:29:47 AM) or consistent (e.g. 11:30:00 AM)? Would be interested to know if it is an automated script (e.g. cron + CLI wallet).

Looks like autochurn to me, especially if it tried to spend funds around 11-15 confs.

Or maybe a script that went wrong, but over multiple weeks and $1k in fees, it seems unlikely.

Blocktime can also vary... so if the script checked every 20 mins, the TX may only have 6/10 confs and not ready to spend, or it may already have 14/10 confs and could have been spent 4 blocks ago, but the script didn't check yet.

<plowsof[m]> "would this 'attack' be beneficia..." <- Activity by an exchange is one hypothesis on the table. However, the data does not support the hypothesis that an exchange did this "to increase the number of outputs in their wallet(s)".....

One of the key "fingerprint" characteristics of the anomalous transactions was the fact that they produced 2 outputs. see the "Question 1(e): Source fingerprint — conclusions" section

If an exchange wanted more outputs to work with, they would have produced more outputs per transaction. I believe that the maximum number of outputs per transaction is 16.

That, of course, does not rule out an exchange doing something that does not involve "fanning out" its XMR holdings.

<anarkiocrypto[m]> "Rucknium - Did the timestamps..." <- Well, we only worked with data on the blockchain. So the transaction timestamps are the block timestamps. I saw some website that seemed to collect mempool activity data, so that could be useful if we could access that data. Let me see...

Rucknium[m]: Sending funds to oneself (which creates two outputs for the sender) or sweep_all (which only creates one)

So sweep_all creates a second "dummy" output that would appear on the blockchain like sending funds to oneself?

dEBRUYNE - "Sending funds to oneself" Do you mean all funds at once or a partial amount (e.g. you have 3 XMR, send 1 XMR to yourself and also receive 2 XMR change to yourself)?

Rucknium - Sweep_all is churn (sweep_single is also churn but with one specific input) and seems to send one input to yourself and one 0 XMR input to a "random address".

My interpretation:... (full message at libera.ems.host/_matrix/media/r0/do…ab3eb40bd521726568f6649583ea70508b4)

Was there increased mining hashrate during this time?

anarkiocrypto:

> If it was academic research or a bug by a third party wallet dev, maybe the person would have already admitted it.

My thoughts:

1) No, a researcher would not have necessarily admitted to it yet since they would presumably still be working on the paper. And they would prefer that no one really investigate the situation before they can publish or present at a conference so they don't get "scooped". Well, we (ad hoc analysis committee) sort of scooped them anyway 🙃 . But of course we don't have direct access to knowledge about exactly which transactions are

theirs

Researchers usually do stuff like this on a private testnet

2) The number of academic papers about Monero has risen dramatically over the past year or so. Moser et al. (2018) now has 84 citations alone. Most of those citations are in passing, but some of the citing papers focus on Monero specifically. See badge.dimensions.ai/details/id/pub.1103730181

Maybe I am naive, but if they are "experimenting" on a currency that people use today for vital real life safety, privacy and financial inclusion use cases, they should ethically at least tell someone what they are doing...

3) It is my view that a researcher at an institution with an Institutional Review Board (IRB) -- which is almost all researchers -- would have needed to file an IRB application for human subjects research, even if they believed their work was exempt. (You have to file for an exemption. You cannot just claim it.)....

we've seen researchers do unethitcal things here

Rucknium[m]: which is one of the reasons I don't believe it was academic research

like that paper being published to a new "monero.link" domain within an hour of a scheduled hardfork, with a social media campaign about how monero is 90% traceable

3) Within the next 24-48 hours I plan to announce an amnesty, I guess, for any researcher who is at an IRB institution who might not have realized that they had to file an IRB application for this research. It will come in the form of a post on the Zcash forums, among other venues, since I suspect someone monitoring the Zcash forums would also be likely to have been the "entity" if they are a researcher.

3) The amnesty would have limited impact. Basically, I would ask them to contact me privately or publicly so that they can own up to the issue wit their institution. The "limited" part of it is that one cannot file an IRB application ex post. The research may already be unpublishable in a respectable journal since it may violate professional ethics...

3) The "amnesty" to be offered is for me to not go on a fishing expedition, making queries to specific institutions about why their researchers may be doing human subjects research without IRB approval. It is much better for a researcher to own up to the mistake of their own initiative rather than have an investigation launched against them.

seems more likely to me it's a blockchain analytics company

<sech1> "Researchers usually do stuff..." <- In the private anomaly analysis room, carrington suggested that "Testnet would not replicate the impacts of dynamic blocksize upon things like block propagation, because testnet has fewer nodes with a very different topology"

<anarkiocrypto[m]> "Maybe I am naive, but if they..." <- Yes, precisely. At least their IRB. And I think this would be "non-exempt" work, so they would have had to file a detailed plan with their IRB about how they protect human subjects and have it be approved by the IRB

I think some computer scientists may not be entirely aware of their obligations under the IRB framework, since they rarely do research that meaningfully involves human subjects.

I am an economist, so I do conduct human subjects research and therefore I know the process well. And I know that they may have done something wrong here if they didn't follow proper procedures. And that will have personal/professional consequences for them if that is the case.

what do you think is the likelihood that this was done by an academic researcher?

My "Bayesian prior" is 30% probability. Just based on my intuition.

because analytics companies and LE might not agree that monero saves lives and in fact might believe that it harms lives

^ I call it professional bias

rupee[m]: Does that, in your view, affect whether an IRB application would have to be filed, in the case that it is a researcher at a university or similar institution?

I don't know anything about IRB. I just assume the CipherTraces and Chainalysises of the world don't bother asking anyone for permission. Just like Facebook and Google don't ask your permission to effectively hack your browers and track you around

> My "Bayesian prior" is 30% probability. Just based on my intuition.

What about the other 70%?

> because analytics companies and LE might not agree that monero saves lives and in fact might believe that it harms lives

Chain analysis companies, state and cops intentionally harm lives. Monero saves people from state violence, surveillance & financial exclusion caused by state KYC and corporate censorship. Of course the psychopaths who desire to control and harm people are against Monero, since Monero is a self-defense and survival tool.

* > My "Bayesian prior" is 30% probability. Just based on my intuition.

What about the other 70%?

> because analytics companies and LE might not agree that monero saves lives and in fact might believe that it harms lives

Chain analysis companies, state and cops intentionally harm lives. Monero saves people from state violence, surveillance & financial exclusion caused by state KYC and corporate censorship. Of course the psychopaths who desire to control and harm people are against Monero, since Monero is a self-defense and survival tool.

<Halver[m]> "which is one of the reasons I..." <- Why would the need to file an IRB application prevent the research from occurring?

rupee[m]: Right. CipherTrace and similar companies would not need to file an IRB application unless they were collaborating with a researcher at an institution that would require it.

anarkiocrypto: The other 70%? Well, this is extremely speculative, obviously, so "don't quote me on this", but here we go:

20% -- CipherTrace, Chainalysis or another similar company. Or some government agency doing something in-house. I would say that this is the only "malicious" entity that I list.

15% -- An exchange doing something, either with a specific purpose or accidentally

20% -- A greyhat hacker or something that is doing it for the lulz or just out of curiosity.

5% -- An individual Monero user that wanted to do _a lot_ of churning for some reason.

2-output transactions are very inefficient for floodxmr attack, so Chainalysis is unlikely

10% -- A Monero "hodler" who wanted to push the dev team to fix the flood issue. SOmething like this may have happened with Nano earlier this year.

5% -- There was some other specific idea that someone mentioned, but I cannot remember it.

15% -- Something no one has considered.

I think you're above 100% in total already :D

^ I admit that, plus the 30% researcher probability, that adds up to 120% probability, which violates an axiom of probability theory, but you get the idea :)

What about autochurn script? Although I guess this could be done by any of the above people.

<Rucknium[m]> "Why would the need to file an..." <- I didn't think the IRB application is the point. It's just one point among others.

The main point which may me think it's not an academic research is the **volume** of txs involved.

This volume looks imo much more like a stress test than anything else. It's like _"look what we can reach in a 1st phase"_.

Just multiply those probabilities by (70/90), I suppose

What I was thinking when reading the report: It's not trivial, and it takes time to prepare a wallet with the thousands of spendable outputs that probably were available at the start of the action

Halver: Yes, I do think that this could be a "1st phase" exploration by a malicious entity. So not an attack in and of itself, but rather gathering info in preparation for a real attack.

1 outputs can be spend every ~20 minutes, so 300 outputs is enough to flood 20,000 tx/day

Yes, but I understood that was one of the results of the investigation: At start, *a lot* of spendable outputs were available

rbrunner: Yes, we have speculated that the first streak of red in the very last graph of the article may have been evidence of the production of the outputs that were eventually used in the flood incident.

There is more than enough questions for a 2nd part of an analysis of the anomaly. We had to cut things off at some point and publish the initial findings, however.

"10% -- A Monero "hodler" who wanted to push the dev team to fix the flood issue" I can somehow sympathize with this, after things like the "1 letter per tx" messenger proposal ...

And this flood of course

Does a flood attack have any other risks other than decoy deanonymization?

I am not sure. I think there is a minor risk of low-performance nodes having syncing problems temporarily. And there is the issue with bloat to the blockchain, long term.

rbrunner: 1 letter per tx is the future of messaging

selsta: Yeah, and patent pending I guess.

<selsta> "rbrunner: 1 letter per tx is the..." <- Tfw your monero stack is just 10000 prepaid text messages

<selsta> "rbrunner: 1 letter per tx is the..." <- you get paid the more people want to message you!

i'm not offering payout in virtual options as well as cash in mail on my site

Cash by mail | Venmo | Zelle | Paypal | Cash app | Apple Pay | Google Wallet | Gift Card

When next Fork? Ring size increase and bp+ ? Nov or dec ?