MWC Privacy Now and Later

Chris Dev

//
June 23, 2020

The GRIN code provided a good foundation for ghost money which is why MWC forked from it. The roadmap states there appears to be no need for either a soft or hard fork so that means the base layer has essentially ossified.

Nevertheless, there is significant work to do improving the privacy and fungibility for MWC users that does not relate to consensus rules. The latest stop on this journey of financial innovation was the release of MWC Qt Wallet 1.0.22, which enables TOR support for payment methods.

The 1.0.22 release introduces TOR addresses which are completely integrated into the QT wallet. No setup is required as the TOR binary is shipped on all platforms. We see this as a replacement to MWCMQS and will make withdrawals from exchanges much easier and private for users.

The MWC Team plans to continue implementing additional privacy features that offer advantages and benefits to MWC users by improving these three aspects of privacy in a cryptocurrency.

1.) Privacy of amount

2.) Privacy of location

3.) Link-ability

Currently, MWC users have largely complete privacy of amount and privacy of location.

PRIVACY OF AMOUNT

Privacy of amount means that amounts in transactions are only known to the participants.

In Bitcoin, all amounts are stored on an immutable public ledger.

In MWC, privacy of amount is already implemented at the base layer by default for all users.

An MWC receiver is only able to know the receiving amount and has no knowledge of "change output" details.

Therefore, MWC privacy of amount is largely already complete.

PRIVACY OF LOCATION

Privacy of location means that no other user, transaction participant, node, etc. can be aware of a user's IP address and hence be able to determine a location.

MWC already had the ability for users to attain privacy of location by using either Files or transferring through secure means like http(s) but it was not really practical until the latest QT wallet release.

The TOR integration for sending and receiving results in fungibility among transaction participants and any observer, like an ISP, will only see TOR traffic and will not know there may be MWC transactions being conducted.

Additional work can be done to increase user's privacy of location.

A goal is to have the ability for a user to download the QT Wallet, perhaps using the TOR browser, and never make any connections using regular traceable protocols like HTTP/S. All communications would be done through TOR or some other method that does not allow leaking of IP address or other user information like browser fingerprinting.

The exact implementation details of how that is done is part of the task of the MWC developers that are working on the wallet, but needless to say, the vision is that all external communications will be done through TOR or another decentralized peer-to-peer anonymization network if one becomes available that has more suitable features than TOR.

On a somewhat related topic, another goal is to have all wallets running a local full node. Currently, there are three options in the QT wallet:

1.) Developer node

2.) Embeded node

3.) Custom node

Eventually, the intention is to remove the Developer node as all wallets should use either the embedded node or a custom node.

These two things together will mean that users have complete privacy of location and also complete decentralization because every wallet will have it's own node installed and the communication with it will be local to the machine the wallet is installed on.

However, the embedded node needs to be improved with greater efficiency and user friendliness. Nevertheless, we think these are achievable goals in the not too distant future.

LINK-ABILITY

Link-ability means the ability for coins to be linked to one another through data available either on-chain or by listening to other nodes on the network.

Legacy blockchain protocols like Bitcoin have significant linkability which creates many opportunities.

Federal Reserve Chairman Powell has said, "A ledger where you know everybody’s payments is not something that would be particularly attractive in the context of the US."

For example, Coinbase has pursued selling blockchain analysis services to the IRS and DEA and an Amazon patent states, “For example, a group of electronic or internet retailers who accept bitcoin transactions may have a shipping address that may correlate with the bitcoin address. The electronic retailers may combine the shipping address with the bitcoin transaction data to create correlated data and republish the combined data as a combined data stream”.

Basically, the plan is to aggregate a feed that will enable storing and distributing a Bitcoin user's spending habits, personal information, home addresses, other wallet addresses and balances, etc. and sell that data to the highest bidder.

In late 2019, the article "Breaking Mimblewimble" discussed why, in the author's opinion, Mimblewimble's link-ability is broken. The MWC Team already published an extensive response to "Breaking Mimblewimble". A major point is that the article was written based on the GRIN network today, but at scale or with different assumptions, the article is not applicable.

The author also noted that MW based protocols already hide amounts and, we think, would acknowledge that privacy of location is also possible.

The author's criticisms centered around the link-ability of Mimblewimble transactions. But, what he did not discuss was the fact that, at scale, the picture would be much different. Since Mimblewimble is in it's infancy, we need to not just look at the picture today, but also look at what's possible when the protocol is in use by many participants.

One of the important features of MWC is the dandylion protocol that is built into the full node and at the core of the protocol. This protocol is designed to aggregate transactions such that no single participant can link all transactions on the network together.

The researcher pointed out that a well funded participant could run many nodes and connect to all the important nodes on the network and thus be able to link most transactions on the network. But if all the nodes run behind TOR then how are the 'important nodes' determined?

The author did concede that something like Coinjoin could be used to break the ability for attackers to link transactions, but one thing he didn't mention is that, since the leading Mimblewimble based coins all implement the dandylion protocol, it would be impossible for an attacker to know whether a transaction was aggregated by the dandylion protocol itself or that the transactions were aggregated before they were submitted to the network.

This is an important assumption because it means that, unlike in cryptocurrencies like Bitcoin, coinjoins and other similar techniques cannot be detected.

Whether implemented in a decentralized way, as part of the full node, or external to the network, MWC transactions can be aggregated in a way that is completely undetectable.

Due to this fact, we believe, at scale, MWC users will be able to avoid having transactions linked to one another in such a way that it becomes too difficult for the attacker to try to link. It will likely be a cat and mouse game where users trying to avoid being linked will try to one up the linker. In the end, the linker is likely to be out maneuvered due to the fact that coinjoin techniques are indistinguishable from the standard aggregations done at the node level.

CONCLUSION

In summary, MWC privacy is only getting stronger with additional software being written and deployed. Currently MWC users have largely complete privacy of amount and privacy of location. There are significant features to work on that hold lots of promise and can improve reduce or completely eliminate link-ability.

Mimblewimble technology is already making it significantly harder to track coin flows. Plus, there are many features that can be built out and deployed that will significantly improve the landscape. And all of this financial innovation is able to take place with the inherent scalability of the Mimblewimble protocol.