Providing a paper about the security of Grin and MimbleWimble with considering the network is populated (not as much as much bitcoin) and how dangerous is transaction graph leaking to privacy would be a good start to degenerate “broken privacy” thinking.
I don’t have computer science knowledge, but I assume even with having an archive node and lots of computational power, the linkability of transactions would need hard effort if there were 800 - 1000 output included in each block.
Describing the point of failure in Grin privacy and quantifying it would be considered a huge and valuable piece of work. It would be perfect if someone with the knowledge to step in and do the math.
I believe this is much harder than it appears at first. It should be relatively easy to show little can be learned about the amounts and addresses but the transaction graph seems like a complex thing to analyze. The main reason is that you don’t know what information people have and this metadata could help reason about the ownership of outputs. Here’s one example I expect to see in the future.
You know the output P is owned by a store located at physical location S. If P is used in a payjoin transaction, then you can probabilistically map the GPS location of cellular phones/identities in that range at time when the transaction T containing P arrived at the mempool. This gives you a set of people which are good candidates for one of the outputs that were created in T. When these outputs created are spent next, you can similarly use location information to drastically reduce the set, quite possibly to a single individual. Then you can start probabilistically tracking the user spendings based on this metadata. This isn’t a problem of payjoins. The owner of the store could report on a receive the ownership of P - and some likely will. It also isn’t a problem of a physical location. Instead of having a physical location, you can have a digital location and instead of gps coordinates you have network traffic and timing analysis (which is harder, but probably not impossible). To make matters worse, you can analyze this retroactively, so even if the links were unlikely to be known today, if you collect all the information you could do a computation that reveals this data later in the future when you actually know how to derive the links with identities.
How do you solve this? One obvious path is to get rid of the transaction graph altogether which is what ZCash wants to do, or have an anonymity set which is very large (lelantus). But if you retain the UTXO model like Bitcoin or Grin, you will have these issues. Can we battle this and make it hard? I’m not sure it’s possible to prevent learning about an output with metadata. Location will be available and deriving the owner from that will likely be possible. But the real issue in my opinion is the subsequent tracking that happens because of the identity knowledge of one transaction. Knowing that you bought X at store Y can always be leaked by the store, the question is whether people can then track your next transactions because of the knowledge of a previous transaction.
An attempt to mitigate this is Mimblewimble CoinSwap proposal. If this was a default wallet behaviour, they might learn which output is yours as you spend it (due to metadata like location etc.), but the knowledge about this output only lasts for 24 hours because after 24 hours, it will become one of 1000 outputs. So if you only use outputs whose knowledge was forgotten, they would only learn that it belonged to you, but would not be able to tell its history. In other words, the fungibility is improved. It blinds all of your neighbours from doing analysis on your transactions and it further blinds everyone if at least one mix node is honest. While not perfect, it seems to me like a good start at improving the issues mentioned above.
Thanks for a detailed explanation. You bring up a real situation, but I worry that much detail is not still considered in the industry by Chainalysis and Crystal (like limiting with GPS location of cellular phones for paying with crypto). I think we can change the subject of the request into “Point of failures for each Privacy coin” to show how much users are responsible for leaking information in each cryptocurrency. The main mistakes should be common not matter what currency is, but some mistakes could be covered up in some coins. I think we can make a good infographic out of this topic too.
@oryph correctly identifies one of the few metadata’s that is still a weakness with Grin, time. This is funny since Grin is a time coin, but knowledge of when Transactions hit the memory-pool can indeed be misused. Furthermore, I am worried about automated payout system such as mining pools that might have a certain time they do all payments. It is not that this information can be used to identify individuals, but more that such knowledge can be use to discard or ignore a large portion of the transactions to filter out real day to day transactions making those more easy to identify.
For GPS locations as well as IP locations, those can indeed be derived if sufficient transaction data is available. E.g. If you control enough nodes in the TOR network and sufficient transactions are happening to a user, it becomes possible to identify the origin of a transaction. A simple VPN service provides protections against such attacks. Also as @Oryph points out, Coin-swaps are an excellent weapon against such automated approaches. I also really like the idea of having the receiver pay part of the fees so he/she has an output in the transaction and no new UTXO’s are created. So in summary
- Allows user to withdraw whenever they want with mining pools, to avoid creating patterns in Time as variable. In automated payments systems, include random offsets to make those transactions less easy to identify and discard
- Remove directionality by using same amount of inputs and outputs by sender and receiver (split the fees).
- Use existing methods to avoid IP tracing, TOR, VPN, Dandelion
- Use coin-swaps now and then since this royally F***s up any transaction graph to metadata linkage.
But you are right @Gorfo that many of these points apply also for other coins. A difference is that most of those obfuscate the transaction graph by creating uncertainty in linkage, so it becomes harder to trace a long transaction graph. Grin does not do so since it bloats the blockchain. So we need to obfuscate by mixing, swapping, stimulating user to make many small transactions like donations on Redit. Etc.
Sorry for my lack of knowledge, but is that a common problem between all blockchains? AFAIK mempool is a necessity and all txs will have received time with them. Is it solvable with Dandelion? (and an extra question :D. Is it implemented in Grin?)
I worry this is not achievable with a low or high tx traffic network (first one leak tx graph automatically and the second one takes away the power of doing on-chain transactions because of high costs for individuals, so I call it a short to mid term solution - Also Grin’s fix fee is a barrier to do it)
How can this done? with Coin-swap?
Yes, that is a common problem for all blockchains. Only way I can think of to solve that is by using 2nd layer technology such as lightning transactions. Regarding giving the user the power to withdraw when they want, this is already how it works for some mining pols like Grinmint, you request payout whenever you feel like. Dandelion was implemented in Grin AFAIK, but I have no idea how to use, I never tried
Yes, actually I am not perfectly happy with the base fee being so hight, although there are good security reasons why this was chosen. I do not see a solution here on the short term, just have to wait for lightning transactions to come. Also, personally, I find it acceptable that Grin is not 100% perfect in privacy. For me it is about the balance and trade-offs when it comes to minimalism, scalability, privacy…in which case Grin is a real winner since it has a great balance of all three, privacy at minimal costs. Tromp made this nice graph where these traits are compared with other privacy coins, unfortunately I cannot find it right now.
Payjoins, this post explains it:
Nice benefit is that in addition to obfuscating directionality, the UTX0 set does not increase when the number of inputs and outputs of a transaction are the same, so it helps with scalability.