Very nice work on the interview guys. My short list of interesting things that were mentioned:

1. "some exchanges share voluntarily, most do not, so there is an art to that"

2. "ip address information is used" -> perhaps they use isp monitoring to assist?

3. they are sending poisoned outputs to mount active attacks

4. They didn't explicitly say they spam the blockchain with txs to reduce anonymous decoys available. But I would not be surprised if they send a burst of fake txs immediately after a tx of interest, to reduce the chances of a churned tx then sourcing good decoys

if ISPs are assisting, then you can know when certain wallets jump online and make txs, if people only sync their wallets when about to send or receive a tx

might be time to consider some sort of automated background churn

I wonder if churn txs could be constructed in advance without waiting for the balance to become available, and the node they're sent to could just wait until they're spendable, or if that would mess up the output selection distribution (since it wouldn't be able to select more recent outs)

but maybe not selecting outs from the most recent few blocks isn't a bad thing

i've been looking at "forward anonymity set sizes", meaning after an output is received, how many txs on the blockchain will end up directly or indirectly referencing those outputs

and the results are good over significant periods

but if churn is automated such that it happens quickly, it's not so good

here are the stats I just ran on 10 random outputs from July:

outputIds: [19584417, 19592166, 19583074, 19577487, 19588150, 19599373, 19578981, 19571263, 19594080, 19589986]

observ. period (hours): 1, fwd tx anon set: 1, 0, 2, 4, 1, 0, 1, 0, 4, 3

observ. period (hours): 2, fwd tx anon set: 3, 8, 8, 15, 12, 6, 6, 0, 60, 13

observ. period (hours): 3, fwd tx anon set: 13, 89, 46, 70, 99, 42, 20, 0, 309, 72

observ. period (hours): 4, fwd tx anon set: 94, 323, 260, 294, 378, 186, 100, 4, 729, 252

observ. period (hours): 5, fwd tx anon set: 386, 840, 555, 721, 815, 588, 386, 22, 1416, 841

observ. period (hours): 6, fwd tx anon set: 824, 1576, 959, 1168, 1281, 1044, 750, 115, 2048, 1402

observ. period (hours): 12, fwd tx anon set: 4317, 4855, 4357, 3914, 5189, 3937, 3563, 2531, 5250, 5179

observ. period (hours): 24, fwd tx anon set: 10765, 10546, 11150, 11097, 11174, 9735, 10700, 9536, 10886, 10935

observ. period (hours): 48, fwd tx anon set: 22221, 22521, 22480, 22745, 22839, 22670, 22345, 21656, 23312, 22676

observ. period (hours): 96, fwd tx anon set: 49754, 49763, 49942, 49717, 50276, 49118, 49446, 47691, 50150, 49792

ok so churn has to be automated, but the wallet has to be open so that it can do so intelligently?

s/has to/can be

good bot

yeah churn would need to happen automatically over longer periods than just "6 churns in 6 hours"

but if we recommend churns, this causes a blockchain bloat problem, and a wallet scanning time problem

See "The wallet scanning-time problem quantified" here: monero-project/research-lab #75#issuecomment-663935804

If the transaction volume were to increase 30x from here, it would take 86 hours per year of transactions scanned""

so churning would help accelerate the increase in tx volume times, and wallet scanning times would be a major problem

s/in tx volume times/in tx volume

sooner or later, we're going to need to take the wallet-scanning-time issue seriously

I've watched the whole interview and honestly I'm disappointed. The CEO Dave has unique ability to say a lot of words without disclosing a bit of information. He basically said they use "all known methods" and do use poisoned outputs.

Plus they do flag benign transactions if they happen to use wrong ring members, what a joke

all of the interesting attacks on monero involve using off-chain information, and the extent of that information will be the extent of their ability to trace

so we can't just dismiss this by talking about how ring signatures are great.

or by saying "nothing new here". if anything, if this is nothing new, and it's a problem we've known about, we need to fix it and provide proper usage guidance, instead of just saying "yeah we did an episode of Breaking Monero about that, old news"

Not much we can do against guys who willingly want to paint benign transactions as tainted

but yes, people should be more aware of best usage practices

yeah i don't have much confidence in his claim of being able to mark txs as involving tainted funds

that seems a bit ridiculous

it is COMPLETELY arbitrary

what would make more sense is if they were doing this: exchanges might not generally be willing to share all tx data, but i can see them being willing to notify a tracing company if they encounter any txs (in the past or future) that reference a certain output

and then share customer info only on those occasions

maybe just account ids at first

but if there is a pattern with certain account ids, they could easily be asked to then disclose more

so their system would be a tool to get exchanges to disclose information they would not do so in a blanket fashion, and that would account for his statement that there is an "art" to getting exchanges to disclose info

as long as they can claim a possible connection, even if they're wrong 95%+ of the time, that'd be enough to extract enough useful info to refine their tracing

another stat: I took 1000 random outputs from July, and observed that 309 of them were not then referenced in further txs within an hour

so higher ring sizes could help with that perhaps

141 of 1000 not referenced within 2 hours

higher ring sizes or a larger amount weighted forwards

but higher ring sizes should be manageable atm

good point, yes i like the idea of a 'hot zone' where we try and make sure everything gets picked up multiple times

I suppose Triptych (or variant) will take care of that

Thanks sarang and sgp_ for the YT interview with Ciphertrace.

<knaccc> or by saying "nothing new here". if anything, if this is nothing new, and it's a problem we've known about, we need to fix it and provide proper usage guidance, instead of just saying "yeah we did an episode of Breaking Monero about that, old news" >>> yeah, this sorta feels similar to when MRL001 indicated we needed bigger ringsizes, or something

and then someone called us out, and the response was "well we knew about it"

so ringsize a bajillion?

ringsize 100k does solve the probem

ok, what're the numbers on that puppy.

processing times, sizes, etc.

too big 4 u

I'm putting together this document to send to CipherTrace this AM with some more specific questions. Please add questions if you have them, but of course take extra effort to keep them professional: monero.sandcats.io/shared/QVo56B5-M76D88sArgVBbjnaJVltp7562CUuUsY3Nbc

Also please review the questions that are already there

are they willing to take the time to write up an essay in response? i'd imagine it'd be much easier to get it out of a phone call

I don't have any reason to believe CipherTrace would be dishonest in their answers, but I also don't have any reason to believe they'd go out of their way to provide details (they aren't obligated to answer any of these!)

