Hello all

Finishing up some effective anonymity set data today, woo

Also UkoeHB_ I have a finalized data set for transaction-output relationships

That can be run against any analysis we wish

It's a pretty huge file, but I can provide format details should you have particular code you wish to run against it

< binaryFate> The wallet warns you when you spend old outputs that privacy is lessen and it's known you should churn in that case <-- is churning much different from a sweep_single of that output? is it best practice to sweep_single to yourself in order to churn, before spending ?

(speaking of old outputs here

Churning individual old outputs before merging them would leave a likely fingerprint in the transaction graph

Merging into a new output would be likely used in many other rings, and therefore introduce some nice ambiguity in the graph

so 1) how old should an output be to qualify as an "old" output?

2) What IS the recommended approach for preparing to spend old outputs?

Well, a transaction spending pre-CT funds runs the risk of being deducible (due to old chain-reaction effects) and/or being susceptible to guess-newest (just a heuristic, not inherently testable)... but otherwise, the older a spent post-CT output is, the less likely it is to be a decoy according to the modern selection algorithm

that is not quite so cut-and-dry

I have data on the deducibility of pre-CT funds being spent in the post-CT world, and can put together a little plot on that

My question is solidly planted in the post-CT era

post-CT funds are not at risk of deducibility using the same method (i.e. chain reaction no longer applies)

ok

maybe the wallet should try to select true spends with one ring spending an old out if there's one, and the rest spending recent ones.

Ideally it should be fairly trivial for users to hold for a long time and then spend safely

True, but the entire point of the spend-age distribution is to match actual known spend patterns as close as possible

ugh. just bump the ringsize to a bajillion and be done with it

s/11/1 bajillion/

done

someone please review that change for me

lol

That will change a lot more than just ring size.

i mean, cereal though, how much of this heuristic nonsense would be abrogated with massive ringsizes

how big of a ringsize is enough?

IMO being able to use ring epochs can mitigate a lot of this

Even in the event of a breakdown of the age distribution, an adversary still has to work within an entire epoch

sorry for being ignorant but its more than just plausible deniability, correct?

and if epochs contain many outputs from the same transactions, output merging is less useful

the buckets or batching or bins or whatever its called?

aye

i mean, a 1k ringsize does far less damage than when we moved to original ringct. Yes yes, i know, we're such a mature network now, but c'mon

is there a ballpark size or a size of diminishing returns? or is it more is always better?

kinghat[m]: that answer would depend highly on the particular risk model a user is considering,

(which is very much a non-answer...)

AFAIK it hasn't really been tested in the real world what "plausible deniability" looks like in the context of ambiguous signatures

ya we cant know that, but we probably can know that 1k is basically the same as 1.2k but is it the same as 2k?

Depends entirely on your threat model

ya i guess im not educated enough on the different threat models to be able to make a distinction.

If an adversary is spending funds repeatedly to a user and is colluding with their exchange to see how often those funds appear in the transaction graph when deposited, then that's probably a different metric for deniability than simply looking at patterns in the graph without such information

and if the adversary also colludes with the user's ISP, it could have more information still

damn, i always forget about the exchanges.

"Who is colluding with whom" is a tricky question

the ring size plays a role if there was collusion with an isp?

Depending on how the user interacts with the network, the ISP could know which transactions belong to the user

or at least provide an indication of when the user was online to potentially make a transaction

and that's useful information

got ya.

re: finalized data set for transaction-output relationships; sounds good sarang

The data is up to block 2.1 M, which extends to May 2020

updated repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/150

i don't think variables outside the scope of the blockchain should function as inhibitors of the security design of the blockchain

just because Jimbo sends from the same IP to the exchange and the publishes his transaction has on twitter doesn't mean the chain should be super awesome

*transaction hash

i mean hell, if you take that philosophy to its maximum (and always crank to 11), then bitcoin's psuedonynmeueoiltuio is fine

I'm not sure I follow what view you're taking here gingeropolous...

the threat models

Are you saying that the security design should take into account common likely user behaviors (e.g. interacting with exchanges)?

If so, I agree

Absolutely

Unfortunately, there's no clear line for where your assumption of entities colluding should be

"Everyone is colluding" seems to ruin most designs