How BIP324 improves Bitcoin’s privacy

KAX1107

One of the biggest challenges of the Bitcoin network is having a low latency, highly secure and private way of exchanging messages between peers. The censorship resistance requirement of the system is determined by the ability to propagate messages without risk of interception by third parties like ISPs. Implementing solutions that enhance privacy among network participants is one way of ensuring that the censorship resistance requirement is satisfied.

In this post, we dive into the need for bitcoin’s transport protocol to encrypt messages exchanged between peers. Since all data relayed in the Bitcoin P2P network is inherently public, and the protocol lacks a notion of cryptographic identities, peers talk to each other over unencrypted and unauthenticated connections. This is a risk to the Bitcoin network’s security in the presence of attackers.

Side Note: This article assumes basic knowledge of programming and how the Bitcoin protocol works

The Bitcoin P2P network serves 3 purposes

Gossiping addresses of know reachable nodes on the network Relaying unconfirmed transactions Propagating blocks to keep the network synchronized with the most up-to-date valid tip of the blockchain

Bitcoin’s Privacy Problem

First, let’s examine the current state of the Bitcoin network

Connections to peers are unauthenticated, and they can be tampered with at a low cost often even with a low risk of detection. For example, an attacker can alter specific bytes of a connection (such as node flags) on-the-fly without the need to keep any state. The data relayed across the network is public in nature. Because of this, the associated metadata may reveal private information and hamper privacy of users. For example, a global passive attacker eavesdropping on all Bitcoin P2P connections can trivially identify the source and timing of a transaction. The protocol is self-revealing. For example, deep packet inspection can identify a P2P connection trivially because connections start with a fixed sequence of magic bytes. The ability to detect connections enables censorship and facilitates the aforementioned attacks as well as other attacks which require the attacker to control the connections of victims, e.g., eclipse attacks targeted at miners.

How BIP 324 (almost) solves the privacy problem

What we want for the network is:

Encryption of data relayed between peers on the network Make tampering with data by intermediaries costlier Disguise Bitcoin peer-to-peer traffic with that of other protocols to make traffic analysis harder

Encryption, even when it is unauthenticated, impedes eavesdropping by forcing the attacker to become active: either by performing a persistent man-in-the-middle attack, or by spinning up their own nodes and getting honest nodes to make connections to them.

Active attacks at scale are more resource intensive in general, but in case of manual, deliberate connections (as opposed to automatic, random ones) they are also in principle detectable: even very basic checks, e.g., operators manually comparing protocol versions and session IDs (as supported by the proposed protocol), will expose the attacker.

Tampering, while already an inherently active attack, is costlier if the attacker is forced to maintain the state necessary for a full man-in-the-middle interception. A pseudorandom byte-stream excludes identification techniques based on pattern matching, and makes it easier to shape the byte-stream in order to mimic other protocols used on the Internet. This raises the cost of a connection censoring firewall, forcing them to either resort to a full man-in-the-middle attack, or operate on a more obvious whitelist basis, rather than a blacklist basis.

Note: BIP324 changes how a traffic is propagated from node to node. It is not changing anything about what is in that traffic, does not affect consensus rules and hence won’t require a fork of any kind. It is kind of like switching from HTTP to HTTPS, there is enhanced security when accessing the website but website content is still the same.

Exploring the Bitcoin Peer-to-Peer transport protocol from first principles

Say we have two Bitcoin enthusiasts, Alice and Bob. Bob has searched the internet for all material related to BIP 324 and knows about the proposal in and out. Alice is quite technical on Bitcoin subjects, but has just heard about BIP 324, and is curious to learn more about it.

Alice: Ok, so the gist of this BIP is opportunistic encryption of messages transported across the Bitcoin network, correct?

Bob: Yes.

Alice: Why encryption without authentication?

Bob: As the saying goes, half a loaf is better than no bread. Unauthenticated encryption provides better security than no encryption. It is better for all connections to use encryption, even if they are unauthenticated. Imagine a spy sneaked into a cocktail party uninvited. If the invited guests communicate in a language only invited guests understand, the spy won’t have any luck collecting information.

Due to Bitcoin’s permission-less nature, authentication will always be restricted to specific scenarios (e.g., connections between peers belonging to the same operator), and whether some form of (possibly partially anonymous) authentication is desired depends on the specific requirements of the involved peers. Therefore, BIP 324 proposes that authentication should be addressed separately (if desired). The proposal aims to provide a solid technical basis for future protocol upgrades, including the addition of optional authentication.

Alice: But isn’t this kind of encryption possible with VPN networks ,for example?

Bob: While that may be the case, these networks are not desirable or applicable for automatic connections at scale, for a few reasons:

Proxy networks like Tor or I2P introduce a separate address space, independent from network topology, with a very low cost per address making eclipse attacks cheaper. Tor connections come with significant bandwidth and latency costs that may not be desirable for all network users. VPN networks like WireGuard or OpenVPN inherently define a private network, which requires manual configuration and therefore is not suitable for automatic connections.

We need a solution that has minimal costs, works without configuration, and is always enabled — on top of any network layer rather than be part of the network layer.