I'd be glad to ask them on a call if they prefer, sure

i'd just imagine it's easier for a human to spend 20 mins on the phone with you than spend 20 mins writing an essay

On the other hand, Dave might not want his technical staff to answer directly without some kind of vetting of the responses and questions

true

Who knows; might as well provide written questions and offer to discuss however they wish (if they choose to discuss at all)

I have added/updated questions

questions sent, thanks

neat

well, even if too big, would be nice to know what the "cost of ideal", and see how we can make successive approximations

If what they are saying is true what should we do to protect our privacy?

TBH it's not entirely clear to me _what_ they're saying at this point, even after the interview

How can they claim it? "This provides ways to track stolen Monero currencies or Monero currencies used in illegal transactions". I'm thinking that it could be a snowball attack

What do you mean by "snowball attack"?

The attack described on Breaking Monero 09 monerooutreach.org/breaking-monero/poisoned-outputs.html

Oh, examining transaction paths between known endpoints?

That becomes a graph matching and probability problem

If I were them, that's probably a technique that I would use where applicable

Maybe they got the majority of decoys tho

There's a new set of ECC releases about "Halo 2." New sample code

Interesting; they switch from Sonic to PLONK

I would view the deployment timeline with raised eyebrows, but who knows

Now to see benchmarks!

That timeline seems a tad optimistic

Eh, it's a press release

Following the code will be far more interesting

It's neat research

Were you able to find some benchmarks?

I'm still perusing

The post is a little confusing

It seems to imply that PLONK support is not there yet, but there is PLONK-related code in the repo

Hmm, commit messages imply some stuff may still be broken, so I dunno

Doesn't appear to be any benchmarking just yet

Would depend on circuit structure, presumably

and if they intend to deploy, they'd need it to scale to something the size of the Sapling/Heartwood/etc. circuit

I'm told the questions have been forwarded

Hopeful for at least some basic responses, but the more the merrier

Forwarded to whom? The people on Dave's team who build the tools?

I have set my expectations low (they are a company, after all), but hope to be pleasantly surprised :D

I think it's pretty obvious what they do though isn't it?

