Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Privacy implications of the interplay between shielded and non-shielded addresses #31

Open
hkalodner opened this issue Sep 15, 2017 · 9 comments

Comments

Projects
None yet
6 participants
@hkalodner
Copy link

commented Sep 15, 2017

Proposal

We propose to study the effects on privacy of the interoperation of shielded (z-addresses) and non-shielded (t-addresses) addresses used in Zcash (this addresses a open research question specified here). The strong privacy guarantees of z-addresses protect the anonymity of their users, but remain relatively underutilized due to high barriers to usage in the protocol today (although it appears that this will be largely resolved with the release of Sapling). Therefore most interactions in Zcash involve t-addresses to some degree and thus possess limited privacy.

First, we will extract empirical data on how t-addresses and z-addresses interact from the Zcash blockchain. In order to do this, we will extend BlockSci, a blockchain analysis tool that we recently released, with specialized support for Zcash.

We will then proceed to study the privacy implications of these interactions. In particular:

  • Specialize BlockSci’s existing address clustering capabilities to the unique usage patterns and protocol differences of Zcash to cluster all t-addresses to learn which user wallets are controlled by the same entity.
  • Looking for patterns in which money is sent from the cluster to a shielded address and subsequently returns to the same cluster.
  • We will pay particular attention to the timing and value of such transactions, attempting to deduce linkages from this data

Finally, BlockSci includes a mempool recorder for Bitcoin, and we will extend this network listener to support Zcash as well. The fine-grained timing data that this provides will allow for a much more detailed temporal analysis of transactions than block timestamps provide.

Our results will be released in an easily reproducible and updatable format which will allow to understand how shifts in usage of Zcash affect the privacy of its users over time. Additionally we will write up a working paper to disseminate our findings.

Team

Princeton University
PI: Arvind Narayanan
PhD Students: Harry Kalodner, Steven Goldfeder, Malte Möser

Budget

$12,000

@tromer

This comment has been minimized.

Copy link
Collaborator

commented Sep 15, 2017

While we ponder this, please see the related discussion and questions (some of which apply here too) in #24 .

@tromer tromer added the security label Sep 16, 2017

@zmanian

This comment has been minimized.

Copy link

commented Sep 17, 2017

One of the unresolved questions I've had for years is if there are simple heuristics that can be built into the wallet that guide users to avoid generating transactions from protected to t-addresses that can be trivially clustered.

@tromer

This comment has been minimized.

Copy link
Collaborator

commented Sep 17, 2017

@zmanian's idea is intriguing!
@hkalodner & co., do you think some of your techniques can indeed be encapsulated as an real-time in-wallet "privacy analyzer" module that would heuristically judge the linkability of imminent transactions (perhaps with server-side support, but ideally without leaking private information to the server)?

@tromer

This comment has been minimized.

Copy link
Collaborator

commented Sep 28, 2017

@hkalodner, can you comment on similarities, differences and potential collaborations between your team and that of #24? (Feel free to talk and coordinate together.)

@nathan-at-least

This comment has been minimized.

Copy link

commented Oct 2, 2017

I'd like to see analysis of both "coincident values" and "short timing" which are the two dangerous cases I describe here: https://twitter.com/least_nathan/status/914696179715268608

@nathan-at-least

This comment has been minimized.

Copy link

commented Oct 2, 2017

Riffing on that twitter thread (*):

Imagine if X ZEC exits a JoinSplit into a t-address in a single transaction. Now, if transparent graph analysis can conclude that entity A never shielded at least X ZEC, that entity could be exlcuded from the set of potential entities issuing the transaction in question. How many entities can be excluded for any given unshielding transaction? It would seem the larger X is here, the worse.

(*) This is inspired by this tweet from @fluffypony. Also props to twitter @lightcoin to starting the thread.

@acityinohio

This comment has been minimized.

Copy link
Member

commented Oct 4, 2017

Every informal proposal has multiple reviews by the review committee. The reviews are being collected and discussed in a private google doc (the 5 reviewers all have edit access to it, no one else can view it). By way of early, informal feedback, the reviewers have made a list of projects that they consider leading candidates for grant funding.

In that vein, your project was selected as one of the leading candidates, and the review committee encourages you to submit a full proposal by October 6th and looks forward to reviewing it.

@acityinohio

This comment has been minimized.

Copy link
Member

commented Oct 6, 2017

Also just a reminder @hkalodner that the submission deadline is October 6th! Please endeavor to have a final proposal submitted by then, as an attachment to this issue (and yes, it can be October 6th anywhere in the world).

@daira

This comment has been minimized.

Copy link

commented Oct 7, 2017

Reminder that there's still just under an hour to submit a final proposal. @hkalodner

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.