SerHack/books

A set of translated and written books.


Third Chapter: How Monero Works

The first two chapters have covered everything you need to know about why and how to use Monero. By now, you have learned everything necessary to begin using Monero yourself.

The rest of this book contains additional details, for those wishing to dive deeper, into how Monero works “behind the scenes.” Chapters 3 and 4 describe underlying technologies such as Monero’s privacy features, the blockchain, and the mining process – focusing on understanding the concepts, without digressing into the advanced mathematics. Later chapters will contain those nitty-gritty details for developers and cryptography geeks.

3.1 Transactions and the Ledger

To set the stage for understanding Monero’s privacy technologies, we will consider how moneroj are sent and received on the ledger. In this chapter, we will focus on blockchain functionality – specifically its role as an inherently tamper-proof shared database that records a list of Monero transactions. The details about blockchain security (mining, hashes, and network consensus) are another topic reserved for Chapter 4.

When you set up a wallet for the first time, it generates a new seed that you will keep secret and use to access your moneroj on the blockchain. This initialization process is carried out on your device and can be executed entirely offline – nothing is broadcast to, or recorded by, the network during wallet generation since the process involves only mathematical computations (for more details, refer to chapters XX and YY).

Behind the scenes, your wallet calculates two sets of keys from your seed. Your private keys should be considered a closely-guarded secret, since you use them to prove your identity and access your moneroj. Your public keys are, as the name implies, made known to other Monero users. Private and public keys are generated together as sets, with particular mathematical properties that create a special link between the keys. That specific link cannot be easily reversed (you can obtain the public keys from the private ones, but not vice versa) and the key generation process makes that link unique and not duplicable.

To receive moneroj, you give your public address (created from your public keys) to the sender. When somebody (a customer, an exchange, or a friend) sends you moneroj, they will broadcast a transaction that transfers some of their moneroj into a new entry on the ledger that you (and only you) can unlock with your private keys.

The transaction reaches the blockchain shared among the network participants (i.e. nodes). The database, approximately every 2 minutes (which is the time dictated by the protocol), creates a block inside which we find a list of all transactions. Think of blocks as announcements containing public modifications of the blockchain. When you receive your moneroj, that particular transaction confirms to the network that moneroj has been moved from the sender to the recipient (you), but in a private way.

In technical lingo, the output of their transaction is stored on the blockchain for you to access and spend, unlocking them with your private keys, at your leisure. This terminology can be a bit confusing, since the cryptocurrency use of the word “output” has a different meaning than its typical definition.

Each time you receive moneroj, you gain another output; each time you spend moneroj, you use one of your outputs and generate a new one for somebody else. In fact, all the moneroj that you “own” are simply outputs on the blockchain that your private keys unlock. Until somebody sends you moneroj, there will not be any outputs on the blockchain that are associated with, or accessible by, your private keys.

When your wallet is scanning or syncing this usually means that it is using your private keys to check all of the transactions and outputs on the blockchain to identify relevant entries. Your wallet balance is the total sum of these outputs that your private keys can unlock and spend. The syncing operation is needed because your wallet cannot deduce what transactions you own; therefore, your wallet needs to check every block to determine your balance. Fortunately for the Monero community, the developers have prioritized and executed on the improvement (speed) of the synchronization process.

When you send moneroj from your wallet, you use up some of your outputs as inputs for a transaction that you broadcast to the network. Conceptually, the blockchain is simply a record of these transactions, each consuming the sender’s outputs as inputs in an effort to generate a new output for the recipient.

The process described above is slightly simplified for the purpose of conveying the crucial parts (private/public keys, transactions, and inputs/outputs) in a way that is understandable. As a continuation of this approach, the following sections provide non-technical explanations of the key concepts underlying Monero’s suite of privacy features.

3.2 Privacy Technology Overview

The general principles and terminology introduced above are shared by most cryptocurrencies. In addition to this, Monero provides enhanced functionality and privacy through several unique cryptographic technologies that shield the users (sender, recipient, and transaction amount) and their activity from public visibility.