It's known attack vectors

There isn't anything new

Is it just confirmation that we are wishing for

So we discredit the efficacy of it

And the accuracy

In the interview, it was implied that the technique involved many known methods, but also some kind of unknown sauce

Without justification or evidence or details, it's not possible to verify any of this

The unknown sauce is just spamming the network

That is not documented in any research, is it?

no, I think they mean sending users txes

No formal research anyways?

not network spam

for later recombination

known suspects?

There's no way to know what they do

What users?

They might have been telling the truth, stretching it, or being dishonest

Designing with any claims in mind that have no evidence is foolish anyway

The interview is all self-reported data

Whether or not they actually have a product that does what they have implied/claimed, they have absolutely succeeded at spreading the news about these implications/claims

Hmm, what if we put together a CCS to become a CT customer, so that we can analyze its capabilities

I'm sure MRL could have a field day testing their abilities

And it'd be a good investment. We're currently fighting blind in an arms race

"Monero community funds chain analysis companies"

Well, not so much fighting, as having someone else write a letter saying they have powerful tools

they have the best tools

some very smart people told them

the smartest

I think it's important not to blindly discount the potential risks of the protocol, but also important is: en.wikipedia.org/wiki/Hitchens%27s_razor

good bot

Isthmus: that is a good idea I think. There is no reason the community couldn't buy the analysis tool

it makes perfect sense to

There would 100% be an NDA

Sure

and Big Fancy Legal Theats for violating it

sure

I am not interested in talking to lawyers about this

that sounds like months of your life you don't get back

Every month we don't get back

Might as well smile along the way

I'm saying "buying" the tools doesn't work

You'd probably send them some txns, and get some data back, but are under strict NDA about not sharing them anyway

So unless you want to tangle with expensive lawyers, you gain nothing

And if you do want to tangle with expensive lawyers, you have strange ideas of fun...

oh. I forgot the AaaS

?

Analysis as a Service

aye

I don't know this is how it works, but it is my assumption

I would be super surprised if they just shipped you the whole damn tool

That seems terrible for business

Maybe you get some kind of viewing interface for your particular case

But still can't share anything under NDA

Oh no. I wouldn't share my transaction information. That would be silly

And another brief reminder that sgp_ and I did write specific technical questions that were sent to Dave Jevans earlier today

They may respond with details, and they might not

But I am certainly willing to give them the professional courtesy of a few days to respond, should they choose to

i have some interesting stats

let's say you pick 100 pairs of outputs at random from the blockchain, where those outputs were created within 7 days of each other

and all pairs were created during or after Jun 2020

how many of those randomly picked pairs will be spent together, by chance, at some point in the future?

the answer: merges detected: 0 of 100 for 2 poisoned outputs

i'm running it again now to do the analysis again for 1000 random pairs, but it takes quite a while

next question:

what if users churned each output in each random pair, prior to merging?

wait, 0 of 100 means it would be very detectable?

so 'this would not happen by random chance'?

exactly, the false positive rate is near 0%, so the spend is ultra-high probability

So this is effectively iterated EAE, right?

to clarify.

yes. so now we look at merges detected for each random pair, during different levels of churn

churn window (hours): 24

merges detected: 1 of 10 for 2 poisoned outputs at churn level: 1

merges detected: 0 of 10 for 3 poisoned outputs at churn level: 1

merges detected: 0 of 10 for 4 poisoned outputs at churn level: 1

merges detected: 0 of 10 for 5 poisoned outputs at churn level: 1

merges detected: 0 of 10 for 6 poisoned outputs at churn level: 1

merges detected: 10 of 10 for 2 poisoned outputs at churn level: 2

merges detected: 8 of 10 for 3 poisoned outputs at churn level: 2

merges detected: 1 of 10 for 4 poisoned outputs at churn level: 2

merges detected: 1 of 10 for 5 poisoned outputs at churn level: 2

merges detected: 0 of 10 for 6 poisoned outputs at churn level: 2

merges detected: 9 of 10 for 2 poisoned outputs at churn level: 3

merges detected: 10 of 10 for 3 poisoned outputs at churn level: 3

merges detected: 10 of 10 for 4 poisoned outputs at churn level: 3

merges detected: 10 of 10 for 5 poisoned outputs at churn level: 3

