Monero Research Lab Meeting - Wed 11 October 2023, 17:00 UTC

Logs

< Rucknium > Meeting in this room in 1.5 hours.

< Rucknium > Meeting time! https://github.com/monero-project/meta/issues/908

< Rucknium > 1. Greetings

< rbrunner > Hello

< vtnerd:monero.social > Hi

< Rucknium > 2. Updates. What is everyone working on?

< vtnerd:monero.social > Me: back on subaddressses. No ETA, but been contacted by multiple people about it now, so it's hopefully done soon^tm

< Rucknium > me: Writing down some early thoughts about analyzing PocketChange privacy. I also read the Ciphertrace employee's statement for the defense in the Bitcoin Fog case.

< rbrunner > Anything really surprising there, in that statement?

< Rucknium > Yes. It is interesting to see Chainalysis and Ciphertrace fight. I can discuss in the discussion section.

< Rucknium > 3. Discussion. What do we want to discuss?

< rbrunner > If nothing else pressing, please do report about that fight :)

< Rucknium > Here is the filing from the Ciphertrace employee: https://storage.courtlistener.com/recap/gov.uscourts.dcd.232431/gov.uscourts.dcd.232431.159.1.pdf

< Rucknium > This was filed after a short filing from Chaianlysis that responded to some questions by the court. The Chainalysis statement said that their methodology was not peer reviewed and it did not have a defined false positive rate (error rate).

< Rucknium > My opinion is that the problems with Chaianlysis's methodology do not mean that blockchain surveillance is completely ineffective (i.e. that bitcoin privacy is "good enough"), but that Chainalysis's methodology is unscientific and unfit for producing the evidence up to the standard of proof in a legal system with strong protections for the accused.

< Rucknium > If blockchain surveillance is more scientific, then yes bitcoin still has major privacy problems.

< Rucknium > The Ciphertrace filing criticized the lack of false positive rates and Chainalysis's use of expanded change output classification rules. They call it "heuristic 2 (behavioral)", which I guess has some meaning in the original case documents that I have not read.

< Rucknium > "Therefore, the discrepancy rate between Ciphertrace and Chainalysis Bitcoin Fog attribution is roughly 67%."

< rbrunner > Those pages and pages of documented errors are pretty depressing, and damning.

< Rucknium > The filing also has discrepancy rates for other entities like AlphaBay

< rbrunner > Found it.

< rbrunner > This is a quite rare look into the workings of these companies, right? Probably so far only their customers get such details.

< Rucknium > The filing from the Ciphertrace employee says that maybe the defendant (Roman Sterlingov) was accused since he had the only KYC'ed account among all the suspected Bitcoin Fog operator withdrawals.

< rbrunner > Did you find any heuristic in there that surprised you personally? That you never heard about, or thought that it would not work well enough?

< Rucknium > Consider if the defendant was targeted by a different entity in a different place. Would a dictatorship allow him to review the evidence against him? What about a criminal gang coming to rob him? False accusations are as big of a threat, if not more, to users of transparent coins.

< Rucknium > rbrunner: Mostly the filing refers to papers that have been posted publicly. One "new" statement is that Ciphertrace said that they do try to link bitcoin addresses/txs to IP addresses: "Ciphertrace collects IP addresses via our own node operation and links them to bitcoin addresses."

< Rucknium > That's not surprising, but I had not seen a public statement from them that this is part of their surveillance

< rbrunner > Ok

< rbrunner > After reading this diagonally, Ciphertrace looks anyway much more "dangerous" than their competitor there ...

< Rucknium > "Blockchain forensics should only be used to generate investigatory leads. Standing alone, they are insufficient as a primary source of evidence. What is striking about this case is the conclusions reached without any corroborating evidence for the blockchain forensics."

< Rucknium > My note on Monero real spend classification using tx fungibility defects has a formula for the false positive rate, so I am ahead of Chainalysis in that regard: https://github.com/Rucknium/misc-research/tree/main/Monero-Fungibility-Defect-Classifier/pdf

< rbrunner > :)

< Rucknium > Ciphertrace was purchased by MasterCard, so their business outlook may be different from Chainalysis now.

< rbrunner > Maybe they looked at both before buying and reached a good conclusion

< Rucknium > Standards of evidence are going to be different for a court of law and advertising targeting, to take the two extremes.

< rbrunner > The court case will go on, based on these filings, I assume?

< Rucknium > MasterCard is probably doing regulatory compliance based on risks scores. Maybe some ad targeting too

< Rucknium > I guess so. I think the prosecution is pushing for a plea deal like usual, so maybe they are in plea deal negotiations or if the defense thinks their side is strong enough they could take it to an actual trial.

< rbrunner > Somehow amazing how all those cryptocurrency funds and ETFs that spring up now risk loss of some of their funds because they turn out to be "dirty"

< rbrunner > No wonder MasterCard tries to find something solid

