Factual inaccuracies of “Breaking Mimblewimble’s Privacy Model”

Daniel Lehnberg
Grin & Mimblewimble
6 min readNov 18, 2019

TL;DR: Mimblewimble privacy is not “fundamentally flawed”. The described “attack” on Mimblewimble/Grin is a misunderstanding of a known limitation. While the article provides some interesting numbers on network analysis, the results presented do not actually constitute an attack, nor do they back up the sensationalized claims made.

An article titled “Breaking Mimblewimble’s Privacy Model” has been making the rounds today, in which the author asserts that they have somehow ‘broken’ Mimblewimble and Grin’s privacy model.

The “attack” that the author claims to have made is the well-documented and discussed transaction graph input-output-linkability problem. This is not new to anyone on the Grin team or anyone who has studied the Mimblewimble protocol. Grin acknowledged the ability to link outputs on chain in a Privacy Primer published on its public wiki in November 2018, before mainnet was launched. This problem encompasses Ian Mier’s “Flashlight attack”, which we have listed as one of our Open Research Problems.

Numerous claims, including the title of the article itself, are factually inaccurate. On a high level, the article reads as a not-so-subtle take down piece that claims an attention-grabbing result. The conclusion of the article however, contains many logical leaps that are not substantiated via the network analysis exercise that is described.

The Grin team has consistently acknowledged that Grin’s privacy is far from perfect. While transaction linkability is a limitation that we’re looking to mitigate as part of our goal of ever-improving privacy, it does not ‘break’ Mimblewimble nor is it anywhere close to being so fundamental as to render it or Grin’s privacy features useless.

Rather than provide a point-by-point refutation of the article, we would like to point out the major issues we have with the research and its conclusions.

1) Mimblewimble does not have addresses

The most fundamental privacy benefit of Mimblewimble is unfortunately the most fundamental issue with the research and related article: Mimblewimble doesn’t have addresses such as those that might be linked to a particular Bitcoin wallet. Value is exchanged by participants adding one-time outputs to a transaction, and at no point is anything resembling an identifying ‘address’ presented to the network or the chain data.

2) It’s not possible to link addresses that do not exist

The researcher appears to take an inconsistent approach to this point. The github repository accompanying the article states:

“There are no addresses, only UTXOs hidden as Pedersen commitments.”

Subsequently, the following scenarios are painted:

“Say I’m law enforcement, and I know that an address belongs to a vendor on a darknet market. When you send your Grin coins to Coinbase, Coinbase links your address with your name.”

The medium article continues:

“Or say an authoritarian government knows that a certain address belongs to a political dissident. You send that dissident a small donation.”

It’s unclear how law enforcement would know anything about a non-existent address, or how Coinbase could link an address that does not exist to a name. Or for that matter how an authoritarian government would be able to link a non-address to a political dissident.

We have to assume that the author conveniently confused transaction outputs (TXOs) with addresses, but these are not the same. And, as we’ve already detailed, the fact that TXOs can be linked is hardly news.

3) The number 95.5% is close to 100%. It also doesn’t mean much

The details about the actual exercise carried out is described as an “attack”. So called “sniffer nodes” collect transactions that are broadcast from nodes as part of the stem and fluff phase in Dandelion. The author is able to collect 95.5% of transactions on the network in a particular time period. Other than that “Output A spends to Output B”, it’s less clear what exactly is being identified here or what else the author is able to accomplish with this information.

4) The transaction graph alone does not reveal information about the transacting parties…

While it would be desirable to avoid leaking the transaction graph, the graph alone doesn’t necessarily reveal sender and receiver outputs. Without amounts, it’s difficult to distinguish between change outputs and recipient outputs. Even if the article doesn’t attempt to actually do this, it would be an interesting area for future research.

5) …and the author doesn’t seem to be aware of this

The Github repository reads:

“what we uncover is the transaction graph: the record of who paid whom”

But that’s not how this works.

Let’s take a concrete example. Alice builds a transaction with Bob, perhaps via TOR, via grinbox, or via direct file exchange. Then, she broadcasts this transaction to the network via a hosted node, for example using wallet713.

In this example, a “sniffer node” monitoring the network would not uncover any information about Alice, and certainly not a record of who paid whom. The “Flashlight attack” is an active attack where an adversary is participating in the transaction building process. The network analysis exercise in this article is passive, and would not be enough.

6. The headline is misleading, nothing is being broken here

The title of the article is “Breaking Mimblewimble’s Privacy Model”. Obscuring transaction outputs from being linked by monitoring nodes is not something that’s covered by Mimblewimble’s privacy model. The ambition is to get there, but we’re not there yet, and there have been no claims otherwise.

In conclusion

You never achieve greater privacy than the size of your anonymity set

Grin is a minimal cryptocurrency that aims to be privacy-preserving, scalable, and fair. It’s far from perfect, but it achieves an equivalent security model as Bitcoin with better privacy that comes enabled by default, with less data required to be kept on chain. It does all this without a trusted setup, without a development tax, ICO, or pre-mine.

Yet, Grin is still very young and has yet to reach its full potential. Eleven months into mainnet, there is low network usage. In the last 1000 blocks, 22% contained only a single tx (and 30% contained no tx), meaning their inputs and outputs are trivially linkable. This won’t change until there’s greater network usage, but it still does not imply that sender and receiver identities are revealed.

Privacy research is helped by collaboration

As Grin contributors, we’re glad to see that there’s interest taken in the project. Scientific analysis and scrutinizing of Grin’s protocol and codebase is something that we welcome in the community, but also expect to carry some degree of rigour. In fact, it’s something we might have even been able to help with, had we been asked to.

The author of the paper had Haseeb, Oleg, Elena, Mohammed, and Nader review their work, yet unfortunately, did not take the opportunity to let anyone in the Grin community do the same and offer (friendly) feedback on what they were about to publish. Doing so might have prevented this response, and could only have improved the quality of the work. In a tweet, the author of the article writes:

“Importantly, I have great respect for the Grin community and core developers, who have all been tremendously helpful in answering my questions.”

It almost sounds as they’ve approached us here with the article, yet none of us have any recollection of encountering the author or this work in our Gitter channel or in Keybase. This was a missed opportunity to produce better quality research.

Co-authored by:
David Burkett, Jasper, @joltz, Quentin Le Sceller, Yeastplume.

This article’s format and opening paragraphs are inspired by Tony Arcieri’s post “Factual inaccuracies of “Facebook Libra is Architecturally Unsound”.

Grin is built by a friendly open source community that is welcoming to new contributions, suggestions, and improvements. If you’re reading this and you’re a researcher or engineer, you may want to take a look at our Open Research Problems and see if there’s anything you might be interested in helping with. Come and say hi on Gitter or Keybase.

--

--