merges detected: 3 of 10 for 6 poisoned outputs at churn level: 3

ok so i'll explain this:

it explains itself

:D

so what happens if someone churns n outputs independently inside a 24hr window

If you want to get effective privacy off of up to 5 outputs, churn 3 times and you're good

within the same window

how many random sets taken from the blockchain show false positives

and yes the false positive rate can get really good

but the problem is you get no false positives if you simply increase the poisoned output count

nah

but you also get higher false positives if you simply increase the number of churns

you havent run the numbers far enough

what should i run

Its a growth rate thing

well the thing is, you can get complete anonymity if you churn enough

poisoned outputs are linear

churns are exponential

right, so you can always beat any number of poisoned outputs if outputs are churned enough, i think

I suspect if you push churns to like, 8, and poisoned outputs to 30, you'll be surprised at the result

'enough' is something like a log on the number of outputs

its not a linear growth thing

there is a churn level where the anonymity set size starts to become "everything"

at least, I suspect.

Try 30 poisoned, 8 churn.

8 churn probably way too high to do in reasonable time

i'll try 30 at 6 churn

ok

3 is just starting to scrape exponentials

6 it should really kick in

8 is prolly overkill tbh

30 is a huge number of poisoned outputs

Yes, but my mental model is telling me that scaling it up that far wont be too bad here

are these 6 churns of the poisoned outputs independently?

idk

30 is a lot

maybe 20?

still a lot, but heh

and then after the 6 churns is there a merge?

right

idk why the rec isnt just to merge them all, then churn

it's detecting false positives for merges after 6 churns

needmoney90: depends on the threat model

'ah, they merged their outs right here! Aha! And then got lost in the crowd...'\

so if you're really churning and merging, what is your anonymity set essentially

if the treat model assuming 30 payments to 1 address, then yes fine to churn right away

what does it look like is happening by chance

if 30 payments to an unassociated entity, then maybe churn separately if the address identities are supposed to stay separate

knaccc: what does it mean by merges detected then? how is this a static yes/no? does the model guess, and then if correct against ground truth, then say it's detected, no if not?

i might not be able to test anything approaching these numbers, actually. it's really slow

sgp_ we're essentially asking: if we pick 2 outputs on the blockchain, and then follow the forwards-in-time anonymity set N levels, does it look like there is ever a transaction afterwards that spends any two outputs together where each of those two outputs are from each of those forward-anonymity-sets

so it's asking what % of other random output pairs on the blockchain look like they might have been churned N times and then merged so that someone could cash out

don't you need to know what the user behavior will look like to test how many possible paths there are?

you don't know an arbitrary user churns x times specifically

i'm asking, at each level of churn, what will their cover be in terms of other outputs that could also look like they were churned and merged the same way

the answer after a direct merge is almost no anonymity

and the anonymity grows with churn distance from the original outputs

just to be extremely clear, can you show how the anonymity is near 0 for a direct merge? I want to follow your application to this design

so with the simple 2 outputs chosen at random then a direct merge, i've just rerun it with 1000 random pairs

and there are merges detected: 6 of 1000 for 2 poisoned outputs

so a 0.6% chance that a direct merge (like in the Ciphertrace example) could have been spent together by chance

so do you look at 1000 random output pairs and see if they appear in an immediate transaction with one of these outputs in each ring?

right, i look from the time of creation to present day

and all pairs were created Jun 2020 or after

okay, so given the shortened timeframe, the test may be slightly less reliable if we chose outputs including those 4 years ago? or at least that intuitively makes sense to me

well, assuming the ringsizes were always 11 I guess. maybe since that point for simplicity

in any case, that doesn't really matter, just trying to make sure I understand it

yeah you understand perfectly i think

so for 1 churn does that mean an immediate merge, or a merge within 2 transactions total?

0 churns means merge after outputs received

okay, so 1 churn = 2 transactions total

1 churn means both outputs churned independently after being received, then merged

sorry, your wording is clearer

going to 1 auto churn makes things much better:

merges detected: 31 of 100 for 2 poisoned outputs at churn level: 1

so we can massively improve monero's privacy with just one level of autochurn

and I assume you're using real Monero blockchain data for this then to test

correct

so to test arbitrary ringsizes it would take a lot of work to make a fake blockchain

when constructing the blockchain graph, extra outputs could be added as decoys to simulate it

