This might be interesting ama.researchhub.com/georgekappos

TIL Kappos is an analyst for Chainalysis

Very interesting! The paper he and his team wrote is really good work

^ Isthmus might also find this useful, since IIRC he had expressed interest in the paper

sarang ?

Hi

What's up atoc

Good, how's it going?

I wanted to ask you about Grin atomic swap

Not bad; finishing up timelock-compatible CLSAG timing code

Nice

There is a good vid here: youtube.com/watch?v=sT3vNycMxw4

It seems that Grin ran into similar issues that we have with Monero atomic swap

According to jasper, they have a working implementation

using multisig wallets

Is the method documented somewhere?

I should look

Unfortunately I can't watch the video now since I'm about to watch a presentation on empirical Zcash anonymity

but I wanted check and see if you had looked into their atomic swaps at all?

I have not

But would be interested to see what techniques they're looking into

alright, let me see if I can some more info on this

Cool, that'd be great

(y)

I wanna see if I can crack this thing before I move on X-P

Anyone else able to load the link for the presentation sgp_ mentioned earlier? crowdcast.io/e/george-kappos-Zcash

I'm getting errors

I have an error too. Maybe it doesn't open until it actually starts which is dumb

still loading.. for me

I got an error too

boo

> All Systems Operational

Dang, the presentation sounded really interesting

it says going live in 3 minutes

Link works now

yeah this is working for me

"Your name and email will be shared with the host" <-- and presumably the company too :/

no⊙ty

:')

temp-mail.org :)

Seems like a pretty nice presentation interface

he's talking about Monero rn :)

atoc: who is?

the zcash screencast?

yes

he stopped though

was only brief mention

/ description

kk

That was a great presentation

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..

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

size you'd probably want all your outputs to be 2 churns away from each other before spending.

The presenter says he will post updated data, since their dataset ended in 2018

yeah it was good

I guess this is the link: researchhub.com/paper/665375/summary

for updated data

UkoeHB_: also depends how you churn

If you separately churn the outputs before using in a txn, or sweep and then churn the new merged output

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

<sarang> That was a great presentation <= Can we get a TL;DW for those that haven't been able to watch it yet?

It summarized a paper on heuristics that could link Zcash transactions in various ways

In the data set of interest, it looks like ~70% of shielded interactions could be linked successfully using the heuristics

(data ended in 2018)

Did that concern fully shielded transactions or z->t and vice versa?

Mostly interpool operations, but they made some limited conclusions about the number of parties likely using intrapool operations

I see, thanks

I guess the low volume of fully shielded transactions is a significant contributor here

Not necessarily volume, but usage characteristics

Presumably broader service support for shielded operations could reduce the reliance on transparent operations, and thereby mitigate a lot of this analysis

However, that seems like a tall order

Does volume matter at all? As I understand it the anonimity set is cumulative anyway?

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

At any rate, really interesting analysis

Seeing updated data will be fascinating

Hooray, new data on timelock-friendly CLSAG signatures is finished :)

It's depressing data, but that was expected

Tune in to tomorrow's meeting for plotz

if we want to use them we would have to accept the limitations for all txes, to promote tx uniformity, no?

or would timelock transactions be a second-class tx type

<[keybase] unseddd>: congrats sarang! sad for CLSAG :(

ping unseddd