< Rucknium > Ironically Ciphretrace has permitted no peer review of their Monero "tracing" methodology. I would have guessed with the Mastercard purchase that they would stop working on it, but IIRC they released a statement at the August 2022 hard fork saying you can run but you can't hide, Monero users.

< Rucknium > Anyway, I have been thinking about the privacy impact of users of Monerujo's PocketChange (and any similar system) to split wallet contents into multiple outputs to get around the 10 block lock.

< Rucknium > There are two components: privacy before the PC tx and privacy after.

< Rucknium > The biggest privacy impact in the post-PC txs would be if transactions consolidate outputs from the PC tx in a single tx later.

< Rucknium > You would see two or more rings in the later tx that reference multiple outputs from the original PC tx

< Rucknium > So we would want to know how often that ring pattern would occur as a coincidence when a tx actually has nothing to do with a PC tx

< rbrunner > I guess such a consolidation can happen quite easily

< Rucknium > I think that the false positive rate is going to be a function of the number of txs on the blockchain with more than two outputs, their age, and the decoy selection algorithm.

< Rucknium > All roads lead back to the decoy selection algorithm and questions about what wallet2 actually does.

< Rucknium > The DSA wasn't very important for the analysis of guessibility of real spends with tx fungibility defects because....well, just because

< rbrunner > This consolidation problem does not get smaller if more and more wallets start to implement such a feature, right?

< Rucknium > But how densely the DSA selects from certain regions of the output set matters a lot for PC analysis because the probability of selecting multiple outputs from the same exact transaction in a large sea of transactions is going to depend a lot of how big that sea is.

< Rucknium > rbrunner: I think if there are more txs with greater than two outputs on chain, then a classification rule that uses multiple outputs from the same tx would have a higher false positive rate. How much more? The math has to be written.

< Rucknium > I don't think I will develop the PocketChange analysis much further at this time unless I get a sudden lightning bolt of insight. I would probably put it in a list of possible projects to work on in a CCS later.

< Rucknium > Priorities would be set partially based on community input.

< Rucknium > I am giving advice to a research group that is planning to recreate the BTC transaction graph with Monero rules. gingeropolous thought it would be a good idea to do that.

< Rucknium > A lot of things need to be modified. I am wondering if I am missing anything:

< rbrunner > I don't understand. BTC transaction graph with Monero rules - what rules?

< Rucknium > You need to eliminate the 10 block lock and even allow child txs within the same block. I guess you could do the idea of referencing by TXID instead out sequential output index

< Rucknium > Have a private testnet where you broadcast and confirm the same txs in the BTC blockchain, but with monerod.

< Rucknium > tx verification for mining blocks is going to take a very long time. I wonder if there is a way to just turn it off.

< rbrunner > Sound a bit crazy, at first read.

< Rucknium > They will need a lot of SSD space. I guess 3 TB at least

< Rucknium > Why is it crazy?

< rbrunner > Maybe I don't understand yet how that could possibly be useful.

< Rucknium > You need coin emission to match BTC's emission.

< rbrunner > Should this demonstrate that we could handle the same amount of transactions?

< Rucknium > There are databases with entity labels on BTC transactions and addresses. Like centralized exchanges. The BTC tx graph can give you the behavioral parameters to simulate what EAE attacks could look like.

< Rucknium > The main purpose of doing this would be to analyze the privacy of Monero when you have a ground truth of what an actual tx graph would be.

< Rucknium > You would need to eliminate the limit on the number of tx outputs.

< rbrunner > You mean you could let loose some heuristics on that new Monero-fied blockchain and then could see exactly how good they were?

< Rucknium > Yes

< rbrunner > Clever. But probably is anything but trivial.

< rbrunner > But already the dropped 10 block limit would disturb things, I guess

< Rucknium > Why not just create a simulation in Python or R? There would be pros and cons to doing a simulation. A real blockchain is what the research group wants to do.

< rbrunner > So let them research, I would say :)

< Rucknium > Methods based on timing analysis wouldn't apply in the exact same way, right.

< Rucknium > Right, but I want to warn them if there's things that need to be modified so they are not surprised later.

< rbrunner > Good idea. I think mining is no problem, you can easily accept arbitrarily low difficulties.

< rbrunner > There is a switch in monerod already I think for that, to create a large blockchain easily

< Rucknium > Yes. I pointed them to https://github.com/moneroexamples/private-testnet

< rbrunner > Yup, " --fixed-difficulty 100 " as a daemon start flag

< rbrunner > Maybe the growth limits of the blocks need to get relaxed

< rbrunner > Or even dropped, if you want the same transactions in the same blocks?

< Rucknium > We can end the meeting. Let me know if you think of anything major that they would have to modify.

Automated by this

monero-project / meta

Monero Research Lab Meeting - Wed 11 October 2023, 17:00 UTC #908

905