Figure 3.1 shows how these complementary features work together to protect sensitive transaction details:

Before digging into each technology, it is important to remember that these features are applied by default and do not require any special setup from the user. In addition to this, Monero network enforces privacy at transaction level and if a transaction does not use these technologies, the transaction is refused and cannot be inserted into blockchain.

Consider what could happen if Monero would not enforce privacy-by-default: a user optionally can refuse to be private for some illogical choices. In this instance, we would not know if the user disabled privacy because they were forced by someone or by something. Thus, a government, a company, or anyone could possibly force a user to opt out of privacy. The team behind Monero and its inherent privacy-oriented features mitigate this risk.

Furthermore, some advanced users might have tried to be private on transparent cryptocurrencies, such as Bitcoin or Ethereum. In most of the cases, they have taken up the daunting task of reading through dense and somewhat confusing documentation in an effort to mix and match cryptographic techniques that lack proven ability to provide the same level of privacy built into Monero.

[Image: https://raw.githubusercontent.com/monerobook/monerobook/master/resources/img/mm-c03i01%20monero%20tech.png]

3.2.1 Ring Confidential Transactions

Ring confidential transactions (RingCT) is a cryptographic technology that conceals the amount of moneroj being sent in a transaction. With most cryptocurrencies, transaction amounts are sent in cleartext and are visible to any observer of a blockchain. RingCT keeps this sensitive information private by allowing the sender to prove that they have enough moneroj for a transaction without revealing the value of that amount. This unique privacy feature is possible thanks to cryptographic commitments and range proofs that allow for the specification of a value while keeping it hidden.

When you send moneroj, you “commit” the amount in a private way, revealing just enough information for the network to confirm the legitimacy of the transaction, while not publicly disclosing the amount itself. A valid commitment guarantees that the transaction is not fraudulently creating or overspending moneroj.

Range proofs are another important mechanism utilized by RingCT – as a method to ensure that the committed amount is greater than zero and less than a certain number. This is necessary to prevent senders from committing negative or impossibly high amounts of moneroj (such as -1 or 2^64 - 1). Together, commitments and range proofs secure the supply of moneroj against fraudulent manipulation and counterfeiting attempts.

A clear use case for RingCT could be the following: suppose we need to send a certain amount of money to a business using a transparent blockchain, such as 0.0000002 BTC. Our wallet builds the transaction and sends it to the Bitcoin network. However, that day a large group of miners could agree and decide to mine only transactions that have the amount greater than 1 BTC in an effort to gather notoriety and make more earnings.

In the example described above, the transaction would be rejected and consequently all the services connected to that transaction (a contract with a business, purchasing goods, etc.) is dissolved. RingCT does not allow miners or any other entity to know how much money a user is sending or receiving in a transaction, so it is not possible to discriminate against a transaction based on how much moneroj is being moved or spent.

Prior to RingCT, Monero transactions were partitioned into specific denominations (for example, 12.5 XMR would be sent as 10 XMR + 2 XMR + 0.5 XMR) and the transaction amounts were visible to outside observers. In January 2017, RingCT was activated and rapid, widespread adoption immediately followed. Within 1 month of its activation, approximately 98% of new transactions were already voluntarily using the RingCT protocol.

In keeping with Monero’s policy of enforced privacy-by-default, RingCT became mandatory for all Monero transactions after September 2017. To spend any old pre-RingCT outputs, they must first be converted to RingCT outputs with masked amounts.

3.2.2 Stealth (One-Time) Addresses

All Monero transactions utilize stealth addresses to protect the privacy of the recipient. To avoid recording the public address of the recipient’s wallet on the blockchain, each Monero transaction is instead sent to a unique and disposable one-time address. The recipient can access funds sent to a stealth address without exposing any links to their wallet’s public address or other transactions.

[Image: https://raw.githubusercontent.com/monerobook/monerobook/master/resources/img/mm-c03i04%20stealth%20address.png]

To conceptualize the use of random one-time codes to protect the recipient’s identity, imagine that you wish to give a few books about coping with a sensitive illness to your friend André. Unfortunately, you are about to leave town for a trip and André will not be around until next week. Perhaps you could ask your friendly neighbor to temporarily hold onto the books and pass them along to the recipient.

Your neighbor will need to verify that anyone attempting to claim the books is actually the intended recipient. Since your friend is a private person with a sensitive condition, it would be inappropriate to tell your neighbor to check their ID for the name “André”. How could you arrange the exchange while preserving André’s privacy? You could simply make up a one-time random code and tell your neighbor to give the books to whoever presents that code (e.g. give these books to the person/intended recipient who knows the phrase PolarComboTango357). Utilizing this approach, your neighbor will be able to keep track of the books and give them to André, without learning anything about the recipient.

Similar to the way you might use that random, non-informative code to keep your neighbor from learning about your books’ recipient, Monero uses a system of one-time codes to prevent the network from learning about Monero recipients. Instead of explicitly recording the recipient’s address on the blockchain (analogously, “Give the books to André”), funds are always sent to a one-time “stealth address” (analogously, “Give these books to the person who knows the phrase PolarComboTango357”). The cryptographic techniques that secure stealth addresses solely for the recipient are discussed in chapter XX, however the salient points are detailed below.

How are these one-time addresses generated? Your Monero wallet’s public address is a 95-character string, which incorporates two public keys (the public view key and public spend key) mathematically derived from your seed. When somebody sends you funds, they will use the public keys in your address along with some random data to generate a unique one-time public key. These one-time public keys that are recorded in transactions on the blockchain are named stealth addresses, because it is impossible for the network or an outside observer to link these random, alphanumeric codes back to the originating wallet. In conducting a transaction, the recipient will not be able to ascertain or even leak the sender’s public address, but should the sender need to prove that they sent the transaction, the sender will be able to do so (this process will be discussed in section X.Y.Z).

[Image: https://raw.githubusercontent.com/monerobook/monerobook/master/resources/img/mm-c03i02%20donation.png]

The use of stealth addresses is a clear privacy benefit for Monero users and ensures that public wallet addresses are not visible on the blockchain. The inability to link or trace public addresses back to users is a privacy-enhancing technique that is inherent, mandatory, and enables improved privacy on the Monero network. In addition, another benefit of stealth addresses is that the use of a one-time key prevents multiple payments to the same public address being linked together.

Suppose you create some public art and post an address for cryptocurrency donations. If you use a coin with a transparent blockchain (e.g. Bitcoin), then every incoming transaction to that address is permanently recorded in a searchable and linkable form. Anyone can use a blockchain explorer to see how many Bitcoin donations or payments you have received, the amount of each transaction, and whether or not you have moved or spent the funds. Every incoming Bitcoin transaction is indexed on the ledger by the address that you shared publicly.

If you post a Monero address instead, your donations are not exposed to public scrutiny. Each donor will generate a unique one-time stealth address and record that on the ledger. The public (donation) address that you posted next to your project will never be directly referenced in a transaction as stealth addresses do not provide any information about the recipient. Since each donor mixes in their own random information to create a stealth address for a transaction, one donor cannot recognize a stealth address generated by another. All Monero transactions must use stealth addresses to ensure privacy for the entire network. Your wallet automatically creates the stealth address from the public address of the recipient when it generates the transaction.

Before moving on, it is important to note that subaddresses are not the same as stealth addresses. Subaddresses are reusable public wallet addresses that are not recorded on the blockchain. Multiple transactions sent to a single subaddress will all point to different and unlinkable stealth addresses.

3.2.3 Ring Signatures

Ring signatures are a feature of Monero that is designed to protect the sender of a transaction by obfuscating the source of the moneroj being spent. Before jumping into ring signatures, we will introduce the concept of digital signatures in general.

Digital signatures are a general cryptographic method for confirming the authenticity and source of data or a message. The signatures can be checked against the public key to confirm the identity of the signer and verify that the signed message is complete and unmodified. If the signed data is changed by even a single character (whether that be due to intentional tampering, accidental miscommunication, etc.) the signature will be rendered invalid.

Varying implementations of digital signatures are a key component of all cryptocurrencies. To spend one of your outputs, you compose a message to the network describing the transaction, sign it with your corresponding private key, and then broadcast the result to the Monero network privately using Dandelion++. Before executing the transaction, the network checks the validity of the signature to verify that the message has not been altered, and/or forged, by a third party that does not possess the correct private key. This process of checking the validity does not involve any keys or information concealing the transaction (sender, recipient, or transaction amount).

With transparent cryptocurrencies (e.g. Bitcoin) each message describing a transaction explicitly declares which outputs are being spent. This is useful for easy bookkeeping, since the network simply maintains a record of unspent transaction outputs (UTXOs) that are considered valid inputs for new transactions. If somebody attempts to spend the same Bitcoin output twice, the fraudulent second transaction is promptly rejected, since the network knows that the owner already spent that output (when they signed and broadcasted the first transaction). Unfortunately, this straightforward proof of ownership is highly detrimental to privacy by definitively indicating the source of funds and indicating when a given output is spent.

Monero uses a different scheme, known as ring signatures. This group-signing method allows one member to digitally sign the message on behalf of a group, while mixing in the public keys of the other members, so that it is unclear who actively signed the message. It is possible to cryptographically verify that one of the ring members signed the message, but impossible to determine which of the members crafted the signature. The set of members used as decoys are randomly chosen and much analysis has been performed to ensure that no entities can predict which decoys are going to be chosen.

Ring signatures are used in Monero to blend the keys from multiple outputs on the blockchain, in order to obfuscate which output is actually being spent. Suppose Maria wants to spend one of her Monero outputs. Her wallet will select several other past outputs on the blockchain (not belonging to Maria) and mix their public keys into the ring signature as decoys. The network is able to verify that one of the outputs is being spent; however, the decoys and true spender are cryptographically indistinguishable. We call this method “plausible deniability” because the network cannot identify which output has been spent – this, in effect, makes everyone participating in the transaction “plausible” spenders of the funds. If we extend the concept to all transactions, making ring signatures mandatory essentially enables everyone to be considered the real source of funds.

Ring signatures protect the sender of a transaction, since the recipient and Monero network are unable to ascertain which ring member is the true source of the funds. A significant benefit of ring signatures is that an outside observer is unable to definitively prove that an output has been spent. The fact that an output appears in a ring signature does not tell an observer of the blockchain anything, since it is impossible to distinguish whether the output was truly being spent or simply passively employed as a decoy ring member.

Since it is impossible to tell whether a particular output has been spent, you might be wondering what prevents an unscrupulous user from trying to spend the same output twice? With one-output-one-spend transparent blockchains (e.g. Bitcoin) this is a trivial task: any output that has been cryptographically signed and transferred once is marked as spent and cannot be used again. However, Monero outputs can appear in ring signatures before and after they have been spent, so output reuse must be prevented by other means. How could the network see something that is hidden?

This is accomplished by utilizing key images that are generated and recorded with each transaction – uniquely derived from the actual output being spent. Thanks to cryptography, the network cannot ascertain which ring member is connected to the key image; however, participants of the network only need to check whether or not the key image has been used before. If a malicious user attempts to spend the same output twice, it generates the same key image both times, and the network instantly rejects the fraudulent second transaction. Thanks to key images, the network can prevent output reuse, despite not knowing which outputs are spent.

[Image: https://raw.githubusercontent.com/monerobook/monerobook/master/resources/img/mm-c03i03%20ring%20signature.png]

Let’s say that in June 2022, George sends a Monero transaction containing 16 ring members. It is obvious to consider that the transaction ID was not on the blockchain before June 2022 and we would likely think that if the transaction was created earlier, the ring members would be different. An astute reader might say that the true origin of funds can be easily found, because that would be the most recent output created.

However, the transaction is built based on other transaction outputs, retrieved on the blockchain, and since the output that is actually being spent cannot be identified, the fact that a person sent a Monero transaction in June 2022 is irrelevant. A ring signature does not exist isolated, as it uses other outputs that likely appear in other signatures.

In the latter example, only one output of 16 could be of the real source of origin, thus there is a 1/16 = 6% probability that an output could be from the actual sender. Imagine if one malicious actor wants to identify the sender of 100 transactions (almost ~1600 ring members), the probability of each output is 0.00625%. That number decreases a lot considering that the ring members are connected to other transactions, other transactions are connected to other ring members, and so on. In that way, the Monero blockchain is not susceptible to mass surveillance.

It is intuitive to decrease the probability of identifying the output of an actual sender by adding as many decoys as possible. Unfortunately, compared to other cryptocurrencies, Monero transactions are heavy, because the structure of a ring contains all of the decoys. We now introduce the fees that are used to incentivize the network to mine a transaction. To quantify the value of the fee of a transaction (see chapter 4 and 9 for more technical information), the network calculates and provides a fee per byte. Since the transaction is going to be inserted into the blockchain, bigger transactions in terms of byte mean higher fees (this is also used to prevent attackers that would try to bloat the blockchain).

The structure of a ring implicates some cryptographic structures that are heavy to be kept on blockchain, thus creating a transaction with a huge number of decoys, in turn, increases the fee associated with a transaction. In the model that was used in the first years of introduction of ring signatures, the size of a transactions grew up linearly with the number of outputs (e.g. 1 output = 5kB, 2 outputs = 10kB, 4 outputs = 20kB, and so on). With a new technology called Bulletproofs, introduced in October 2018, the transaction size grew similarly to a logarithm function with regard to the number of outputs (e.g. 1 output = 5kB, 2 outputs = 5.5 kB, 4 outputs = 6.5 kB). Thanks to Bulletproofs, the time to verify a transaction decreased, which means that the Monero network was able to process more transactions than ever before.

Therefore, the Bulletproofs technology has greatly contributed to the scalability of Monero, because less size means less fees. The space saved by Bulletproofs technology may also enable the implementation of additional obfuscation mechanisms.

Originally the Monero network did not mandate ring signatures, which unfortunately allowed privacy-damaging zero-mixin transactions with no decoys. These early transactions had the same structure and weaknesses as transparent blockchains, by unequivocally identifying both the sender and receiver, along with revealing when the output was spent. Starting in 2016, the network began requiring two ring members for each signature, enforcing privacy-by-default for the sender. This was raised to a minimum ring size of five plausible signers in late 2017, and increased again to a minimum of seven potential signers in early 2018. In March 2022, a new hardfork occurred and the number has been set to 16.

Historically, between 2016 and 2018, ring size policies were formulated as a minimum number of mix-ins – where users were allowed to create transactions with larger rings if desired. On paper, one might think that using more decoys in a transaction guarantees more privacy. However, there is a practical issue to take into consideration: when the vast majority of transactions use the minimum ring size, larger custom ring sizes stand out as unusual, which is counterproductive for privacy. Since ring sizes are public, there are some identifiable transactions with a particular ring size (e.g. 69 or 1,024) that can connect all the different transactions with the same number of decoys.

This problem was addressed in the late 2018 network upgrade, where instead of specifying a minimum ring size, the network policies now mandated a fixed ring size. At the time of writing, all transactions must use ring signatures with exactly 16 members. This number may increase in the future, as research into statistical threat models and best privacy practices continue to evolve.

3.2.4 Dandelion++ & Traffic Analysis Countermeasures

Among the data that most private cryptocurrencies aim to protect, we find some information that is critical to initiating a transaction – such as who is sending the transaction, who is receiving the transaction, and the amount.

However, there are additional pieces of important transaction information that should be highlighted. There is other data called metadata that does not take on any particular importance for the blockchain, but allows an attacker to reveal certain details about a user. For example, metadata includes the date and time when a transaction is made, the IP address from which a transaction came from, and many other fields. In this chapter, we will talk specifically about IP address protection; although, a more in-depth section relating to metadata analysis can be found in chapters XX or YY.

The network is a fundamental part of Monero, because it allows anyone to connect to the blockchain and manage their wallet securely without downloading the entire blockchain locally (using a remote node). Moreover, the presence of a decentralized and distributed network is a fundamental requirement on which all cryptocurrencies are based. Therefore, an attacker could try to maliciously insert itself inside the network in an attempt to steal as many details as possible about a transaction and users.

To better understand the problem, it is necessary to introduce a bit of detail about how the Internet works. At the network level, any information between two different devices is encapsulated into packets that are addressed to specific network addresses (called IP addresses from the name of the protocol that manages them). Let’s explain this encapsulation through the classic example of the postal system. We assume that Mary and George want to exchange correspondence and Mary is trying to send a letter to George. Maria writes the letter on a piece of paper (the information) and places that paper in a paper envelope. On the paper envelope, Maria writes the information for the postal service, which is George’s home address. The postal service then does its best to send the letter to George’s home address as quickly as possible (so to speak…) by first moving the letter to George’s town through various municipalities. The letter carrier in George’s district finally receives the letter and begins the process of verifying his home address and then proceeds to deliver the envelope to George, who (once received) will read the letter. To respond, George uses the same method, writing Mary’s home address on the envelope.

The exact same method happens for any information that is generated by our devices, to which a header is inserted, a sort of stamp that tells the network where our information should be sent for IP addresses. The IP address is not randomly assigned, but it is an address (a series of unique numbers) that is reserved based on how you connect to the internet (wireless or cable). The IP address is given to you by an Internet Service Provider (ISP), which is a company you sign a contract with to get internet at your home or where you bought a new server. An IP address is assigned via some network characteristics, such as geographical location, the provider connected, the type of user (private or business), etc.

It is clear that an attacker could try to link the activity on the Monero network (which remains private anyway) with your IP address and, with a bit of luck, even to your identity. Going back to the postal system analogy, it is not possible to hide the sender’s address or the recipient’s address, because both pieces of data are used by the system to bring a letter to its destination. No one can guarantee that the postal system will not keep track of the addresses and correspondence in the envelopes. The contents of the envelope, if properly encrypted, could still be secure for both participants, but their addresses would be leaked.

While the postal system legally protects (to some extent) the information between two people holding correspondence, the same cannot be said for a decentralized network. In fact, in any decentralized network it is much easier to keep track of active connections by inserting malicious nodes, whose behavior is the same as the good nodes, but their main goal is to damage the network.

The ability to link Monero activity and transactions to IP addresses has several significant downsides. Some of the cryptographic measures described in the previous section that protect Monero users may be partially circumvented if IP addresses are logged by a node and, in turn, used to analyze and/or identify Monero users.

Since broadcasting to the Monero network reveals an IP address, a node receiving a transaction may be able to identify the physical location of the sender. While Monero’s other privacy features make it difficult to link transactions from blockchain data alone, surveilling node(s) that observe multiple transactions originating from the same IP address could infer that they may be connected.

In addition to these privacy concerns, exposed IP addresses also enable potential censorship. A malicious node might choose to not relay transactions from certain senders (individuals or groups). Even worse, the geographic information revealed by IP addresses might lead adversaries to pay a malicious visit to a sender’s doorstep.

The connection between IP addresses and Monero activity is not only a threat for the users sending transactions; the network traffic through nodes is currently visible to ISPs and other surveilling parties, which could put node owners at risk if governments or ISPs choose to take a negative stance toward cryptocurrencies.

Cryptocurrency miners may also experience unfair treatment if their IP addresses are connected to network activity. Malicious parties might seek to attack certain miners by censoring their blocks, perhaps due to some ideological disagreement or to limit non-government or non-corporate mining.

Clearly, all parties in the Monero ecosystem benefit from the decoupling of their network activity from their IP addresses (and thus their physical location/identity). This major flaw, however, has long been an open question since IP addresses are a fundamental part of the transmission protocol within a network.

So, it is not conceivable to completely remove the IP protocol, because it provides a good routing method compatible with many devices. To solve the problem, another option could be writing a new protocol from scratch that can provide privacy at the network level, but even this possibility is discarded since it would mean rewriting and replacing huge parts of code for electronic devices (routers, switches, computers, etc.) already on the market, that would be rendered incompatible with a new routing protocol.

The solution that Monero introduces is based on the use of a new application protocol called Dandelion++ that does not replace the IP protocol. Dandelion++ is a privacy improvement developed by researchers at the University of Illinois and utilized by the Monero network to alter the way transactions are propagated in an effort to make it more difficult to connect a transaction to a specific IP address; thereby creating plausibility deniability. Dandelion++ first routes transactions to a remote node in a special, undetectable way before initiating the flooding (which is a term used to describe the propagation process that is initiated when a Monero node broadcasts a user’s transaction).

Before Dandelion++, when George sends a new transaction, his wallet sends a message with the transaction, attaching a header with the IP address of the node he is connected to. Once the node receives the transaction, it is propagated to all the other nodes and so on. Subsequently, it is placed in a shared space called the mempool, which contains the list of transactions that had recently been sent (and not yet confirmed). Think of the mempool as a “waiting room” where transactions sit before being included in a new block. Obviously, the node that propagates the transaction can cause several headaches: the node can make the user believe that it has propagated the transaction (when in fact it has not) and it can potentially track the user’s IP address and much more.

From here, transaction propagation happens: this is where one node broadcasts the transaction and contacts all of its neighbors (other nodes) to propagate that information to its neighbors’ neighbors. Neighboring nodes of neighbors will do the same and in a very short period of time, the entire Monero network knows about your transaction.

To protect the sender of a transaction against tracking, some researchers have proposed utilizing Dandelion++. As it relates to propagation, below, we will identify two phases: a stem phase and a fluff phase.

During the stem phase, the user and his wallet forward the transaction to one or more nodes that are chosen at random. This node performs the same operation: it forwards the transaction to one or more particular nodes chosen according to an algorithm to avoid sending the message to the same node and to protect the communication (more specific information on this in Chapter XX). This continues until the transaction message arrives at a node in the fluff phase: the node that received the transaction and is in the fluff phase proceeds to forward it to all neighboring nodes.

To understand Dandelion++ even better, let’s look again at an example of the postal system and introduce a new infrastructure. Let’s think of the Monero network as a network of several postal entities with the nodes being the post offices. Each post office has a blockchain, an open-source shared database that maintains some very important information. To exchange information and keep this database in sync with others at all times, a post office receives and sends messages through letters.

With the postal system, as soon as a user wants to send a piece of information to the system, he connects to a post office by sending a letter. As a result, a post office prepares all the letters intended for the neighboring post offices and sends them. The neighboring post offices that receive the letters with valuable information will send more letters to the other neighboring post offices. In a short time, all post offices become aware of the information. Note, however, that if any attacker intercepts the first letter pretending to be a post office, he would immediately associate the information with the sender.

With Dandelion++, on the other hand, the user does not send a single letter, but sends a certain limited number of letters to nearby post offices. Upon receiving the letter, each post office (which is in stem mode) will forward the letter to another nearby post office – obviously replacing the sender’s information. If by chance a post office received a letter and it was in fluff mode, the post office would start preparing all the letters for its neighbors and so on. However, any attacker, even inside a post office, could never figure out which letter comes from a post office or a user, since it is not possible to predict whether a certain address is from a user or a post office. Dandelion++ does not introduce any particular technique to privatize message exchange, since it does not add significant delay to transaction propagation. However, it becomes much more difficult to trace the user who created a message, because the message of the transaction has been transferred to many other individual nodes, so any node could potentially be the originator of the transaction. The converse is abstractly similar to the way a ring signature obfuscates the actual signer of a transaction. Through the use of Dandelion++, a node does not know which user or node the transaction originated from.

However, Dandelion++ does not limit any attacks at the ISP level. To ensure that you are not being watched during your connection, you need to introduce some additional privacy layers. It is good to reiterate though that, in any situation, an attacker at the network level can only determine whether you are connected to a Monero node or not, since no information about your wallets is available.

There are currently several ways to achieve additional privacy, if you are in a situation where you must conceal your use of Monero on a monitored connection. Naturally, more privacy does not always imply more protection, because each solution described in the following paragraphs can add some attack surface, and thus make you vulnerable.

One option is a virtual private network (VPN), which can be used to send your traffic through an encrypted connection that your ISP and government cannot surveil. This works by establishing a secure tunnel between you and the VPN servers, so that your traffic is mixed with other users’ data and broadcasts from a different IP address. Note that the service providing your VPN could be keeping logs (even if they assure you they do not), so be sure to exercise due diligence and use a trustworthy company. Several cases of data leaks indicate that even reputable companies have been attacked and might reveal some details about your connections.

Another option is to use The Onion Router (“Tor”) to route your traffic through a private network of relay nodes. Tor was originally developed by the United States Naval Research Laboratory and is used by journalists, intelligence agencies, and those who must take extra steps to avoid surveillance or censorship. Tor is a free, decentralized open-source private network designed so that no participants can identify the source of any particular broadcast. Tor can be accessed through a dedicated browser and users with strong privacy needs can use a Linux distribution, such as Whonix, that routes all traffic through Tor.

Since 2019, Monero has also supported the integration of the decentralized Invisible Internet Project (I2P) routing system, which is similar to Tor. The connection via Tor/I2P is not exclusive to Monero, as it is available for other web-based applications. [Adding some details about I2P?]

3.3 Concluding Comments

Monero uses several unique privacy technologies to protect various elements of the network and all affiliated parties in every transaction. RingCT conceals the amount sent in each transaction. Ring signatures protect the sender by concealing the source of the funds, while stealth addresses ensure that the recipient’s public address is not recorded on the blockchain. Dandelion++ is a routing technology that breaks the link between your Monero activity and your physical location/identity. With the help of the Monero Research Lab and various auditing agencies, Monero will continue to identify and validate cutting edge encryption technology to make Monero as fast, secure, private, and efficient as possible.

Together, these features ensure that Monero users remain anonymous and that funds are not traceable. By cryptographically eliminating all the links used in analyzing transactions on the blockchain, Monero achieves fungibility, which is a necessary characteristic of a practical currency.

One of the key features of money is the feature known as fungibility. If something is fungible, it is easily exchangeable or substitutable. Many commonly traded commodities are fungible. Any given ton of copper can be exchanged for another ton of copper, or a barrel of oil for another barrel of oil. The cleanest example of a fungible object is money. A dollar equals a dollar, whether you received it as a gift, found it on the floor, or earned it by working. A dollar is also a dollar whether it is a dollar bill in your wallet, four quarters in a bowl of loose change, or a number on the screen when you check your bank balance online. It all has the same value. Money is fungible. Or in our case, one moneroj equals one moneroj. The encryption technologies used by Monero make it fungible and allow it to reach its goal of being true digital money.

Now, let’s compare Bitcoin and Monero in terms of fungibility. In this comparison, transaction history will play an important role. Bitcoin is not considered fungible, because its transparent blockchain allows anyone to trace where a Bitcoin came from. Let’s assume that you legally received a Bitcoin that had been used, previously, in a nefarious transaction. When that Bitcoin arrives in your wallet, it would be possible to look into the transaction of that specific Bitcoin and detect whether or not it had been used for an illicit activity. If that Bitcoin was used for such an act, it could be deemed as “dirty” and could be blacklisted by a merchant that accepts Bitcoin or even an exchange where you could trade that Bitcoin for another cryptocurrency. In other words, a Bitcoin leaves a trace on the blockchain. A so-called “clean” Bitcoin is worth slightly more than another coin on the network, as it has no history linking ownership of the Bitcoin to a specific wallet address that could have possibly taken part in a nefarious transaction.

As you are aware, Monero has an opaque blockchain. The history of a Monero transaction cannot be looked up or investigated, so one moneroj will always be equal to one moneroj. As noted above, by virtue of obfuscation, Monero cannot become tainted through participation in previous transactions. This means Monero is fungible and will always be accepted without the risk of censorship.

Now that you have read this chapter, you understand how Monero protects the individuals described in the use cases described in chapter 1.