16:35:39 <sgp_> This might be interesting https://ama.researchhub.com/georgekappos
16:36:43 <sgp_> TIL Kappos is an analyst for Chainalysis
16:52:44 <sarang> Very interesting! The paper he and his team wrote is really good work
16:55:03 <sarang> ^ Isthmus might also find this useful, since IIRC he had expressed interest in the paper
18:49:24 <atoc> sarang ?
18:50:29 <sarang> Hi
18:50:35 <sarang> What's up atoc
18:50:50 <atoc> Good, how's it going?
18:51:07 <atoc> I wanted to ask you about Grin atomic swap
18:51:09 <sarang> Not bad; finishing up timelock-compatible CLSAG timing code
18:51:13 <atoc> Nice
18:51:40 <atoc> There is a good vid here: https://www.youtube.com/watch?v=sT3vNycMxw4
18:51:41 <monerobux> [ 06 @jaspervdm: Atomic Swaps - YouTube ] - www.youtube.com
18:52:03 <atoc> It seems that Grin ran into similar issues that we have with Monero atomic swap
18:52:28 <atoc> According to jasper, they have a working implementation
18:52:37 <atoc> using multisig wallets
18:52:53 <sarang> Is the method documented somewhere?
18:52:58 <atoc> I should look
18:53:19 <sarang> Unfortunately I can't watch the video now since I'm about to watch a presentation on empirical Zcash anonymity
18:53:20 <atoc> but I wanted check and see if you had looked into their atomic swaps at all?
18:53:25 <sarang> I have not
18:53:34 <sarang> But would be interested to see what techniques they're looking into
18:53:36 <atoc> alright, let me see if I can some more info on this
18:53:41 <sarang> Cool, that'd be great
18:53:56 <atoc> (y)
18:54:10 <atoc> I wanna see if I can crack this thing before I move on X-P
18:58:14 <sarang> Anyone else able to load the link for the presentation sgp_ mentioned earlier? https://www.crowdcast.io/e/george-kappos-Zcash
18:58:19 <sarang> I'm getting errors
18:59:40 <sgp_> I have an error too. Maybe it doesn't open until it actually starts which is dumb
19:00:10 * sarang will wait a few minutes
19:00:24 <atoc> still loading.. for me
19:00:47 <atoc> I got an error too
19:00:58 <sarang> boo
19:01:46 <selsta> > All Systems Operational
19:02:17 <sarang> Dang, the presentation sounded really interesting
19:02:42 <selsta> https://www.crowdcast.io/search?q=zcash
19:02:45 <selsta> it says going live in 3 minutes
19:04:03 <sgp_> Link works now
19:04:06 <atoc> https://www.crowdcast.io/e/george-kappos-Zcash?utm_campaign=discover&utm_source=crowdcast&utm_medium=discover_web
19:04:10 <atoc> yeah this is working for me
19:04:39 <sarang> "Your name and email will be shared with the host" <-- and presumably the company too :/
19:04:54 <sarang> no⊙ty
19:06:09 <atoc> :')
19:06:22 <selsta> https://temp-mail.org :)
19:13:27 <sarang> Seems like a pretty nice presentation interface
19:14:38 <atoc> he's talking about Monero rn :)
19:37:16 <Inge-> atoc: who is?
19:37:45 <Inge-> the zcash screencast?
19:38:41 <atoc> yes
19:38:47 <atoc> he stopped though
19:38:50 <atoc> was only brief mention
19:39:39 <atoc>  / description
19:44:18 <Inge-> kk
19:56:45 <sarang> That was a great presentation
19:57:22 <UkoeHB_> thinking a bit about graph matching (probably common knowledge).. the efficacy of heuristics vs ring size is also a function of tx volume. Current tx volume is around 10-15k per day, which is 70-105k per week. Imagine splitting your funds in a tx, and in the future they will get combined again to spend. If those outputs are directly combined, what is the likelihood of that happening randomly? Super low..
19:57:22 <UkoeHB_> choose 11 twice from the same huge set, and they will almost never crossover. But if that set is even way bigger, then the probability is even lower. This means how much you need to churn for plausible deniability increases with tx volume. And increasing ring size doesn't 'solve' it, just reduces the churn-volume scaling factor. Bitcoin is pumping out 2.1mill tx a week.. at that level even with 256 ring
19:57:22 <UkoeHB_> size you'd probably want all your outputs to be 2 churns away from each other before spending.
19:57:28 <sarang> The presenter says he will post updated data, since their dataset ended in 2018
19:57:32 <atoc> yeah it was good
19:58:22 <atoc> I guess this is the link: https://www.researchhub.com/paper/665375/summary
19:58:24 <atoc> for updated data
20:00:48 <sarang> UkoeHB_: also depends how you churn
20:01:18 <sarang> If you separately churn the outputs before using in a txn, or sweep and then churn the new merged output
20:03:02 <UkoeHB_> well maybe the best example is outputs you receive from random people who don't know you're the same person, so you can't directly sweep them without basically identifying yourself if those random people communicate
20:03:12 <dEBRUYNE> <sarang> That was a great presentation <= Can we get a TL;DW for those that haven't been able to watch it yet?
20:03:34 <sarang> It summarized a paper on heuristics that could link Zcash transactions in various ways
20:04:23 <sarang> In the data set of interest, it looks like ~70% of shielded interactions could be linked successfully using the heuristics
20:04:39 <sarang> (data ended in 2018)
20:05:53 <dEBRUYNE> Did that concern fully shielded transactions or z->t and vice versa?
20:07:45 <sarang> Mostly interpool operations, but they made some limited conclusions about the number of parties likely using intrapool operations
20:08:15 <dEBRUYNE> I see, thanks
20:08:40 <dEBRUYNE> I guess the low volume of fully shielded transactions is a significant contributor here
20:09:07 <sarang> Not necessarily volume, but usage characteristics
20:09:56 <sarang> Presumably broader service support for shielded operations could reduce the reliance on transparent operations, and thereby mitigate a lot of this analysis
20:10:19 <sarang> However, that seems like a tall order
20:10:37 <bluesunground> Does volume matter at all? As I understand it the anonimity set is cumulative anyway?
20:11:28 <sarang> If users are only using the shielded pool as an intermediate stop between transparent operations, then the volume might not necessarily play a significant role, depending on the heuristic that might apply
20:14:51 <sarang> At any rate, really interesting analysis
20:15:03 <sarang> Seeing updated data will be fascinating
21:25:54 <sarang> Hooray, new data on timelock-friendly CLSAG signatures is finished :)
21:26:05 <sarang> It's depressing data, but that was expected
21:26:16 <sarang> Tune in to tomorrow's meeting for plotz
22:15:16 <needbrrrrrrr90> if we want to use them we would have to accept the limitations for all txes, to promote tx uniformity, no?
22:15:30 <needbrrrrrrr90> or would timelock transactions be a second-class tx type
22:54:07 <derpy_bridge> <[keybase] unseddd>: congrats sarang! sad for CLSAG :(
23:38:32 <sarang> ping unseddd