Beam: The Best in Privacy

Published in

BEAM Privacy

11 min readOct 15, 2020

TLDR; Following release 5.2 of Beam wallets, Beam will have achieved best in class privacy for all practical purposes and real-life applications. In this article we will review the key components of Beam privacy architecture summarizing over 30 months of hard work in both research and development. Looking forward, Beam is quickly becoming much more than just a privacy coin, with the addition of the Confidential DeFi platform and applications.

The less they know the better you sleep

Alex Romanov, Beam CTO, 2020

A bit of History

The Beam project started in March 2018 and after nine and a half months of development launched the first ever Mimblewimble based confidential cryptocurrency on January 3rd 2019, the ten year anniversary of Bitcoin Genesis block. During the next two years Beam has continued improving and expanding its technology and product line at an incredible speed. Some of the highlights include:

Decentralized trustless Atomic Swaps between BEAM and BTC, LTC QTUM (and soon BSV, BCH, DOGE, DASH and Ethereum) blockchains.
Chainwork SPV wallets — first ever implementation of the FlyClient protocol created by Benedikt Bunz
Laser Beam — instant confirmation direct payment channels
LelantusMW — first ever implementation of the Lelantus shielded pool based confidential protocol.
BeamHash III — unique mining algorithm for smooth transition between GPU and ASIC mining.
Confidential Assets — ability to create new confidential tokens on top of Beam blockchain.

Beam has also created a vast ecosystem of beautiful and usable UI wallets for all platforms, both desktop and mobile, and accessible APIs for easy integrations. As of now, Beam is listed on over 50 exchanges and accepted in several hundred online stores and services.

Now let’s see how Beam approached and solved the problem of creating the best privacy coin.

Define Privacy

In the context of a cryptocurrency privacy can be broken down into three basic questions:

Who are you?
What do you do?
Who do you do it with?

Let’s see how the Beam implementation addresses these questions one by one.

Who are you?

Bitcoin and many other cryptocurrencies have something called an ‘address’. If you want to send someone some coins you need to know their address. In Bitcoin, this address has two properties:

1. It is used by the receiver of funds to prove ownership of the coins.

2. It is recorded in the distributed immutable ledger (aka blockchain).

Bitcoin addresses are pseudonymous, meaning that it does not contain the identity of its owner, however research has shown that it is very possible to establish this identity by tracing Bitcoin transactions to some point that has identity information attached to it (like an exchange with KYC data). And, due to property number 2, it is possible to do it retroactively by analyzing the blockchain backwards to the very first block and finding all transactions this address has ever participated in. Creating new addresses does not help since each such address has to receive funds from somewhere to be used, and these funds can be traced as well.

The Mimblewimble protocol (MW), which Beam is based upon, does not have addresses. In basic MW transactions are created online and are signed by both the sender and the receiver (unlike Bitcoin where transactions are only signed by the sender). This means that no address or any other identity related information is ever recorded on chain at all.

This does make the process of creating transactions much more cumbersome, which is why Beam has a Secure Bulletin Board System (SBBS) built into all wallets and nodes. SBBS is a decentralized and distributed encrypted messaging system that allows wallets to create transactions without having to be online at the exact same time and since it is built into all wallets greatly improves the usability of the process. To make it look even more familiar to Bitcoin users, SBBS has something called ‘SBBS address’ that is generated by the receiver and then used by the sender to start a new transaction. Unlike Bitcoin addresses, SBBS addresses have the following properties:

1. It is NOT used by the receiver of funds to prove ownership

2. It is NOT recorded in the blockchain

Here is a short FAQ regarding SBBS messages:

Is it possible to read all SBBS messages sent in the system?
Of course, it is as simple as setting up a Beam node.

Is it possible to know who is the sender of the message?
Yes, with some work you can figure out the IP of the sender, and thus deduce their identity.

Is it possible to know who is the receiver of the message or what it is about?
No, the entire message is encrypted with the public key of the receiver and is pulled in by the receiver in bulk, so neither the identity nor the very fact of reception could be deduced.

Does the fact of sending an SBBS message constitute a proof that a transaction has occurred?
No, messages can remain unanswered, besides, there are many types of SBBS messages some of which are not related to transactions at all.

In short, all you can know from the SBBS system is that some person has sent a message.

What do you do?

Even though there are no addresses in the blockchain, there is still SOME information there. What does it tell us about the value of the transaction or maybe any other properties?

Short answer is: no identity or transaction information (amount, type, etc…) is visible on the blockchain.

The value is encrypted. The type of the transaction is encrypted and when the transaction involves Beam Confidential Assets — new tokens that can be created on top of Beam blockchain and that inherit all privacy properties of Beam itself — even the type of asset is encrypted. Just by looking at a single transaction in a blockchain (see side note), the so called passive attack, you can only tell that some random looking inputs were transformed into some random looking outputs. This is where it gets interesting and brings us to the third question: Who do you do it with.

Side note:
Even looking at a single transaction in the Beam blockchain is not a simple task. When a node receives a new transaction from the wallet it does not immediately broadcast it to the network but rather engages the Dandelion protocol with decoy outputs. What it means is that the node rolls a dice (say a ten sided one like those you used when playing Dungeons and Dragons) and if a number between 1 and 9 comes out it selected a random peer and only sends the transaction to this one node (aka the stem phase of the dandelion), which in turn rolls its own dice and does the same. Only if a 10 comes out, does the node broadcast the transaction (aka the fluff phase of the dandelion).

