BIPs can be confusing and sometimes hard to keep up with, especially if you are just getting started. This review series aims to summarize and provide a brief overview of the general ideas in a beginner-friendly way. So read along :)
Bitcoin improvement proposals(BIPS)
A Bitcoin improvement proposal is a document design that allows members of the Bitcoin community to propose changes to bitcoin core. The changes include but are not limited to protocol standards, informational updates, and process improvements affecting the wider Bitcoin network. The review process is usually lengthy and ultimately the community gets to decide what BIP makes it to the development process. The time between when a proposal is made and when it's approved for development takes time as this is more of a community effort than an individual making a decision.
Now that we have an idea of what a BIP is before diving into BIP324 we first have to understand the history of P2P transport in bitcoin.
P2P Transaport Version 1
After the initial handshake takes place, for a node to continue to be part of the network it has to stay connected to other nodes and continue to exchange information. Node discovery is a never-ending process and the gossiping process that occurs is because at any given time a node is continuing to establish new connections and forming paths within the network.
Through gossiping, the network remains synchronized at all times, regardless of whether a node joins for the first time or drops off from the network.
Let's briefly explore two messages that nodes send each other:
A node podcasts it's addrmessage to the network so that it can connect to other nodes. This field is a combination of the node's IP address and the host(default value 8333) that the node is running on, for example:
"86.200.199.49:8333"
addrv2 was introduced as an improvement for addr message, to support addresses longer than 16 bytes [source] unlike IPV4 and ipv6 addresses, I2P addresses, are dynamic in nature and can be longer or shorter than 16 bytes.
Nodes can also send a “getaddr” message this is the more direct message and it's basically a node requesting other nodes on the network to share their IP addresses for information exchange. The key difference is that for getaddr message the receiving node will send a response that will include the addr message
Possible attacks
Currently, the Bitcoin P2P network can be comprised in the following ways.
Man in the middle attack (MITM)
This is a type of Network eavesdropping attack where the attacker is able to intercept communication between two parties. The attacker can read, modify, and send messages to both parties.
Attackers use tools such as packet sniffers to monitor connections in the network. Once an insecure connection is found, the attacker can capture data packets between two parties. This guide provides an in-depth tutorial on how to create a sniffer in Python.
Denial-of-Service (DoS) Attack
This is an attack that overwhelms a server by sending it excessive traffic or traffic that can crash the server. The aim of a DoS attack is to cause the unavailability of a service. Computers are susceptible to this attack because of temporary memory called a buffer, which is usually used to enhance performance. However, an attacker could overload your computer's buffer, creating a memory overflow and resulting in a crash. It is important to note that certain programming languages are more prone to buffer attacks than others. You can read more about buffer attacks [here].
what is BIP324
This proposal aims to mitigate the occurrence of the attacks mentioned above by increasing the cost and time it would take for an attacker to perform them. This is to be achieved through data encryption.
BIP324 introduces an encryption mechanism for node communication. It leverages Pseudorandom Bytestream, meaning that if an attacker attempts to eavesdrop, the information will appear entirely random. Nodes communicating with each other do not have to be authenticated; however, both parties must activate BIP324, otherwise, they will not understand each other's encrypted messages. While this doesn't make eavesdropping entirely impossible, it does make it harder. The proposal also highlights the difficulties that fake nodes will face in joining and staying connected to the network, as well as exchanging information. This is because of the introduction of checks such as session IDs that other nodes will use to identify whether a node is fake or not.
Sometimes firewalls can be used to block a connection because of the randomness of byte stream data. This randomness makes it extremely difficult for an attacker to decipher the encrypted messages between nodes, requiring a significant amount of effort and resources. Eventually, they might resort to launching a full-blown man-in-the-middle attack, which would also requires a lot of resources.
BIP324 does not introduce an authentication mechanism this is due to the nature of Bitcoin being open and trustless.
Session IDS
The main purpose of a session ID in BIP324 is for honest nodes to detect attackers by comparing IDs. If two connecting nodes match their session IDs the assumption is that the connection is from an honest node. This is made possible by the use of the Diffie-Hellman exchange algorithm.
Imagine Alice and Bob. They don't know each other, but they want to share a secret using a channel that may be insecure. Derrick is sneaky and dishonest and is trying to intercept the chat between Alice and Bob. This is where the Diffie-Hellman(DH) negotiation exchange algorithm comes in. DH allows for the two parties to construct a secret key together without knowing each other using a common value. let's follow these steps:
Alice has a secret value of k and Bob has a value of X. These values can be used to construct a common secret value Q which Bob and Alice will use to identify each other.
Value X and K are then used to construct a value Q.
Bob wants to connect to Alice by sending them value Q over a public insecure channel. remember Bob doesn't want anyone to know that they are trying to connect to Alice and what information they are sending each.
When Alice receives the Key Q from Bob they can check if they can derive q from their value of X if yes, the value Q is legit.
This shared secret Q derived from DH is used to create a session ID that both Alice and Bob can compare to identify each other and potentially detect an attacker.
Derrick cannot decrypt the communication between Alice and Bob because DH doesn't provide a decryption key.
Session IDs have already been implemented and can be tested on Bitcoin Core version 27(https://github.com/bitcoin-core/bitcoin-devwiki/wiki/27.0-Release-Candidate-Testing-Guide#v2-transport-on-by-default)
After setting up version 27 and connecting to a peer, using RPC bitcoin-cli getpeerinfo the sample output as seen below will have a session ID unlike version 1:
Version 2
"connection_type": "outbound-full-relay",
"transport_protocol_type": "v2",
"session_id": "b8739386b90b8dd7216152f2ad6b044535ceef7970cbe426e6756a404ebc214e"
Version 1
"connection_type": "outbound-full-relay",
"transport_protocol_type": "v1",
"session_id": ""
Conclusion
BIP324 is an interesting BIP. We explored how BIP324 leverages Diffie-Hellman negotiation to establish secure communication channels. However, note that this is not the only component of BIP324. For details on all the components, check out [link]. If you want to learn more about the technical details of BIP324 and keep track of the development process, visit [link]