14:31:19 <sarang> Hello all
14:31:32 <sarang> Finishing up some effective anonymity set data today, woo
14:31:47 <sarang> Also UkoeHB_ I have a finalized data set for transaction-output relationships
14:32:00 <sarang> That can be run against any analysis we wish
14:32:18 <sarang> It's a pretty huge file, but I can provide format details should you have particular code you wish to run against it
14:40:33 <Inge->  < 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 ?
14:47:39 <Inge-> (speaking of old outputs here
14:50:24 <sarang> Churning individual old outputs before merging them would leave a likely fingerprint in the transaction graph
14:50:53 <sarang> Merging into a new output would be likely used in many other rings, and therefore introduce some nice ambiguity in the graph
14:51:00 <Inge-> so 1) how old should an output be to qualify as an "old" output?
14:51:12 <Inge-> 2) What IS the recommended approach for preparing to spend old outputs?
14:55:48 <sarang> 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
14:55:54 <sarang> that is not quite so cut-and-dry
14:56:52 <sarang> 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
14:57:19 <Inge-> My question is solidly planted in the post-CT era
14:57:23 <sarang> post-CT funds are not at risk of deducibility using the same method (i.e. chain reaction no longer applies)
14:57:24 <sarang> ok
14:57:32 <moneromooo> 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.
14:58:29 <Inge-> Ideally it should be fairly trivial for users to hold for a long time and then spend safely
14:59:14 <sarang> True, but the entire point of the spend-age distribution is to match actual known spend patterns as close as possible
16:04:12 <gingeropolous> ugh. just bump the ringsize to a bajillion and be done with it
16:04:38 <sarang> s/11/1 bajillion/
16:04:39 <sarang> done
16:04:54 <sarang> someone please review that change for me
16:05:00 <gingeropolous> lol
16:05:25 <moneromooo> That will change a lot more than just ring size.
16:05:40 <gingeropolous> i mean, cereal though, how much of this heuristic nonsense would be abrogated with massive ringsizes
16:08:03 <kinghat[m]> how big of a ringsize is enough?
16:09:00 <sarang> IMO being able to use ring epochs can mitigate a lot of this
16:09:27 <sarang> Even in the event of a breakdown of the age distribution, an adversary still has to work within an entire epoch
16:09:45 <kinghat[m]> sorry for being ignorant but its more than just plausible deniability, correct?
16:09:47 <sarang> and if epochs contain many outputs from the same transactions, output merging is less useful
16:09:47 <gingeropolous> the buckets or batching or bins or whatever its called?
16:09:51 <sarang> aye
16:11:06 <gingeropolous> 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
16:11:43 <kinghat[m]> is there a ballpark size or a size of diminishing returns? or is it more is always better?
16:12:18 <sarang> kinghat[m]: that answer would depend highly on the particular risk model a user is considering,
16:12:35 <sarang> (which is very much a non-answer...)
16:13:06 <sarang> AFAIK it hasn't really been tested in the real world what "plausible deniability" looks like in the context of ambiguous signatures
16:14:16 <kinghat[m]> 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?
16:14:29 <sarang> Depends entirely on your threat model
16:15:38 <kinghat[m]> ya i guess im not educated enough on the different threat models to be able to make a distinction.
16:15:47 <sarang> 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
16:16:41 <sarang> and if the adversary also colludes with the user's ISP, it could have more information still
16:17:32 <kinghat[m]> damn, i always forget about the exchanges.
16:18:13 <sarang> "Who is colluding with whom" is a tricky question
16:18:19 <kinghat[m]> the ring size plays a role if there was collusion with an isp?
16:18:50 <sarang> Depending on how the user interacts with the network, the ISP could know which transactions belong to the user
16:19:01 <sarang> or at least provide an indication of when the user was online to potentially make a transaction
16:19:13 <sarang> and that's useful information
16:20:29 <kinghat[m]> got ya.
18:03:06 <UkoeHB_> re: finalized data set for transaction-output relationships; sounds good sarang
18:03:39 <sarang> The data is up to block 2.1 M, which extends to May 2020
18:06:26 <niocbrrrrrr> https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/149
18:44:00 <niocbrrrrrr> updated https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/150
19:20:06 <gingeropolous> i don't think variables outside the scope of the blockchain should function as inhibitors of the security design of the blockchain
19:20:37 <gingeropolous> 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
19:20:44 <gingeropolous> *transaction hash
19:21:25 <gingeropolous> i mean hell, if you take that philosophy to its maximum (and always crank to 11), then bitcoin's psuedonynmeueoiltuio is fine
19:41:11 <sarang> I'm not sure I follow what view you're taking here gingeropolous...
19:45:53 <gingeropolous> the threat models
19:46:45 <sarang> Are you saying that the security design should take into account common likely user behaviors (e.g. interacting with exchanges)?
19:46:50 <sarang> If so, I agree
19:46:52 <sarang> Absolutely
19:47:27 <sarang> Unfortunately, there's no clear line for where your assumption of entities colluding should be
19:47:49 <sarang> "Everyone is colluding" seems to ruin most designs
20:16:21 <gingeropolous> im saying the security design shouldn't be hindered by likely user behaviors
20:17:34 <gingeropolous> ah, missed a negative in my original statement. my bad "doesn't mean the chain shouldn't be super awesome"
20:17:57 <gingeropolous> well, a double negative was attempted, and missed. I'll work on my doublespeek. That was doubleplus ungood.
20:19:00 <gingeropolous> not even these keys can keep up with these caffeinated manic comments!