Published on: 2019-03-25T06:32:58+00:00
On 22nd March 2019, Jonas Schnelli proposed a new Bitcoin peer-to-peer transport protocol with opportunistic encryption via the bitcoin-dev mailing list. The current unencrypted message transport is inefficient and vulnerable to various attacks. This proposal aims to address these issues by introducing opportunistic encryption. The key idea is that encrypting public data between anonymous peers is pointless, so the proposal focuses on identifying data manipulation by communicating peers.The proposal acknowledges that encrypting traffic between peers is already possible with existing encryption mechanisms, but those solutions are not widely deployed due to the complexity of setting up a secure channel. The proposed protocol aims to make encryption more accessible by providing an easy-to-use solution.The proposal includes specific requirements for peers supporting the new message transport protocol. Peers must accept encryption requests from all peers and signal NODE_P2P_V2. Peers supporting NODE_P2P_V2 must accept encrypted communication as specified in the proposal. It is assumed that the two peers using this protocol know and trust each other and have the ability to communicate over a secure side channel.In a discussion on the bitcoin-dev mailing list, Dave raised a question about the optional nature of short command IDs in the v2 message format. He suggested having a fixed-length field for all message types instead of dealing with variable size and mapping negotiation. Jonas argued that short IDs can help avoid collisions in the future, especially for high-frequency messages. He also mentioned that there are only 26 different message types currently, so short IDs may not be necessary for all of them. He proposed that short IDs can be altered with the message protocol version, and adding them should be straightforward. However, he noted that some commands may not benefit significantly from short IDs, as there are only 244 available.In another discussion, David A. Harding questioned why short IDs were optional and specified only for certain message types. Gregory Maxwell explained that allocating short IDs to existing messages is easy, but adding new protocol messages would require coordination with all developers working on protocol extensions. This could lead to disagreements and delays. Allowing nodes to use arbitrary command names eliminates this issue and saves bandwidth through optional negotiation. Harding found this reasoning reasonable after understanding the motivation behind it.The discussion also covered the structure of v2 messages, including field size, description, data type, and comments for each message. The command field must start with a byte that defines the length of the ASCII command string or a short command ID. Short command IDs are supported for high-frequency message types but are optional and can be negotiated between peers. The list of all net message types in the src/protocol.cpp file was shared.The proposed Version 2 Peer-to-Peer Message Transport Protocol aims to provide a more efficient and secure communication method for Bitcoin. It addresses vulnerabilities in the current unencrypted message transport and introduces opportunistic encryption to detect data manipulation by communicating peers. The protocol requires an optimized AEAD construct, a NODE_P2P_V2 signal, a 32-byte "pseudorandom" key exchange, removal of the multi-message envelope, and the use of a 3-byte integer to determine packet length. Short-command-IDs are introduced for high-frequency message types, but their usage is optional and may be negotiated between peers. The proposal also outlines the key derivation process, symmetric encryption cipher keys, and the encryption scheme used (ChaCha20-Poly1305).Overall, the proposal aims to enhance the security and efficiency of the Bitcoin peer-to-peer network by introducing opportunistic encryption and addressing vulnerabilities in the current message transport. It provides detailed specifications for peers supporting the new protocol and discusses the optional nature of short command IDs. The proposal is backward compatible, allowing non-supporting peers to continue using unencrypted communications.
Updated on: 2023-08-02T00:40:05.191007+00:00