What’s more, if the node participating in the stem phase has some other transactions waiting, it non interactively merges them with the new transaction in a way that can not be separated back and if there are not enough transactions to merge with the node adds decoy outputs with zero sum that are indistinguishable from real outputs (these decoy outputs are later spent by the same node as decoy inputs and then removed by the MW cut-through feature, thus having zero total impact on the blockchain size). So the only way you can see a single transaction in Beam is if you are the first node in the Dandelion stem, if you are the one who sent it or if you are the one who sent all the other transactions in the stem. Possible, but not a simple thing to achieve, especially for the passive attacker.

Who do you do it with?

In the context of cryptocurrencies we can differentiate between two types of attackers.

Passive attackers analyze information on the blockchain retroactively and do not send any transactions.
Active attackers identify the targets wallet and attempts to deanonymize or link it to another person or wallet by actively sending transactions to that wallet and monitoring the blockchain state to determine the possible recipients of those funds.

As we have seen the passive attacker has no chance against Beam. But who said the attacker should be passive?

Let’s say an active attacker wants to establish a connection between two wallets, at least one of which is a known suspect. They will send transactions to this wallet (inputs of which are obviously known to the attackers) and then look at the blockchain to see which outputs were created. This process of determination which inputs were transformed to which outputs is known as reconstructing the transaction graph and as we have seen from the side note above it’s very difficult, but not impossible. Now, if the attackers are lucky, at some point one of these outputs along the way will be sent to an exchange, with the KYC information, which can be forced by law to disclose this information. Now the attackers have a non zero probability that these wallets are connected.

This is of course, as they would say in the movies, ‘very thin’, but by repeating this active attack many times, and observing this correlation the probability could theoretically be increased to some statistically significant number that might imply a real link between the wallets.

This attack on MW is known as the “MW linkability problem” and this is the only known attack against the MW protocol and is the only one used in articles that discuss MW weaknesses, exaggerating the simplicity of performing the steps described above.

However, it is a valid point, so what do we do? Enter LelantusMW.

Lelantus protocol was developed by a cryptographer Aram Jivanyan for the ZCoin cryptocurrency and adapted by Beam to augment the MW protocol. We called this adaptation LelantusMW and published a paper describing the changes we have done. The purpose of LelantusMW is to break coin linkability by burning the old coin and creating a new one which is completely unlinked from any previous history.

LelantusMW creates a shielded pool, basically a pool of coins with a maximum anonymity set of 64K. Before we continue to describe how this helps us with the linkability problem let’s first understand what the **** an anonymity set is.

What the **** is an anonymity set?

Many cop movies feature a lineup, a process in which several individuals (usually five) are standing in one line and the witnesses are pointing at the one they recognize as the potential felon. Now imagine that you are standing in such a lineup but the other four people look EXACTLY like you. Since the witnesses have no chance to distinguish you from the others visually, they can only choose you by accident and the probability of this ‘accident’ is one in five. In this case we can say that this is an anonymity set of size 5.

LelantusMW pool does the same trick with transaction outputs (TXOs) only with an anonymity set of 64K, basically like having 64 thousand people in that lineup. After TXO is submitted to the pool, a completely new output is created along with the proof that it corresponds to one of 64 thousand other outputs in the pool. This new output has never been seen before in the blockchain and is thus completely unlinked from the previous history. It looks as it has just appeared out of nowhere and it can not be traced back, thus breaking the transaction graph and solving the MW linkability problem.

Side note: As a kind of added bonus, Lelantus is a non interactive protocol, which means that senders can submit coins into the pool for other wallets (receivers) without requiring their signature and thus emulate Bitcoin like transactions, the property which Beam has used in the recently released ‘Offline transactions’ feature in Beam wallets.

Short FAQ regarding LelantusMW:

If LelantusMW is so great, why don’t we use it all the time? Who needs MW anymore?
Good question, however, nothing in this life comes completely free and Lelantus has some important tradeoffs to consider. The proofs needed for the process of extracting new coins from the pool are relatively large and more time consuming to construct compared to MW, and the Lelantus pool does not lend itself to the cut-through process, thus increases the blockchain size, which in turn is bad for decentralization. Which is why Beam has decided to go with the balanced combination of the two protocols to achieve the best tradeoff between privacy and scalability in terms of the blockchain size.

One last question please, as a user, do I really need to worry about any of that when I use Beam wallets?
Of course not. Beam wallets hide the complexity by providing three clear types of transactions:

Regular — the good old MW transaction that should be used most of the time and costs minimal fees from 100 Groth. These transactions were available from the very first version of Beam wallet.
Offline — that uses LelantusMW shielded pool and breaks the transaction graph but does not guarantee minimal anonymity set. These should be used when the receiver is offline and cost 0,01 Beam for each output. These transactions were introduced in the recently released 5.1 version.
Max Privacy — that both breaks linkability and guarantees an anonymity set of 64K. They cost the same fee as the Offline transaction, but might take a significantly longer time to complete, depending on the anonymity set required. These transactions will be released with the next 5.2 version scheduled for October 2020.

For any transaction type you choose, the wallet will automatically select the best set of available coins both in terms of privacy (as first priority), fees and change.

To conclude

Beam privacy architecture offers the combination of Mimblewimble, LelantusMW and Dandelion protocols to provide the best in class privacy with superior scalability and usability. All of the features described above are already deployed on Beam network starting from the 5.0 hard fork that was activated in July 2020, and are now being added to Beam Desktop and Mobile wallets, as well as APIs and the Beam blockchain explorer.

Is Beam’s mission complete? Far from it. Even though Beam has achieved the best privacy, our next target is to expand this technology to more use cases including the Confidential DeFi platform and applications, such as Confidential Stable Coin, Decentralized Exchange for Confidential Assets, Non fungible tokens, and more. Check out our roadmap and follow the news for updates.