hmm, that could be super useful actually. very clever too

and care would need to be taken to apply the correct selection distribution

of course

so now walking through the results you posted, for example this line:

merges detected: 1 of 10 for 2 poisoned outputs at churn level: 1

the problem though is still that the more iterations, the less churn helps you, unless you are churning many times more than once, in which case churn is a panacea

what does 1 of 10 mean?

that means of 10 random pairs chosen, 1 merge was detected at churn level=1

so 10% false positive rate

that you can hide in

the problem is that if you have 10 poisoned outputs instead of 2, then:

merges detected: 0 of 100 for 10 poisoned outputs at churn level: 1

can this be interpreted as 10% of the time, a "fake" merge of these 2 poisoned outputs occurs?

right

so essentially you need to look at how often you plan on transacting

and set churn level accordingly

and if you plan on transacting more than a few times, suddenly you need to go all the way up to churn level 6 or so

are these 10 random pairs selected from the 1000 earlier somehow?

or is this a completely independent test?

always independent

why only select 10 random pairs then?

because it takes a really long time to run. i'd select 1000 if i could

got it

Super interesting stuff knaccc just finished reading backscroll

Thanks for crunching the numbers :)

np, i kinda got addicted to it

I assume the time to run increases substantially with each churn more than it does each pair?

yeah, it's already super-optimized by not talking to the daemon. it loads everything into memory and then darts around

but still it takes time

how much memory does that take lol

only about 500mb, it only loads the essentials of the graph

my recent code is only really good for low churn levels. i have different code that looks at anonymity set sizes for transactions generally

=========================================================================================================================

Anonymity set sizes for txs in block 2177013 for observation window size: 7 days

=========================================================================================================================

txid | Level=1 | Level=2 | Level=3 | Level=4 | Level=5

------------------------------------------------------------------|----------|----------|----------|----------|----------

fe39a21b57814a980aea6d69fe8ab9cad609713b84d9c09f97e4b8cf74580e5b | 9 | 100 | 1,942 | 29,205 | 187,841

75cbf8e6805f0417c5f6160c47ca9db701e74f8583d33135f60dadf9ee1e3c6c | 6 | 66 | 1,119 | 17,488 | 146,782

ffa60ba1161b700efd8effe7a85fd3e93a7b08c2f9f0e3adb0ede229458b80b1 | 9 | 119 | 1,643 | 22,785 | 166,487

0b76935fa6b22da2e1baf41a8e9371dbf0ff727ebfe84928412179c8567e7774 | 11 | 147 | 2,180 | 31,761 | 191,051

d74e2ceb424abab0baaf9e3c6a9695cd08bff69c7ca8539a4bffe61c933e8a05 | 7 | 81 | 967 | 13,891 | 130,696

12b4af06464c29171f9ae857200ef343c7c3115ace8b2e78c528245330c86850 | 9 | 106 | 2,041 | 29,293 | 185,865

e9f0eab46edded095f9c5a2726b4e4610df3b98391730b2862c98058a362be2b | 11 | 200 | 3,353 | 46,762 | 210,115

1a223fd2c6ed9c64b1cd7e73370b93975edc89373f7ad8caab1cf601a9221948 | 8 | 97 | 1,401 | 18,670 | 139,589

ea012a8bf1898cd7f100257bb699696450dbfb8351599801689c8cba3e168e1d | 8 | 87 | 1,252 | 18,160 | 151,164

4a0b235f1e9f34d4a1adf185bdb0f4224c4925a2d3a4c5cfc736e46a3ff9cd44 | 7 | 416 | 7,149 | 86,880 | 235,023

c001acce972fb25d88b4b7ec524baf40c2512538137733fd69d661c72706577c | 7 | 96 | 1,471 | 21,017 | 163,831

824e016ab77108e808f706f2a3af95b949e23f5f7a6f8a182a893f2cf6cdd989 | 7 | 160 | 2,395 | 35,394 | 202,839

771d4db8b4f7eecf7e4914acb1264a34842a057480625498f270b2d1d2971053 | 9 | 167 | 2,863 | 40,307 | 208,096

207ca5090bb382e441820a21e807e22028d5f6970210c7df604d6b83236185db | 8 | 74 | 923 | 13,672 | 130,121

