A few days ago, a debate about Mimblewimble's privacy protections sparked heated discussions on Twitter. The incident stemmed from an article published on Medium by Dragonfly Capital researcher Ivan Bogatyy. In this article, Ivan Bogatyy clearly stated: "Mimblewimble's privacy protection function is fundamentally flawed." Affected by this, Grin, BEAM, Sero, etc.privacy coinNot a small decline occurred.
This translation from BEAM official responds to questions raised by Ivan Bogatyy and explains how BEAM alleviates them. This article was translated and edited by Mine Vision (Miracle Moore). If you need to reprint, please indicate the source.
Full text summary: The attack mentioned in the paper "Breaking MimbleWimbl's privacy model" is ineffective against BEAM, because BEAM's decoy output makes it more difficult to construct a transaction graph. Even in the face of more sophisticated attacks, the upcoming Lelantus-MW feature will make it almost impossible for attackers to construct transaction graphs.
The following is the full text (you need to go online scientifically to view the links in the text):
Mine Vision Translation: Why Breaking MimbleWimble's Privacy Model Doesn't Work for BEAM
We would like to contribute to the article published by Ivan Bogatyy (https://medium.com/) in our response, which states thatMimbleWimbleThere is no privacy at all. The article has aroused everyone's attention and discussion, and we are also very grateful to the author for his research and contribution.
However, we feel that some members of our community are overly concerned, so we would like to respond to the issues raised (which have also been well known and discussed in depth in the past), and we will also explain how BEAM alleviates these issues.
1 How did the attack actually work?
The system Ivan built collects and analyzes logs from multiple "sniffer" nodes connected to the Grin network.
When doing log analysis, the authors look for transactions with only one core. In Grin, having a kernel means that the transaction has not been merged with any other transaction, so the input of this transaction is connected to the output. When enough such associations are accumulated, it is possible to construct a transaction graph connecting different wallets, and using this graph, it is possible to deduce and prove the financial connection between two known parties.
Ivan didn't actually construct a transaction graph, the article just proved that it is possible to successfully construct a transaction graph - from finding associated inputs and outputs to constructing the actual transaction graph, to finding out the actual connection between specific parties, there are many more Long way to go.
The attack also does not reveal any user identities, such as IP addresses, nor transaction amounts.
Why GRIN or suffer from it?
The reason why such a large number of single-core transactions are broadcast to the network is that the Grin network is not saturated enough, and there are not enough transactions to merge in the backbone stage of the Dandelion Privacy Protocol.
As transaction volume increases, so does anonymity. But at the moment, as Ivan said, anonymity is low.
Why is BEAM different?
Although based on the same MimbleWimble protocol, unlike GRIN, BEAM adopts important privacy improvements while applying the Dandelion privacy protocol.
Early in the project, we identified potential transaction dependencies in MimbleWimble and considered mitigations.
In September 2018, Valdo (https://github.com/valdok) has published a technical paper on transaction correlation and how the BEAM team handles it
（https://github.com/BeamMW/beam/wiki/Transaction-graph-obfuscation）。
This paper describes the concept of decoy (aka dummy) UTXOs. Please note that BEAM has deployed this measure before the mainnet launch, and the mechanism is also discussed with the GRIN development team
https://gitter.im/grin_community/Lobby?at=5bebf9d76b9822140d2a7b37 , who decided not to implement it.
How do these dummies work? At each step in the Dandelion trunk phase, BEAM nodes check whether the merged transaction (possibly only one transaction) reaches at least 5 outputs. If not, the decoy output will be added to the merger transaction, ensuring that the number of outputs is at least 5.
You can find it here (https://explorer.beam.mw/) or here (https://explorer.beamprivacy.community/)
Check out the BEAM blockchain explorer and see that every block with at least 2 cores (meaning at least one block with transaction info not just currency) has at least 7 outputs (coin, transaction fee, receipt payer and 4 dummies).
Each dummy outputs a value of zero, but it's completely indistinguishable from regular output -- all output looks like random numbers.
In a later stage (randomly choosing a block height for each output), nodes add dummy UTXOs as inputs to random transactions, likely belonging to different users, thereby consuming the dummy and removing it from the blockchain, but It also creates virtually irrelevant connections between users, hence the name decoy.
Another thing to note is that since these decoy outputs will eventually be used, this mechanism will not cause any permanent chaos on the blockchain.
2 Why are attacks more difficult to implement on BEAM?
If a similar operation were run on BEAM, the researchers might still find many single-core transactions. Although BEAM handles 60% more transactions than GRIN (average over the past 30 days), it is still not enough to guarantee that two or more real transactions will always "meet" in the trunk stage. However, such single-core transactions are useless for mining transaction graphs due to the use of fake outputs.
The decoys in BEAM make building a transaction graph a probabilistic task, and the probability of association between two wallets decays exponentially with the number of hops.
As Ivan explained in a tweet (https://twitter.com/IvanBogatyy/status/1196441085221855233?s=20):
Mine Vision Translation: Why Breaking MimbleWimble's Privacy Model Doesn't Work for BEAM
This is not practical for BEAM - even if there are no mergers between transactions, they still have an anonymity set of at least 4 decoy outputs (this number is configurable).
Next stage: Lelantus-MW
The decoy output in BEAM increases the anonymity set, which makes it more difficult to construct the transaction graph as Ivan described, but it is still possible to achieve to some extent. Some have also exemplified other more sophisticated active attacks, such as the flashlight attack mentioned by Ian Miers.
Therefore, we decided to implement (https://github.com/) Lelantus-MW, and launched shortly thereafter.
Lelantus MW will significantly increase the anonymity set (up to 100 K outputs), and if users choose to use Lelantus-MW transactions from time to time, building a transaction graph really becomes an almost impossible task.
More information about Lelantus-MW can also be found by clicking here (https://github.com/) or here
（https://docs.google.com/)learn.
end with a challenge
Original link:
Original link:
——–END——–
IOS
Android