How Dandelion++ Keeps Monero's Transaction Origins Private
Privacy as priority
As a cryptocurrency, Monero might seem very boring to the naked eye. It doesn’t have a big claim to fame such as being a ‘world computer’ or ‘revolutionizing xyz industry’. It’s just trying to be a private, digital, fungible money, and every upgrade and new technology just furthers this end.
Those that deem this goal as too narrow or uninteresting generally don’t understand how difficult it is to achieve meaningful privacy, especially on a permanent, open ledger like a blockchain. Any avenue for metadata leakage is a potential for privacy erosion.
Monero takes precautions to obfuscate on-chain data, such as the receiver, sender, and amounts, via stealth addresses, ring signatures, and Pedersen commitments respectively. This minimizes the chances of a casual observer from deducing critical info after transactions have already been sent and are now just a part of recorded history. There are, however some attacks that can be done the moment a transaction occurs that cannot be performed any time later.
Attack to reveal IP address
These attacks revolve around identifying which IP address a transaction came from. If this information is deduced it could reveal that an individual sent a Monero transaction. It’s not able to show to who, and how much, but there are some cases where the knowledge of someone using Monero is enough to cause harm.
The good news is, that if this information is not gleaned the moment the transaction is made, then it cannot be learned at a later date, since IP addresses are not stored on the blockchain. It is also comforting to know that such an attack is unlikely to be seen in the wild, as, in order to pull it off, the attacker would need a large majority of nodes on the network. If a person was able to command this large majority, however, they would be able to identify the “direction” a transaction came from.
This may be confusing, so we’ll explain some background info here. Each node connects to other nodes on the network, so that they can keep their blockchain up to date, as well as share what they know with others. These connections allow them to learn about new transactions, propagate them, and send their own. Since a node can only tell their peers about transactions they know about, it stands to reason that the very first node that propagates a transaction is the node that is actually sending Monero.
If an attacker owns a large majority of nodes on the network, each node will hear about a transaction from one of their peers, and based on the timing in which each node receives this information, they can deduce likely candidates for where the transaction started.
If this is still confusing, we offer this example. Suppose we both have a mutual friend that is hiding from our vision. This friend calls out loudly. I hear his call first, and I hear it louder than you do. From this information, we can know that I am likely closer to our friend than you are. The fact that you hear the sound later (even by just a split second) and the sound is fainter means that we should start our search around my area, not yours.
If an attacker is able to successfully guess which of their peers sent the transaction, since they have the IP address that is connected to their node and forwarded it to them, they can be certain of the IP address that sent it. This is powerful information, as IP addresses contains information about the country and internet service provider (ISP) of the user, and the ISP themselves know which user is linked to which exact IP address, effectively deanonymizing the Monero user.
The good news is, that if this information is not gleaned the moment the transaction is made, then it cannot be learned at a later date, since IP addresses are not stored on the blockchain. It is also comforting to know that such an attack is unlikely to be seen in the wild, as, in order to pull it off, the attacker would need a large majority of nodes on the network. If a person was able to command this large majority, however, they would be able to identify the “direction” a transaction came from.
This may be confusing, so we’ll explain some background info here. Each node connects to other nodes on the network, so that they can keep their blockchain up to date, as well as share what they know with others. These connections allow them to learn about new transactions, propagate them, and send their own. Since a node can only tell their peers about transactions they know about, it stands to reason that the very first node that propagates a transaction is the node that is actually sending Monero.
If an attacker owns a large majority of nodes on the network, each node will hear about a transaction from one of their peers, and based on the timing in which each node receives this information, they can deduce likely candidates for where the transaction started.
If this is still confusing, we offer this example. Suppose we both have a mutual friend that is hiding from our vision. This friend calls out loudly. I hear his call first, and I hear it louder than you do. From this information, we can know that I am likely closer to our friend than you are. The fact that you hear the sound later (even by just a split second) and the sound is fainter means that we should start our search around my area, not yours.
If an attacker is able to successfully guess which of their peers sent the transaction, since they have the IP address that is connected to their node and forwarded it to them, they can be certain of the IP address that sent it. This is powerful information, as IP addresses contains information about the country and internet service provider (ISP) of the user, and the ISP themselves know which user is linked to which exact IP address, effectively deanonymizing the Monero user.
The mitigation(s)
One possible mitigation for this attack is usage of an overlay network such as Tor or I2P. This makes it so that even if an attacker can deduce a source IP address, it’s probably not the one that made the transaction, but rather the outproxy (I2P) or exit node (Tor) of the overlay network. This is not an all-encompassing solution however, as overlay networks, VPNs, and similar software is banned in many countries, and expecting everyone to use, sync, and propagate on these networks is unrealistic. There needs to be a solution that doesn’t require the usage of external software and networks; one that is available to the common person.
This solution is Dandelion++ (DPP), which is an upgraded protocol to the original Dandelion proposal for Bitcoin. In this protocol, there are two phases, the stem phase, and the fluff phase; both of them together are supposed to represent the form of a dandelion.
In the stem phase, every few minutes, the sending node randomly chooses two peers out of all of the nodes it’s connected to. When the sending node sends a transaction, either on behalf of itself or just forwarding the transaction from another node in the stem phase, it randomly chooses one of these two selected peers and sends the transaction to it.
The fluff phase is when a node receives a transaction and broadcasts it to every outgoing connection, rather than just to one randomly chosen one, this allows true transaction propagation. Every few minutes a node defines itself as one that will either propagate via stem or via fluff at random, so a stem phase can be quite long if each connecting node has defined itself as a stem node, but once the transaction hits the fluff phase, it stays there.
This means that an attacker will not be able to simply listen for the direction of a transaction anymore, because before it was propagated to everyone, it underwent the stem phase, and the originating node of the fluff phase is not the node the transaction originated from, and it is unknown how many hops along the stem the transaction underwent.
Of course, combining the solutions above (DPP plus an overlay network) will give even stronger guarantees of privacy and protection against IP tracing. It should also be noted, that DPP does not defend against another form of network tracing attack that can be done with ISPs, but this is beyond the scope of this article.
Dandelion++ is set to go live on the Monero network, and be used by default on the reference client, in the 0.16 release. This small change will further mitigate the attacks possible on the Monero network, and exemplifies why Monero leads the pack in practical, applied privacy technologies.
This solution is Dandelion++ (DPP), which is an upgraded protocol to the original Dandelion proposal for Bitcoin. In this protocol, there are two phases, the stem phase, and the fluff phase; both of them together are supposed to represent the form of a dandelion.
In the stem phase, every few minutes, the sending node randomly chooses two peers out of all of the nodes it’s connected to. When the sending node sends a transaction, either on behalf of itself or just forwarding the transaction from another node in the stem phase, it randomly chooses one of these two selected peers and sends the transaction to it.
The fluff phase is when a node receives a transaction and broadcasts it to every outgoing connection, rather than just to one randomly chosen one, this allows true transaction propagation. Every few minutes a node defines itself as one that will either propagate via stem or via fluff at random, so a stem phase can be quite long if each connecting node has defined itself as a stem node, but once the transaction hits the fluff phase, it stays there.
This means that an attacker will not be able to simply listen for the direction of a transaction anymore, because before it was propagated to everyone, it underwent the stem phase, and the originating node of the fluff phase is not the node the transaction originated from, and it is unknown how many hops along the stem the transaction underwent.
Of course, combining the solutions above (DPP plus an overlay network) will give even stronger guarantees of privacy and protection against IP tracing. It should also be noted, that DPP does not defend against another form of network tracing attack that can be done with ISPs, but this is beyond the scope of this article.
Dandelion++ is set to go live on the Monero network, and be used by default on the reference client, in the 0.16 release. This small change will further mitigate the attacks possible on the Monero network, and exemplifies why Monero leads the pack in practical, applied privacy technologies.