Given the decentralized nature of the Bitcoin protocol, it is important to keep it as simple and highly customizable to individual node needs as possible. These constraints make general purpose encryption protocols an unsuitable choice.

The treatment of encryption and authentication by existing protocols not sufficiently modular. The form of authentication desired in the bitcoin p2p network depends on the specific requirements of the involved peers (resulting in a mix of authenticated and unauthenticated connections).

Alice: Ok, so BIP 324 aims for a simple modular design that makes it possible to address encryption and authentication separately. What takes precedence, encryption or authentication?

Bob: Any authentication needs to run after an encrypted connection has been established, so encryption is done first. The price paid for this modularity is a possibly higher number of round-trips as opposed to other protocols that perform authentication alongside with the Diffie-Hellman key exchange. However, the resulting increase in connection establishment latency is a not a concern for Bitcoin’s long-lived connections, which typically live for hours or even weeks.

The proposal provides a foundation for authentication by exporting a ‘‘session ID’’ that uniquely identifies the encrypted channel. After an encrypted channel has been established, the two endpoints are able to use any authentication protocol to confirm that they have the same session ID.

Alice: What other downsides are there for current general purpose off-shelf-solutions to this encrypted transport problem?

Bob: Let’s say we decide to apply TLS for our desired use case, we may run into further technical issues because:

It doesn’t offer a pseudorandom byte-stream. It doesn’t offer native support for elliptic curve cryptography on the curve secp256k1 as otherwise used in Bitcoin. While using secp256k1 is not strictly necessary, it is the obvious choice is for any new asymmetric cryptography in Bitcoin because it minimizes the cryptographic hardness assumptions as well as the dependencies that Bitcoin software will need. It doesn’t offer shapability of the byte-stream. It provides a stream-based interface to the application layer whereas Bitcoin requires a packet-based interface, resulting in the need for an additional thin layer to perform packet serialization and de-serialization.

Alice: Can’t we amend TLS to address the above technical issues?

Bob: That would negate the benefits of using it as an off-the-shelf solution, e.g., the possibility to re-use existing implementations and security analyses.

Alice: Why have a pseudorandom byte-stream when traffic analysis is still possible?

Bob: A pseudorandom byte stream raises the cost of fingerprinting the protocol substantially, and may force some intermediaries to attack any protocol they cannot identify, causing collateral cost. A pseudorandom byte stream is not self-identifying. Moreover, it is unopinionated and thus a canonical choice for similar protocols. As a result, Bitcoin P2P traffic will be indistinguishable from traffic of other protocols which make the same choice e.g., obfs4 and a recently proposed cTLS extension.

Alice: Why not use a secure tunnel protocol?

Bob: The goal of the BIP includes making opportunistic encryption ubiquitously available, as that provides the best defense against large-scale attacks. That implies protecting both the manual, deliberate connections node operators instruct their software to make, as well as the the automatic connections Bitcoin nodes make with each other based on IP addresses obtained via gossip.

Alice: That was a lot to take in Bob. How about summarizing the goals of this proposal?

Bob: This proposal aims to achieve the following properties:

Confidentiality against passive attacks: A passive attacker having recorded a v2 P2P byte-stream (without timing and fragmentation information) must not be able to determine the plaintext being exchanged by the nodes. Observability of active attacks: A session ID identifying the encrypted channel uniquely is derived deterministically from a Diffie-Hellman negotiation. An active man-in-the-middle attacker is forced to incur a risk of being detected as peer operators can compare session IDs manually, or using optional authentication methods possibly introduced in future protocol versions. Pseudorandom byte-stream: A passive attacker having recorded a v2 P2P byte-stream (without timing information and fragmentation information) must not be able to distinguish it from a uniformly random byte-stream. Shapable byte-stream: It should be possible to shape the byte-stream to increase resistance to traffic analysis (for example, to conceal block propagation), or censorship avoidance. Forward secrecy: An eavesdropping attacker who compromises a peer’s sessions secrets should not be able to decrypt past session traffic, except for the latest few packets. Upgradability: The proposal provides an upgrade path using transport versioning which can be used to add features like authentication, PQC handshake upgrade, etc. in the future. Compatibility: v2 clients will allow inbound v1 connections to minimize risk of network partitions. Low overhead: the introduction of a new P2P transport protocol should not substantially increase computational cost or bandwidth for nodes that implement it, compared to the current protocol.

Alice: Got it. How can I take part in helping with getting the BIP implemented?

Bob: You can help out in a variety of ways including:

Conclusion

It is quite interesting that to date, Bitcoin traffic has always been trivially distinguishable from other forms of internet traffic. In addition to encryption, BIP324 lays the necessary groundwork for addition of optional authentication. The Chinese say a journey of a thousand miles begins with one step, and as far as privacy and security on the Bitcoin network is concerned, BIP 324 is a necessary first step.

Even when this BIP is implemented and activated in Bitcoin Core, privacy on Bitcoin is always a moving target. BIP324 does not remove the possibility of attacks on the network. It just makes the costlier and riskier from an attacker’s perspective.