2398a80e742070504123dde6057b9711492d64c22928abd80079459837322c3b | 7 | 204 | 3,404 | 48,961 | 219,691

155e8c8c03e699c337e241232ec18bed9a155d923d33c6c19835a0ff3fdc3a82 | 9 | 196 | 2,927 | 39,841 | 208,513

46f1e03ed2c1ca6ea075956bf123a48f1ad8ea0b26ab6b8bc707076ab4dfc422 | 8 | 110 | 2,054 | 28,871 | 183,053

f164ca136b28611edef5c9939a882dd473b8d47772734d3cc2132beb720efab9 | 10 | 255 | 3,677 | 49,390 | 217,902

a667874ccf43f27fc4c56b5142d3b9137c450f1c86f27f1d63c695c943c09713 | 8 | 129 | 2,075 | 33,952 | 195,938

d2585dfc318f3bcb97f4d9ac1d11cfd120186383d7591d7f8611ef8ec011b749 | 5 | 68 | 912 | 13,995 | 130,375

e05287eea35d42cdf4adae65da54183f566b8d5d693c5772c6474ff7d90d8539 | 9 | 191 | 2,958 | 43,535 | 202,102

so you can see anonymity set sizes exploding

level 6 or 7 should be enough for anyone to get perfect anonymity

but of course, if we tell people to do that, it'll spam the blockchain, increase wallet scanning times to unacceptable levels, and people will get annoyed at how long they have to wait for the churns

hmmm actually that output looks a bit broken

i might have messed something up

paste as code snippet?

level 11 normally look like multiples of 11

level=1 i mean

anonymity set sizes, defined how?

defined as number of outputs that these txs could have sourced their inputs from

that paste is definitely wrong, level 1 should always be multiples of 11

i've messed something up in the last few hours i think

i pasted stuff earlier today that made more sense

some debian pastes

ohhhhhh

okay, is there better wording for that? easily confused with effective ringsizes

ok no my code isn't broken at all

it's because of the observation window

so it's clipped at 7 days

What does this mean exactly?

so the level 1 anonymity set size will only include any of the 11 outputs that existed in the 7 days prior to that tx

Hmm ok

That looks like one of the tools in src/blockchain_utilities.

Which I promptly forgot what they do.

c'est la vie

UkoeHB_ this is the entire listing for all txs in that block paste.debian.net/plain/1162186

btw the anonymity set sizes listed there are not approximations by multiplying ring counts together or something. it literally actually finds all distinct output ids in the anonymity sets, and so sees intersections and does not count duplicates

so this test takes these IDs and works backwards, not forwards?>

correct, this one is now backwards

in time

okay, so explain how for fe39a21b57814a980aea6d69fe8ab9cad609713b84d9c09f97e4b8cf74580e5b that is would be 9 possible source transactions when it has 11 inputs/ring

*it? idk lol

because an observation window is applied

so i could have said show me the anonymity set size going back forever

and then the level=1 col woudl all be multiples of 11

but i applied a 7 day observation window

btw if i take just that first tx in the list, i can then see the anonymity set size at different window sizes and at higher levels

so basically 9 of those outputs are within 7 days?

============================================================================================

Anonymity set sizes for txid: fe39a21b57814a980aea6d69fe8ab9cad609713b84d9c09f97e4b8cf74580e5b

============================================================================================

Window (days) | Level=1 | Level=2 | Level=3 | Level=4 | Level=5 | Level=6 | Level=7

---------------|----------|----------|----------|----------|----------|----------|----------

gah

1 | 6 | 43 | 700 | 5,439 | 18,833 | 25,354 | 27,873

3 | 8 | 76 | 1,340 | 15,676 | 74,092 | 91,192 | 93,762

pastebin, my friend

7 | 9 | 100 | 1,942 | 29,205 | 187,841 | 233,330 | 235,936

14 | 9 | 108 | 2,330 | 39,611 | 335,643 | 460,474 | 463,143

30 | 10 | 134 | 3,155 | 58,189 | 604,834 | 916,965 | 919,772

============================================================================================

stahp

correct

oh do you not have monospaced font in your irc?

Pastebin is just classier for many reasons :)

Not the point.

Fewer pings, easier to copy/paste/save

here is pastebin

:D

knaccc: interested in sharing a summary of this at tomorrow's meeting?

