05:57:27 Very nice work on the interview guys. My short list of interesting things that were mentioned: 05:57:29 1. "some exchanges share voluntarily, most do not, so there is an art to that" 05:57:31 2. "ip address information is used" -> perhaps they use isp monitoring to assist? 05:57:33 3. they are sending poisoned outputs to mount active attacks 05:57:35 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 05:58:33 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 06:10:30 might be time to consider some sort of automated background churn 06:11:53 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) 06:12:13 but maybe not selecting outs from the most recent few blocks isn't a bad thing 06:15:35 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 06:15:42 and the results are good over significant periods 06:15:57 but if churn is automated such that it happens quickly, it's not so good 06:16:08 here are the stats I just ran on 10 random outputs from July: 06:16:17 outputIds: [19584417, 19592166, 19583074, 19577487, 19588150, 19599373, 19578981, 19571263, 19594080, 19589986] 06:16:19 observ. period (hours): 1, fwd tx anon set: 1, 0, 2, 4, 1, 0, 1, 0, 4, 3 06:16:21 observ. period (hours): 2, fwd tx anon set: 3, 8, 8, 15, 12, 6, 6, 0, 60, 13 06:16:23 observ. period (hours): 3, fwd tx anon set: 13, 89, 46, 70, 99, 42, 20, 0, 309, 72 06:16:25 observ. period (hours): 4, fwd tx anon set: 94, 323, 260, 294, 378, 186, 100, 4, 729, 252 06:16:27 observ. period (hours): 5, fwd tx anon set: 386, 840, 555, 721, 815, 588, 386, 22, 1416, 841 06:16:29 observ. period (hours): 6, fwd tx anon set: 824, 1576, 959, 1168, 1281, 1044, 750, 115, 2048, 1402 06:16:31 observ. period (hours): 12, fwd tx anon set: 4317, 4855, 4357, 3914, 5189, 3937, 3563, 2531, 5250, 5179 06:16:33 observ. period (hours): 24, fwd tx anon set: 10765, 10546, 11150, 11097, 11174, 9735, 10700, 9536, 10886, 10935 06:16:35 observ. period (hours): 48, fwd tx anon set: 22221, 22521, 22480, 22745, 22839, 22670, 22345, 21656, 23312, 22676 06:16:37 observ. period (hours): 96, fwd tx anon set: 49754, 49763, 49942, 49717, 50276, 49118, 49446, 47691, 50150, 49792 06:17:12 ok so churn has to be automated, but the wallet has to be open so that it can do so intelligently? 06:17:30 s/has to/can be 06:17:30 fluffypony meant to say: ok so churn can be be automated, but the wallet has to be open so that it can do so intelligently? 06:17:37 good bot 06:17:43 yeah churn would need to happen automatically over longer periods than just "6 churns in 6 hours" 06:19:18 but if we recommend churns, this causes a blockchain bloat problem, and a wallet scanning time problem 06:20:09 See "The wallet scanning-time problem quantified" here: https://github.com/monero-project/research-lab/issues/75#issuecomment-663935804 06:20:17 If the transaction volume were to increase 30x from here, it would take 86 hours per year of transactions scanned"" 06:20:48 so churning would help accelerate the increase in tx volume times, and wallet scanning times would be a major problem 06:21:44 s/in tx volume times/in tx volume 06:21:44 knaccc meant to say: so churning would help accelerate the increase in tx volume, and wallet scanning times would be a major problem 06:24:53 sooner or later, we're going to need to take the wallet-scanning-time issue seriously 06:30:50 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. 06:31:22 Plus they do flag benign transactions if they happen to use wrong ring members, what a joke 06:32:40 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 06:33:30 so we can't just dismiss this by talking about how ring signatures are great. 06:34:47 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" 06:47:34 Not much we can do against guys who willingly want to paint benign transactions as tainted 06:48:00 but yes, people should be more aware of best usage practices 06:48:33 yeah i don't have much confidence in his claim of being able to mark txs as involving tainted funds 06:48:40 that seems a bit ridiculous 06:49:27 it is COMPLETELY arbitrary 06:52:54 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 06:53:38 and then share customer info only on those occasions 06:53:46 maybe just account ids at first 06:54:03 but if there is a pattern with certain account ids, they could easily be asked to then disclose more 06:54:58 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 06:56:00 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 07:34:49 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 07:34:59 so higher ring sizes could help with that perhaps 07:39:53 141 of 1000 not referenced within 2 hours 07:41:48 higher ring sizes or a larger amount weighted forwards 07:42:03 but higher ring sizes should be manageable atm 07:42:18 good point, yes i like the idea of a 'hot zone' where we try and make sure everything gets picked up multiple times 07:43:54 I suppose Triptych (or variant) will take care of that 09:14:18 Thanks sarang and sgp_ for the YT interview with Ciphertrace. 13:14:59 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 13:15:18 and then someone called us out, and the response was "well we knew about it" 13:21:04 so ringsize a bajillion? 13:25:34 ringsize 100k does solve the probem 13:26:01 ok, what're the numbers on that puppy. 13:26:35 processing times, sizes, etc. 13:47:28 too big 4 u 14:42:44 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: https://monero.sandcats.io/shared/QVo56B5-M76D88sArgVBbjnaJVltp7562CUuUsY3Nbc 14:44:06 Also please review the questions that are already there 14:44:34 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 14:44:43 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!) 14:45:20 I'd be glad to ask them on a call if they prefer, sure 14:47:37 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 14:48:48 On the other hand, Dave might not want his technical staff to answer directly without some kind of vetting of the responses and questions 14:49:32 true 14:50:22 Who knows; might as well provide written questions and offer to discuss however they wish (if they choose to discuss at all) 15:00:19 I have added/updated questions 15:35:23 questions sent, thanks 15:35:40 neat 15:43:30 well, even if too big, would be nice to know what the "cost of ideal", and see how we can make successive approximations 15:55:25 If what they are saying is true what should we do to protect our privacy? 15:56:22 TBH it's not entirely clear to me _what_ they're saying at this point, even after the interview 16:01:18 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 16:01:40 What do you mean by "snowball attack"? 16:03:42 The attack described on Breaking Monero 09 https://www.monerooutreach.org/breaking-monero/poisoned-outputs.html 16:04:17 Oh, examining transaction paths between known endpoints? 16:04:25 That becomes a graph matching and probability problem 16:04:38 If I were them, that's probably a technique that I would use where applicable 16:04:39 Maybe they got the majority of decoys tho 16:43:11 There's a new set of ECC releases about "Halo 2." New sample code 16:43:21 https://electriccoin.co/blog/ecc-releases-code-for-halo-2/ 16:44:14 Interesting; they switch from Sonic to PLONK 16:45:05 I would view the deployment timeline with raised eyebrows, but who knows 16:46:27 Now to see benchmarks! 17:04:56 That timeline seems a tad optimistic 17:05:47 Eh, it's a press release 17:05:53 Following the code will be far more interesting 17:06:16 It's neat research 17:07:08 Were you able to find some benchmarks? 17:08:05 I'm still perusing 17:08:14 The post is a little confusing 17:08:32 It seems to imply that PLONK support is not there yet, but there is PLONK-related code in the repo 17:09:25 Hmm, commit messages imply some stuff may still be broken, so I dunno 17:09:46 Doesn't appear to be any benchmarking just yet 17:09:53 Would depend on circuit structure, presumably 17:10:12 and if they intend to deploy, they'd need it to scale to something the size of the Sapling/Heartwood/etc. circuit 17:55:27 I'm told the questions have been forwarded 17:55:44 Hopeful for at least some basic responses, but the more the merrier 17:58:46 Forwarded to whom? The people on Dave's team who build the tools? 17:59:13 I have set my expectations low (they are a company, after all), but hope to be pleasantly surprised :D 18:44:49 I think it's pretty obvious what they do though isn't it? 18:44:54 It's known attack vectors 18:44:59 There isn't anything new 18:45:13 Is it just confirmation that we are wishing for 18:45:23 So we discredit the efficacy of it 18:45:27 And the accuracy 18:45:38 In the interview, it was implied that the technique involved many known methods, but also some kind of unknown sauce 18:45:51 Without justification or evidence or details, it's not possible to verify any of this 18:49:02 The unknown sauce is just spamming the network 18:49:13 That is not documented in any research, is it? 18:49:25 no, I think they mean sending users txes 18:49:25 No formal research anyways? 18:49:27 not network spam 18:49:36 for later recombination 18:49:55 known suspects? 18:50:12 There's no way to know what they do 18:50:12 What users? 18:50:22 They might have been telling the truth, stretching it, or being dishonest 18:50:35 Designing with any claims in mind that have no evidence is foolish anyway 18:50:51 The interview is all self-reported data 18:52:23 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 19:03:02 Hmm, what if we put together a CCS to become a CT customer, so that we can analyze its capabilities 19:03:11 I'm sure MRL could have a field day testing their abilities 19:03:48 And it'd be a good investment. We're currently fighting blind in an arms race 19:08:40 "Monero community funds chain analysis companies" 19:09:53 Well, not so much fighting, as having someone else write a letter saying they have powerful tools 19:10:20 they have the best tools 19:10:25 some very smart people told them 19:10:26 the smartest 19:10:53 I think it's important not to blindly discount the potential risks of the protocol, but also important is: https://en.wikipedia.org/wiki/Hitchens%27s_razor 19:10:54 [WIKIPEDIA] Hitchens's razor | "Hitchens's razor is an epistemological razor expressed by writer Christopher Hitchens. It says that the burden of proof regarding the truthfulness of a claim lies with the one who makes the claim; if this burden is not met, then the claim is unfounded, and its opponents need not argue further in order..." 19:11:01 good bot 19:13:47 Isthmus: that is a good idea I think. There is no reason the community couldn't buy the analysis tool 19:14:07 it makes perfect sense to 19:14:17 There would 100% be an NDA 19:14:23 Sure 19:14:28 and Big Fancy Legal Theats for violating it 19:14:38 sure 19:14:47 I am not interested in talking to lawyers about this 19:14:55 that sounds like months of your life you don't get back 19:15:14 Every month we don't get back 19:15:21 Might as well smile along the way 19:15:39 I'm saying "buying" the tools doesn't work 19:15:58 You'd probably send them some txns, and get some data back, but are under strict NDA about not sharing them anyway 19:16:11 So unless you want to tangle with expensive lawyers, you gain nothing 19:16:47 And if you do want to tangle with expensive lawyers, you have strange ideas of fun... 19:17:42 oh. I forgot the AaaS 19:17:50 ? 19:17:53 Analysis as a Service 19:17:55 aye 19:18:07 I don't know this is how it works, but it is my assumption 19:18:24 I would be super surprised if they just shipped you the whole damn tool 19:18:45 That seems terrible for business 19:19:02 Maybe you get some kind of viewing interface for your particular case 19:19:07 But still can't share anything under NDA 19:19:40 Oh no. I wouldn't share my transaction information. That would be silly 19:22:06 And another brief reminder that sgp_ and I did write specific technical questions that were sent to Dave Jevans earlier today 19:22:12 They may respond with details, and they might not 19:22:41 But I am certainly willing to give them the professional courtesy of a few days to respond, should they choose to 19:54:26 i have some interesting stats 19:54:45 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 19:54:59 and all pairs were created during or after Jun 2020 19:55:27 how many of those randomly picked pairs will be spent together, by chance, at some point in the future? 19:55:34 the answer: merges detected: 0 of 100 for 2 poisoned outputs 19:56:06 i'm running it again now to do the analysis again for 1000 random pairs, but it takes quite a while 19:56:10 next question: 19:56:33 what if users churned each output in each random pair, prior to merging? 19:56:33 wait, 0 of 100 means it would be very detectable? 19:56:48 so 'this would not happen by random chance'? 19:56:55 exactly, the false positive rate is near 0%, so the spend is ultra-high probability 19:57:26 So this is effectively iterated EAE, right? 19:57:36 to clarify. 19:57:37 yes. so now we look at merges detected for each random pair, during different levels of churn 19:57:43 churn window (hours): 24 19:57:45 merges detected: 1 of 10 for 2 poisoned outputs at churn level: 1 19:57:47 merges detected: 0 of 10 for 3 poisoned outputs at churn level: 1 19:57:49 merges detected: 0 of 10 for 4 poisoned outputs at churn level: 1 19:57:51 merges detected: 0 of 10 for 5 poisoned outputs at churn level: 1 19:57:53 merges detected: 0 of 10 for 6 poisoned outputs at churn level: 1 19:57:55 merges detected: 10 of 10 for 2 poisoned outputs at churn level: 2 19:57:57 merges detected: 8 of 10 for 3 poisoned outputs at churn level: 2 19:57:59 merges detected: 1 of 10 for 4 poisoned outputs at churn level: 2 19:58:01 merges detected: 1 of 10 for 5 poisoned outputs at churn level: 2 19:58:03 merges detected: 0 of 10 for 6 poisoned outputs at churn level: 2 19:58:05 merges detected: 9 of 10 for 2 poisoned outputs at churn level: 3 19:58:07 merges detected: 10 of 10 for 3 poisoned outputs at churn level: 3 19:58:09 merges detected: 10 of 10 for 4 poisoned outputs at churn level: 3 19:58:11 merges detected: 10 of 10 for 5 poisoned outputs at churn level: 3 19:58:13 merges detected: 3 of 10 for 6 poisoned outputs at churn level: 3 19:58:15 ok so i'll explain this: 19:58:20 it explains itself 19:58:32 :D 19:58:44 so what happens if someone churns n outputs independently inside a 24hr window 19:58:49 If you want to get effective privacy off of up to 5 outputs, churn 3 times and you're good 19:58:57 within the same window 19:58:59 how many random sets taken from the blockchain show false positives 19:59:11 and yes the false positive rate can get really good 19:59:30 but the problem is you get no false positives if you simply increase the poisoned output count 19:59:56 nah 19:59:58 but you also get higher false positives if you simply increase the number of churns 20:00:04 you havent run the numbers far enough 20:00:11 what should i run 20:00:17 Its a growth rate thing 20:00:29 well the thing is, you can get complete anonymity if you churn enough 20:00:32 poisoned outputs are linear 20:00:38 churns are exponential 20:00:57 right, so you can always beat any number of poisoned outputs if outputs are churned enough, i think 20:00:58 I suspect if you push churns to like, 8, and poisoned outputs to 30, you'll be surprised at the result 20:01:11 'enough' is something like a log on the number of outputs 20:01:15 its not a linear growth thing 20:01:28 there is a churn level where the anonymity set size starts to become "everything" 20:01:29 at least, I suspect. 20:01:39 Try 30 poisoned, 8 churn. 20:02:10 8 churn probably way too high to do in reasonable time 20:02:21 i'll try 30 at 6 churn 20:02:27 ok 20:02:51 3 is just starting to scrape exponentials 20:03:04 6 it should really kick in 20:03:10 8 is prolly overkill tbh 20:03:25 30 is a huge number of poisoned outputs 20:03:41 Yes, but my mental model is telling me that scaling it up that far wont be too bad here 20:03:46 are these 6 churns of the poisoned outputs independently? 20:03:48 idk 20:03:59 30 is a lot 20:04:01 maybe 20? 20:04:06 still a lot, but heh 20:04:06 and then after the 6 churns is there a merge? 20:04:11 right 20:04:21 idk why the rec isnt just to merge them all, then churn 20:04:30 it's detecting false positives for merges after 6 churns 20:04:37 needmoney90: depends on the threat model 20:04:39 'ah, they merged their outs right here! Aha! And then got lost in the crowd...'\ 20:04:47 so if you're really churning and merging, what is your anonymity set essentially 20:04:51 if the treat model assuming 30 payments to 1 address, then yes fine to churn right away 20:04:56 what does it look like is happening by chance 20:05:37 if 30 payments to an unassociated entity, then maybe churn separately if the address identities are supposed to stay separate 20:06:26 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? 20:06:40 i might not be able to test anything approaching these numbers, actually. it's really slow 20:08:19 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 20:09:21 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 20:09:51 don't you need to know what the user behavior will look like to test how many possible paths there are? 20:10:05 you don't know an arbitrary user churns x times specifically 20:10:46 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 20:11:04 the answer after a direct merge is almost no anonymity 20:11:21 and the anonymity grows with churn distance from the original outputs 20:11:48 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 20:12:07 so with the simple 2 outputs chosen at random then a direct merge, i've just rerun it with 1000 random pairs 20:12:11 and there are merges detected: 6 of 1000 for 2 poisoned outputs 20:12:48 so a 0.6% chance that a direct merge (like in the Ciphertrace example) could have been spent together by chance 20:14:53 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? 20:15:36 right, i look from the time of creation to present day 20:15:48 and all pairs were created Jun 2020 or after 20:16:37 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 20:17:21 well, assuming the ringsizes were always 11 I guess. maybe since that point for simplicity 20:17:38 in any case, that doesn't really matter, just trying to make sure I understand it 20:17:46 yeah you understand perfectly i think 20:18:24 so for 1 churn does that mean an immediate merge, or a merge within 2 transactions total? 20:18:51 0 churns means merge after outputs received 20:19:08 okay, so 1 churn = 2 transactions total 20:19:11 1 churn means both outputs churned independently after being received, then merged 20:19:24 sorry, your wording is clearer 20:19:32 going to 1 auto churn makes things much better: 20:19:34 merges detected: 31 of 100 for 2 poisoned outputs at churn level: 1 20:19:56 so we can massively improve monero's privacy with just one level of autochurn 20:19:57 and I assume you're using real Monero blockchain data for this then to test 20:20:00 correct 20:20:28 so to test arbitrary ringsizes it would take a lot of work to make a fake blockchain 20:21:26 when constructing the blockchain graph, extra outputs could be added as decoys to simulate it 20:21:44 hmm, that could be super useful actually. very clever too 20:21:46 and care would need to be taken to apply the correct selection distribution 20:22:03 of course 20:22:41 so now walking through the results you posted, for example this line: 20:22:42 merges detected: 1 of 10 for 2 poisoned outputs at churn level: 1 20:22:48 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 20:22:51 what does 1 of 10 mean? 20:23:23 that means of 10 random pairs chosen, 1 merge was detected at churn level=1 20:23:34 so 10% false positive rate 20:23:46 that you can hide in 20:24:45 the problem is that if you have 10 poisoned outputs instead of 2, then: 20:24:47 merges detected: 0 of 100 for 10 poisoned outputs at churn level: 1 20:25:04 can this be interpreted as 10% of the time, a "fake" merge of these 2 poisoned outputs occurs? 20:25:14 right 20:26:29 so essentially you need to look at how often you plan on transacting 20:26:44 and set churn level accordingly 20:27:05 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 20:27:14 are these 10 random pairs selected from the 1000 earlier somehow? 20:27:25 or is this a completely independent test? 20:27:57 always independent 20:28:27 why only select 10 random pairs then? 20:30:09 because it takes a really long time to run. i'd select 1000 if i could 20:30:26 got it 20:30:49 Super interesting stuff knaccc just finished reading backscroll 20:30:54 Thanks for crunching the numbers :) 20:31:05 np, i kinda got addicted to it 20:31:13 I assume the time to run increases substantially with each churn more than it does each pair? 20:31:39 yeah, it's already super-optimized by not talking to the daemon. it loads everything into memory and then darts around 20:31:48 but still it takes time 20:31:57 how much memory does that take lol 20:32:15 only about 500mb, it only loads the essentials of the graph 20:32:51 my recent code is only really good for low churn levels. i have different code that looks at anonymity set sizes for transactions generally 20:33:09 ========================================================================================================================= 20:33:11 Anonymity set sizes for txs in block 2177013 for observation window size: 7 days 20:33:13 ========================================================================================================================= 20:33:15 txid | Level=1 | Level=2 | Level=3 | Level=4 | Level=5 20:33:17 ------------------------------------------------------------------|----------|----------|----------|----------|---------- 20:33:19 fe39a21b57814a980aea6d69fe8ab9cad609713b84d9c09f97e4b8cf74580e5b | 9 | 100 | 1,942 | 29,205 | 187,841 20:33:21 75cbf8e6805f0417c5f6160c47ca9db701e74f8583d33135f60dadf9ee1e3c6c | 6 | 66 | 1,119 | 17,488 | 146,782 20:33:23 ffa60ba1161b700efd8effe7a85fd3e93a7b08c2f9f0e3adb0ede229458b80b1 | 9 | 119 | 1,643 | 22,785 | 166,487 20:33:25 0b76935fa6b22da2e1baf41a8e9371dbf0ff727ebfe84928412179c8567e7774 | 11 | 147 | 2,180 | 31,761 | 191,051 20:33:27 d74e2ceb424abab0baaf9e3c6a9695cd08bff69c7ca8539a4bffe61c933e8a05 | 7 | 81 | 967 | 13,891 | 130,696 20:33:29 12b4af06464c29171f9ae857200ef343c7c3115ace8b2e78c528245330c86850 | 9 | 106 | 2,041 | 29,293 | 185,865 20:33:31 e9f0eab46edded095f9c5a2726b4e4610df3b98391730b2862c98058a362be2b | 11 | 200 | 3,353 | 46,762 | 210,115 20:33:33 1a223fd2c6ed9c64b1cd7e73370b93975edc89373f7ad8caab1cf601a9221948 | 8 | 97 | 1,401 | 18,670 | 139,589 20:33:35 ea012a8bf1898cd7f100257bb699696450dbfb8351599801689c8cba3e168e1d | 8 | 87 | 1,252 | 18,160 | 151,164 20:33:37 4a0b235f1e9f34d4a1adf185bdb0f4224c4925a2d3a4c5cfc736e46a3ff9cd44 | 7 | 416 | 7,149 | 86,880 | 235,023 20:33:39 c001acce972fb25d88b4b7ec524baf40c2512538137733fd69d661c72706577c | 7 | 96 | 1,471 | 21,017 | 163,831 20:33:41 824e016ab77108e808f706f2a3af95b949e23f5f7a6f8a182a893f2cf6cdd989 | 7 | 160 | 2,395 | 35,394 | 202,839 20:33:43 771d4db8b4f7eecf7e4914acb1264a34842a057480625498f270b2d1d2971053 | 9 | 167 | 2,863 | 40,307 | 208,096 20:33:45 207ca5090bb382e441820a21e807e22028d5f6970210c7df604d6b83236185db | 8 | 74 | 923 | 13,672 | 130,121 20:33:47 2398a80e742070504123dde6057b9711492d64c22928abd80079459837322c3b | 7 | 204 | 3,404 | 48,961 | 219,691 20:33:49 155e8c8c03e699c337e241232ec18bed9a155d923d33c6c19835a0ff3fdc3a82 | 9 | 196 | 2,927 | 39,841 | 208,513 20:33:51 46f1e03ed2c1ca6ea075956bf123a48f1ad8ea0b26ab6b8bc707076ab4dfc422 | 8 | 110 | 2,054 | 28,871 | 183,053 20:33:53 f164ca136b28611edef5c9939a882dd473b8d47772734d3cc2132beb720efab9 | 10 | 255 | 3,677 | 49,390 | 217,902 20:33:55 a667874ccf43f27fc4c56b5142d3b9137c450f1c86f27f1d63c695c943c09713 | 8 | 129 | 2,075 | 33,952 | 195,938 20:33:57 d2585dfc318f3bcb97f4d9ac1d11cfd120186383d7591d7f8611ef8ec011b749 | 5 | 68 | 912 | 13,995 | 130,375 20:33:59 e05287eea35d42cdf4adae65da54183f566b8d5d693c5772c6474ff7d90d8539 | 9 | 191 | 2,958 | 43,535 | 202,102 20:34:01 so you can see anonymity set sizes exploding 20:34:03 level 6 or 7 should be enough for anyone to get perfect anonymity 20:34:21 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 20:35:14 hmmm actually that output looks a bit broken 20:35:18 i might have messed something up 20:35:23 paste as code snippet? 20:35:27 level 11 normally look like multiples of 11 20:35:32 level=1 i mean 20:35:46 anonymity set sizes, defined how? 20:36:51 defined as number of outputs that these txs could have sourced their inputs from 20:37:03 that paste is definitely wrong, level 1 should always be multiples of 11 20:37:10 i've messed something up in the last few hours i think 20:37:32 i pasted stuff earlier today that made more sense 20:37:59 some debian pastes 20:38:54 ohhhhhh 20:38:55 okay, is there better wording for that? easily confused with effective ringsizes 20:39:05 ok no my code isn't broken at all 20:39:10 it's because of the observation window 20:39:15 so it's clipped at 7 days 20:39:35 What does this mean exactly? 20:39:44 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 20:39:55 Hmm ok 20:39:56 That looks like one of the tools in src/blockchain_utilities. 20:40:06 Which I promptly forgot what they do. 20:40:57 c'est la vie 20:41:32 UkoeHB_ this is the entire listing for all txs in that block https://paste.debian.net/plain/1162186 20:43:23 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 20:44:08 so this test takes these IDs and works backwards, not forwards?> 20:44:16 correct, this one is now backwards 20:44:20 in time 20:44:51 okay, so explain how for fe39a21b57814a980aea6d69fe8ab9cad609713b84d9c09f97e4b8cf74580e5b that is would be 9 possible source transactions when it has 11 inputs/ring 20:45:55 *it? idk lol 20:46:08 because an observation window is applied 20:46:20 so i could have said show me the anonymity set size going back forever 20:46:35 and then the level=1 col woudl all be multiples of 11 20:46:44 but i applied a 7 day observation window 20:47:21 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 20:47:26 so basically 9 of those outputs are within 7 days? 20:47:29 ============================================================================================ 20:47:31 Anonymity set sizes for txid: fe39a21b57814a980aea6d69fe8ab9cad609713b84d9c09f97e4b8cf74580e5b 20:47:33 ============================================================================================ 20:47:35 Window (days) | Level=1 | Level=2 | Level=3 | Level=4 | Level=5 | Level=6 | Level=7 20:47:37 ---------------|----------|----------|----------|----------|----------|----------|---------- 20:47:39 gah 20:47:39 1 | 6 | 43 | 700 | 5,439 | 18,833 | 25,354 | 27,873 20:47:41 3 | 8 | 76 | 1,340 | 15,676 | 74,092 | 91,192 | 93,762 20:47:42 pastebin, my friend 20:47:43 7 | 9 | 100 | 1,942 | 29,205 | 187,841 | 233,330 | 235,936 20:47:45 14 | 9 | 108 | 2,330 | 39,611 | 335,643 | 460,474 | 463,143 20:47:47 30 | 10 | 134 | 3,155 | 58,189 | 604,834 | 916,965 | 919,772 20:47:49 ============================================================================================ 20:47:51 stahp 20:47:51 correct 20:48:03 oh do you not have monospaced font in your irc? 20:48:28 Pastebin is just classier for many reasons :) 20:48:31 Not the point. 20:48:38 Fewer pings, easier to copy/paste/save 20:48:42 here is pastebin 20:48:44 https://paste.debian.net/plain/1162187 20:48:47 :D 20:49:47 knaccc: interested in sharing a summary of this at tomorrow's meeting? 20:50:01 https://github.com/monero-project/meta/issues/502 20:50:08 i'm not sure what time i'd be around tomorrow, i'll make the meeting if i can 20:50:21