In part 4, we discussed the importance of using a full node to protect the confidentiality of your transactions. However, it's essential to recognize that your node may also be vulnerable to attacks aimed at extracting information about your activities. In this chapter, therefore, we'll look at the various measures you can take to protect your privacy, not at the level of the transactions themselves or the bitcoin flows, but at the level of the network.

One way to avoid various de-anonymization attacks is to use the Dandelion proposal. This broadcast protocol was formalized in BIP156, but has never been implemented on Bitcoin.

The idea behind Dandelion is to enhance the confidentiality of transaction routing in the Bitcoin network, thereby counteracting various forms of attack. Its main objective is to hide the source node that initially broadcasts a transaction on the network. Disclosure of this node could enable linking a Bitcoin transaction to a specific IP address (if the node operates on the clearnet), providing an entry point for chain analysis.

This association between activity on Bitcoin and an IP address represents a considerable risk to user confidentiality. Indeed, many entities are in a position to easily link an IP address to a personal identity. This includes governments and Internet service providers. Furthermore, this information can become publicly accessible, for example, if your IP address and personal data are leaked when a website's database is compromised.

In classic Bitcoin operation, transactions built by a user on his wallet software are transmitted to his personal node. This node will immediately broadcast the new transaction to all the peers to which it is connected.

These peers then check the transaction to ensure that it complies with consensus and local standardization rules. Once validated, each peer in turn forwards the transaction to their peers, and so on.

This distribution of transactions awaiting integration into a block is fairly balanced and statistically predictable. This weakness can be exploited by accomplices of spy nodes, who collaborate to monitor and analyze the network, in order to identify the first node to have broadcast a transaction. If an observer successfully locates the source node, they can assume that the transaction originated from the node's operator. This type of observation can be used to link normally anonymous transactions to specific IP addresses.

The aim of BIP156 is to address this problem. To achieve this, it introduces an additional phase in the propagation of a new transaction to preserve anonymity before it is widely publicized. Dandelion first uses a "stem" phase where the transaction is sent through a random path of nodes.

The transaction is then broadcast to the entire network during the "Fluff" phase.

The stem and the "Fluff" are references to the behavior of transaction propagation through the network, which resembles the shape and evolution of a dandelion.

Thus, spy nodes can potentially trace the transaction back to the node that initiated the "Fluff" phase (the mass broadcast), but that node is not the one that first broadcast the transaction, as it received it from the last node of the stem. If the spy nodes cannot trace the stem, they also cannot identify the source node.

Even in the presence of spy nodes during the stem phase, a doubt always remains, because as soon as they encounter an honest node in the diffusion graph, the spies can't determine whether this node is the original source or simply an intermediary.

This routing method blurs the trail leading back to the source node, making it difficult to trace a transaction back through the network to its origin. Dandelion thus enhances confidentiality by limiting adversaries' ability to de-anonymize the network. This method is particularly effective when, during the "stemming" phase, the transaction traverses a node that encrypts its network communications, as with Tor or P2P Transport V2.

BIP156 has not been integrated into Bitcoin Core and is currently classified as "rejected". One of the main concerns with this protocol is that, during the stem phase, transactions must be relayed through intermediate nodes before being verified. As we have seen, in the normal Bitcoin model, each node first verifies the transaction before broadcasting it to its peers. If a transaction does not comply with the node's consensus rules or local standardization rules, the node ignores it and does not distribute it. This process is crucial in countering DoS attacks, as only valid transactions are broadcast to the entire network. Invalid transactions, potentially generated in large quantities to overload the network, are stopped at the first node encountered and do not propagate. The main risk with Dandelion is that this new protocol could introduce new vectors for DoS attacks by allowing invalid transactions to be broadcast across part of the network.

P2P transport V2 is another network protocol presented in BIP324. It's a new version of the Bitcoin P2P transport protocol that incorporates opportunistic encryption to improve the confidentiality and security of communications between nodes.

This enhancement is designed to solve several problems with the basic version of the P2P protocol. On the one hand, it makes the data exchanged indistinguishable from other types of data circulating on the Internet for a passive observer. The primary objective is to prevent governments, ISPs, and VPN providers from conducting extensive monitoring of Bitcoin users. This also makes it more difficult for these entities to determine whether an Internet user is also a Bitcoin user, i.e., whether they are running a full node.

P2P V2 also helps reduce the risk of censorship and attacks by detecting specific patterns in data packets. It complicates and increases the cost of executing various types of Sybil attacks at the network level. A Sybil attack occurs when an actor creates multiple false identities in order to gain an unfair advantage. In the context of the Bitcoin network, this often manifests as an actor controlling a large number of full nodes and aggressively utilizing them to establish multiple connections. Sybil attacks can be passive, gathering information and compromising user confidentiality, or active, in the form of Eclipse attacks. The latter isolates a specific node from the rest of the network, either censoring the user or altering the data it receives. Finally, P2P V2 also makes Man-In-The-Middle (MITM) attacks more costly and easier to detect.

The encryption implemented by P2P V2 does not include authentication to avoid adding unnecessary complexity or compromising the network's permissionless feature. Nevertheless, this new P2P transport protocol offers better security against passive attacks and makes active attacks considerably more costly and detectable. The introduction of a pseudo-random data stream in network messages makes it more difficult for attackers to censor or manipulate communications.

P2P V2 transport was included as an optional feature (disabled by default) in Bitcoin Core version 26.0, which was deployed in December 2023. It was then enabled by default in version 27.0 of April 2024. It can be modified with the v2transport= option in the configuration file.

Another simple solution to mitigate the risk of confidentiality loss for a network node is to run it entirely under Tor.

Tor is a network of relay servers (nodes) that anonymizes the origin of TCP connections on the Internet. It works by encapsulating data in several layers of encryption. Each relay node removes a layer to reveal the address of the next node until the final destination is reached. The Tor network ensures anonymity by preventing intermediary nodes from knowing both the origin and destination of data, making it very difficult for an observer to trace a user's activity.

Tor not only encrypts data, but also masks the origin and destination of communications. By using Tor for communications from your personal node, you reinforce the confidentiality of your transactions: your ISP can't decrypt communications, and other nodes in the Bitcoin network can't identify the source node's IP address. What's more, Tor also hides your very use of Bitcoin from your ISP.

The main risk with this method is that Tor is a protocol independent of Bitcoin. If you have a Bitcoin node running under Tor and Tor stops working, then your Bitcoin node will no longer be able to communicate.

Additionally, it's worth noting that communication on Tor is slower. This latency is particularly annoying during the initial launch of a node, as IBD (Initial Block Download) requires a lot of communication. As a result, your initial synchronization with the Bitcoin network could take significantly longer using Tor. It's also possible to perform IBD on the clearnet, then activate Tor as a second step. Although this method discloses the existence of your Bitcoin node to your ISP, it protects your personal transaction information once you switch to Tor.

Having explored the various methods of confidentiality at the network level, I will also introduce you to two elegant solutions for avoiding address reuse in the next few chapters: BIP47 and Silent Payments.