i'm not sure what time i'd be around tomorrow, i'll make the meeting if i can

I think at this point a write-up is warranted

yeah

i'll put something together

Great

the churns test is the most directly applicable but also only 10 samples is quite small sadly

You're welcome to post anything onto the agenda issue if this is handy

the bottom line is that if you have multiple poisioned outputs, you need e.g. 6-7 levels of churn, and that's not something we can really recommend without spamming the blockchain and making wallet scanning times too long

so all of this fancy schmancy analysis is kinda moot

There's an interesting social aspect to the "are my outputs flagged" question

would also be awesome to test arbitrary ringsizes :D

yeah

can someone point me to the current selection algo, preferably described in plain english?

zero to monero 2?

oh that's up-to-date is it?

I'm also most interested in 0-3 churns, anything more than that is hella niche (anything >1 is already super niche)

A version of arxiv.org/pdf/1704.04299, page 13

However, that paper does not account for block density

Here is a version of what we do: github.com/SarangNoether/skunkworks/blob/outputs/outputs/simulate.py

Namely, github.com/SarangNoether/skunkworks…ob/outputs/outputs/simulate.py#L127

(that script tested several methods)

IIRC the window we use for estimating "output time" is 6 months

selsta unless i've failed to locate it, i don't think z2m2 has the ring selection described

I recommend the python code

sarang so if i copy the python code, that's exactly what monero currently does?

gah numpy.random.geometric

With the exception of the overall block timing window, should be

it'll take quite a while to figure out how to get equivalent libraries for java and reimplement this

Very interesting anlysis

just catching up

"the bottom line is that if you have multiple poisoned outputs, you need e.g. 6-7 levels of churn, and that's not something we can really recommend without spamming the blockchain and making wallet scanning times too long"

knaccc: it is mentioned but then miller et al paper is linked for more details

why java

python iz easy

In this case, what should we recommend for people whose threat model includes multiple poisoned outputs? Just to not use Monero, because the churn necessary for anonymity is considered spam to others?

because you can't memory map a file in python to get ultra fast blockchain lookups

Small amounts of churn are fine

I believe he was meaning everyone churning all outputs 6-7x would be spam

yeah

Oh gotcha, yea

My idea was to allow "flagging" of subaddresses at creation time that enable auto-churning 1+ times of each received output

we won't want monero to be untraceability-theater for most users unless they do special churn techniques

^^

So, for instance, I have a subaddress per exchange used, I could flag those (manually or at creation of the subaddress) and the wallet would churn in the background.

That's a cool idea

It has to be something that can be brain-dead for everyone to benefit from it, if this heuristic is a threat to most users

Obviously power users can sweep_single easily in CLI already

I know I don't need to churn the lunch money my friend sends me, so why waste the TX fees and spam the blockchain with that

But I also don't want to manually sweep each "risky" output I receive

And obviously dusting of addresses only works for known addresses in Monero, so if I only share one subaddress with each exchange their dust will always be churned

i'm reminded of this imgur.com/gB65bZg "Deep Anonymity Accounts"

ah interesting!

Basically that, but has to be forced as a choice to the user, not manual/hidden

essentially in their wallet, where they already create multiple accounts, they can create a "Deep Anonymity Account" and a "Regular Privacy Account"

knaccc: is this basically a wallet feature with no extra crypto?

and use the DAA when they are worried

selsta correct

so my ideal flow is: Receive>Create new address>Prompt appears asking if I will be using this address for exchanges and untrusted third parties (wording needs to be clear here)>Yes flags it for autochurn, no treats it like normal.

knaccc: where did that come from?

midipoet i made it in 2017, when i first started talking about EABE issues :)

so basically it should also work with subaccounts?

knaccc: cool

yes could work with anything

It just changes wallet behavior

selsta yes it's just like normal accounts, except the wallet automatically churns when you transfer between accounts

instead of just letting you directly transfer funds

do you know if 7x churn is necessary with triptych?

or could that be reduced?

So: Send from DAA>Wallet "intercepts" and churns > Sends when done churning?

perhaps reduced

the key insight in that DAA thing is that if someone doesn't know your real-world identity, you don't have to churn at all

you can just receive from and spend with people that don't know your real-world identity

no blockchain spam required

true, thats a good differentiator

Well, some, but only when the threat is real/clear

