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

[hkalodner]

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]

While we ponder this, please see the related discussion and questions (some of which apply here too) in https://github.com/ZcashFoundation/GrantProposals-2017Q4/issues/24 .

[zmanian]

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]

@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]

@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]

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]

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]

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]

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]

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