Why "Break the MimbleWimble Privacy Model" does not apply to BEAM

A few days ago, a debate about Mimblewimble's privacy protection sparked heated discussions on Twitter. The event was based on an article published by Dragonfly Capital researcher Ivan Bogatyy on Medium. In this article, Ivan Bogatyy made it clear: “Mimblewimble's privacy protection features are fundamentally flawed.” As a result, privacy notes such as Grin, BEAM, and Sero have seen significant declines.

The translation comes from BEAM's official response to questions from Ivan Bogatyy and explains how BEAM mitigates these issues. This article is translated and edited by the mine vision (Miracle Moore). If you need to reprint, please indicate the source.

Summary of the full text: The attack mentioned in the article "Breakthrough MimbleWimbl Privacy Model" is not valid for BEAM because BEAM's bait output makes it harder to build a transaction graph. Even in the face of more sophisticated attacks, the upcoming Lelantus-MW feature will make it almost impossible for an attacker to build a trading map.

The following is the full text (see the link in the text for scientific internet access):

• Opinion: Blockchain development requires industry self-regulation and market supervision, applying technology to the real world and creating value
• Jia Nan’s coronation moment
• Advanced Edition Interpretation | What is a blockchain?

We would like to respond to an article by Ivan Bogatyy (https://medium.com/dragonfly-research/breaking-mimblewimble-privacy-model-84bcd67bfe52), which states that MimbleWimble has no privacy. The article has aroused everyone's attention and discussion, and we are also grateful for the research and contributions made by the author.

However, we believe that some of the members of our community are a bit too sorrowful, so we want to respond to the questions raised (these issues have been familiar and in-depth in the past), and we will explain how B EAM mitigates these problems . .

1 How is the attack actually carried out?

The system built by Ivan collects logs and analyzes them from multiple "sniffer" nodes connected to the Grin network.

In the log analysis, the author looks for transactions with only one kernel. In Grin, having a kernel means that the transaction is not merged with any other transaction, so the input and output of the transaction are associated. When such associations are met, it is possible to construct a transaction map that connects different wallets, and use this diagram to derive a financial connection between two known parties.

Ivan didn't actually build a trading chart. The article just proved that it is possible to build a trading chart successfully—from finding the input and output to building the actual trading chart, and then finding out the actual connection between the specific parties. The long way to go.

The attack also does not display any user identity, such as an IP address, nor does it display the transaction amount.

Why is GRIN harmed?

The reason for this large number of single-core transactions being broadcast to the network is that the Grin network is not saturated enough, and there is not enough transaction to merge in the main stage of the Dandelion privacy agreement.

Anonymity will also improve as the volume of transactions increases. But now, as Ivan said, anonymity is low.

Why is BEAM different?

Although based on the same MimbleWimble protocol, unlike GRIN, BEAM has taken important privacy improvements when applying the Dandelion Privacy Agreement.

Early in the project, we discovered potential trading correlations in MimbleWimble and considered mitigation measures.

In September 2018, Valdo (https://github.com/valdok) has published a technical paper on transaction relevance and how the BEAM team handles this issue.

(https://github.com/BeamMW/beam/wiki/Transaction-graph-obfuscation).

This article describes the concept of bait (also known as dummy) UTXOs. Please note that BEAM has deployed this measure before the main online line and the mechanism is also discussed with the GRIN development team.

https://gitter.im/grin_community/Lobby?at=5bebf9d76b9822140d2a7b37 The latter decided not to implement it.

What is the operating principle of these dummies? At each step of the dandelion trunk phase, the BEAM node checks whether the merge transaction (and possibly only one transaction) has at least 5 outputs. If not, the bait output will be added to the merge transaction to ensure that the output is at least 5.

You can do it here (https://explorer.beam.mw/) or here (https://explorer.beamprivacy.community/)

Look at the BEAM blockchain resource manager and see that each block with at least 2 cores (meaning at least one transaction is not just a block of currency) has at least 7 outputs (currency, transaction fees, receipts) Employer and 4 dummy).

Each dummy has a zero output value, but it is completely indistinguishable from regular output – all outputs look like random numbers.

In the later stages (the block height is chosen randomly for each output), the node adds the dummy UTXOs as input to the random transaction, most likely belonging to a different user, consuming the dummy and removing it from the blockchain, but It also creates virtually irrelevant connections between users , so we also call it bait.

It is also important to note that since these bait outputs will eventually be used, this mechanism does not cause any permanent confusion on the blockchain.

2 Why is the attack more difficult to implement on BEAM?

If you run a similar operation on BEAM, the researchers may still find many single-core transactions. Although BEAM's entire network deals 60% more transactions than GRIN (the past 30-day average), it is not enough to ensure that two or more real transactions are “meeting” during the main phase. However, due to the use of pseudo-outputs, such single-core transactions have no reference value for exploring transaction graphs.

The bait in B EAM makes the construction of the transaction graph a probabilistic task, and the probability of association between the two wallets decreases exponentially with the increase in the number of hops.

As Ivan explained in the tweet (https://twitter.com/IvanBogatyy/status/1196441085221855233?s=20):

This is not true for BEAM – even if there are no mergers between transactions, they still have an anonymous set with at least 4 bait outputs (the number is configurable).

Next stage: Lelantus-MW

The bait output in BEAM adds an anonymous set, which makes it more difficult for Ivan to describe the construction of a transaction graph, but to some extent, there is still the possibility of implementation. Some people 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/BeamMW/beam/tree/lelantus_mw) Lelantus-MW and start it shortly.

Lelantus MW will significantly increase the anonymity set (up to 100 K output), and if the user chooses to use the Lelantus-MW transaction from time to time, building a trading chart will really become a task that is almost impossible.

More information about Lelantus-MW can also be found by clicking here (https://github.com/BeamMW/beam/wiki/Lelantus-MW) or here.

(https://docs.google.com/presentation/d/1t3RkaAyhsd_Y9NNheFzB8VAXzQ3hSq27dkBsm0M2i5w/edit#slide=id.p1)Understand.

End with challenge

We want to challenge Ivan's analysis of the BEAM network and try to establish a provable connection between a large number of wallets. Because for BEAM, a single core lookup transaction really doesn't work.

Original link:

Https://medium.com/beam-mw/will-breaking-mimblewimbles-privacy-model-work-on-beam-9125bc2ee863

——–END——–

We will continue to update Blocking; if you have any questions or suggestions, please contact us!