unless you want to transfer to an account where you transact with an exchange or something

Its not spam, per se, but still bloat

at which point the wallet will do the churn

But for a good and needed reason

So wallet says "Will this address be linked in any way with your identity?" might be a better popup in my subaddress/subaccount idea

And if yes, autochurn 1+ times

Much better wording there, I like it knaccc

still though, all of this is going to confuse the hell out of people

Will need a clear doc to link to from the popup if we do something like that

we're gonna have to explain that if you churn, you can make monero more private, not that it wasn't already private, but now it's more private, not that if you don't do this you won't have privacy

But most will just answer yes or no and not care I think

it's too complicated to try and explain

that's why my preferred solution requires no churn

the tagging?

right.

Yeah, that requires a lot of changes though

So is likely a ways off

yeah, it's an almost impossible ask

Churning could be done today in theory, as the protocol obviously already supports it

I like the tagging long term, but churning is a good interim solution

but then we are going to hit immovable objects

in terms of wallet scanning time.

And we need to clearly explain that churning reduces a common attack vector against Monero, but isn't always needed

It's not a big deal if a couple of transactions per user get churned every once in a while

People aren't receiving from VASPs etc frequently

if we wanted to do a quick fix to partially address these recent tracing concerns, i'd recommend 1 churn automatically done on each incoming output prior

delete the word prior off the end

Yeah, but thats a lot of interim, unrecoverable blockchain bloat

For who knows how long

correct

2x the storage and compute for the foreseeable future is non-ideal, but if its that big of an issue it could be done I guess

it all depends on how seriously we take the threat

But I'd lean more towards selective churning if at all possible

<knaccc "it all depends on how seriously "> Absolutely

if we can kick the can down the road, and if this recent angst fades, we can go back to being content with untraceability-theater

The other alternative is re-sharing the Breaking Monero on EABE and recommending users with advanced threat models churn 1+ time when receiving funds from a "risky" source

<knaccc "if we can kick the can down the "> :P I don't think anyone is content with that

But rather the pros are not clearly outweighing the cons until this CT stuff

This could be a good fire under us to figure out a path forward for this specific heuristic

the fire will fade, we'll announce that we're aware of certain heuristics and that MRL is working on research to enhance untraceability

and then the pressure will be off

XMRUSD is up 2.62% today, why rock the boat

I don't want the pressure to be off :)

This was a good push, lets ride it if there is a good solution forward

knaccc: any good guides/docs on churning currently? I don't even see a way to do it in the GUI at all

And, tbh, I've never done it before

nvm, this is MRL channel, we can leave that topic for elsewhere/another day :)

maybe we should have churn capabilities built into the GUI per output.

Insight has some internal docs about churn: docs.google.com/document/d/1BZ3ptvi…FlUnCNisLeJ0LH_6js/edit?usp=sharing

sethsimmons since outputs need to be churned independently, it can be quite hard to do it yourself

We were thinking about adding churn functionality to the CLI / GUI

so really there needs to be auto-churn queuing on incoming outputs as a wallet feature

<Isthmus "Insight has some internal docs a"> Thanks!

<knaccc "so really there needs to be auto"> Yeah has to be automatic to work for the masses, and has to be clear why it should be on/off

i've long thought that tx queuing in general would be useful anyway, even if no churn

because then people don't have to wait for transactions to complete before making more transactions with the change

they just initiate the txs and the wallet queues them up and submits them when funds are unlocked

the idea that people need to set a timer to return to their wallet to do a further tx is crazy

Its true, I would love that, but that also requires leaving wallet unlocked in some way for long periods

Because you can't sign the TX until the parent is confirmed, correct?

Yea, since ring members are referenced by output index instead of something intrinsic like tx_hash

right, the wallet would need to keep your privspendkey around until the queued stuff is completed

and churn would not be fun with hardware wallets

<knaccc "and churn would not be fun with "> I don't think this is a problem, just recommend that people don't send straight from exchange to cold storage

but then their funds are exposed

negates the advantage of having your private key only on your hardware wallet

True, then HW wallets are gonna suck in a major way lol

Come back to your Lexger and sign every few hours

Isthmus: it's always amusing to see my comments from over a year ago on rando docs haha

knaccc: you still here? I have a question about the churn test. How are the other pairs selected? for example the 10 pairs