Skip to content

Protocol Versioning

Jump to bottom
Eric Voskuil edited this page Oct 5, 2022 · 33 revisions

Background

Network communication uses protocol versioning to enable backward compatible protocol changes. Backward compatibility is the assurance that older implementations will continue to operate (indefinitely) as these changes occur. This investigation reviews all documented (and some undocumented) protocol changes, which have not been withdrawn or rejected, dating to the creation of the Bitcoin Improvement Proposal (BIP) system by Amir Taaki in 2011.

History of Protocol Changes

BIP 014

The currently unused sub_version_num field in "version" packets will become the new user-agent string.

BIP 031

  • Pong message
  • Created: 2012-04-11
  • Status: deployed
  • Negotiation: version >= 60001
  • Behavior: Versioned protocol change (compatible).

Clients must opt-in to the new feature by advertising a protocol version > 60000. Clients with older protocol versions are not expected to provide a nonce in the ping message and will not be sent a pong.

BIP 035

  • mempool message
  • Created: 2012-08-16
  • Status: deployed
  • Negotiation: version >= 60002
  • Behavior: Versioned protocol change (compatible).

Feature discovery is enabled by checking two "version" message attributes: Protocol version >= 60002, NODE_NETWORK bit set in nServices

A later undocumented change concurrent with the deployment of BIP61 allowed multiple INV messages in response (version >=70002).

BIP 037

  • Connection Bloom filtering
  • Created: 2012-10-24
  • Status: deployed
  • Negotiation: version >= 70001
  • Behavior: Versioned protocol change, but broken (not compatible, see BIP60 post mortem)

"If missing or true [version.relay field], no change in protocol behaviour occurs."

The negotiated version was implemented but not documented until BIP60. The design assumes peers above version 70001 provide filters, which was later modified by BIP111.

BIP 060

  • Fixed Length "version" Message
  • Created: 2013-06-16
  • Status: version message length still varies due to old implementations
  • Negotiation: N/A
  • Behavior: N/A (clarification of expected behavior).

The implementation is problematic because the [version.relay field] is an optional part of the version message stream.

When a node creates an outgoing connection, it will immediately advertise its version. The remote node will respond with its version. No futher [sic] communication is possible until both peers have exchanged their version.

This is a post mortem on BIP37, clarifying handshake immutability.

BIP 064

  • getutxo message
  • Created: 2014-06-10
  • Status: obsolete
  • Negotiation: version >= 70004, service bit NODE_GETUTXO
  • Behavior: Versioned protocol change, and service bit (compatible).

Nodes indicate support by advertising a protocol version above 70003 and by setting a new NODE_GETUTXO flag in their nServices field.

BIP 061

  • Reject P2P message
  • Created: 2014-06-18
  • Status: deployed, deprecated
  • Negotiation: version >= 70002
  • Behavior: Versioned protocol change (compatible).

All implementations of the P2P protocol version 70002 and later should support the reject message.

This has been deprecated by various implementations (undocumented, though support is not required). An undocumented change deployed under the same version (70002) allows multiple "inv" messages in response to the mempool message.

BIP 130

  • sendheaders message
  • Created: 2015-05-08
  • Status: deployed
  • Negotiation: version >= 70012
  • Behavior: Versioned protocol change (compatible).

Feature discovery is enabled by checking protocol version >= 70012.

BIP 111

  • NODE_BLOOM service bit
  • Created: 2015-08-20
  • Status: deployed
  • Negotiation: version >= 70011, service bit NODE_BLOOM
  • Behavior: Versioned protocol removal, and service bit (incompatible).

This BIP extends BIP 37, Connection Bloom filtering, by defining a service bit to allow peers to advertise that they support bloom filters explicitly.

It also bumps the protocol version to allow peers to identify old nodes which allow bloom filtering of the connection despite lacking the new service bit.

the protocol version is increased from 70002 to 70011

The change is not compatible with nodes at/above version 70001 and below version 70011.

BIP 133

  • feefilter message
  • Created: 2016-02-13
  • Status: deployed
  • Negotiation: version >= 70013
  • Behavior: Versioned protocol change (compatible).

Feature discovery is enabled by checking protocol version >= 70013.

BIP 150/151

Encryption initialization must happen before sending any other messages to the responding peer (encinit message after a version message must be ignored).

See draft BIP324 for superseding protocol proposal.

BIP 152

  • Compact Block Relay
  • Created: 2016-04-27
  • Status: deployed
  • Negotiation: version >= 70014
  • Behavior: Versioned protocol change (compatible, if node does what it "SHOULD").

Nodes SHOULD check for a protocol version of >= 70014 before sending sendcmpct messages.

BIP 159

  • NODE_NETWORK_LIMITED service bit
  • Created: 2017-05-11
  • Status: deployed
  • Negotiation: service bit NODE_NETWORK_LIMITED
  • Behavior: Signaled protocol change (compatible).

NODE_NETWORK_LIMITED = (1 << 10): If signaled, the peer MUST be capable of serving at least the last 288 blocks (~2 days).

BIP 157/158

NODE_COMPACT_FILTERS = (1 << 6): If enabled, the node MUST respond to all BIP 157 messages for filter type 0x00.

BIP 324

The encryption handshake MUST happen before any other messages are exchanged between the peers.

Peers supporting the transport protocol proposed here MUST signal the NODE_P2P_V2 = (1 << 11) service flag.

A peer usually learns an address along with the expected service flags which MAY be used to filter possible outbound peers.

Peers MAY make outbound connections exclusively to peers supporting NODE_P2P_V2.

This is a successor to BIP150/151, which were withdrawn.

BIP 330

The sendrecon message announces support for the reconciliation protocol. It is expected to be only sent once, and ignored by nodes that don't support it.

BIP 155

  • addrv2 message
  • Created: 2019-02-27
  • Status: deployed
  • Negotiation: assumes older peer ignores invalid messages
  • Behavior: Unversioned protocol change (not compatible).

The sendaddrv2 message MUST only be sent in response to the version message from a peer and prior to sending the verack message.

BIP 339

  • WTXID-based transaction relay
  • Created: 2020-02-03
  • Status: deployed
  • Negotiation: version >= 70016
  • Behavior: Versioned protocol change (compatible).

The protocol version of nodes implementing this BIP must be set to 70016 or higher. The wtxidrelay message MUST be sent in response to a version message from a peer whose protocol version is >= 70016 and prior to sending a verack.

BIP 338

The protocol version of nodes implementing this BIP must be set to 70017 or higher.

If a node sets the transaction relay field in the version message to a peer to false, then the disabletx message MAY also be sent in response to a version message from that peer if the peer's protocol version is >= 70017. If sent, the disabletx message MUST be sent prior to sending a verack.

Nodes with protocol version >= 70017 that do not implement this BIP, and nodes with protocol version < 70017, will continue to remain compatible with implementing software: transactions would not be relayed to peers sending the disabletx message (provided that BIP 37 or BIP 60 has been implemented).

BIP ???

  • Generic Package Relay
  • Created: 2022-04-14
  • Status: proposed
  • Negotiation: assumes older peers ignore invalid messages during handshake
  • Behavior: Unversioned protocol change (not compatible, but not deployed).

Package relay is negotiated between two peers during the version handshake. Package relay requires both peers to support wtxid-based relay [version >= 70016] because package transactions are referenced by their wtxid.

During version handshake, nodes should send a "sendpackages" message indicate they support package relay and may request packages.

Protocol Negotiation

There are three distinct techniques in the above designs.

Negotiated Version

The handshake consists of the initial send of the version message followed by the verack message. Once a peer has sent its version and received a acknowledgement it may start communicating at the negotiated level. There are two distinct treatments of the version value above:

  1. Claim a version increment.
  2. Claim an unused bit of the version as a flag.

The version is symmetric. Both ends must support the negotiated protocol. Therefore the negotiated protocol is the intersection of each of these two version treatments.

Advertised service

The services advertised by a peer through address relay and/or the handshake. Services exist because of asymmetry. One end may provide a service that the other may not provide, independent of the negotiated version.

  • NODE_NETWORK : Independent of network protocol level.
  • NODE_COMPACT_FILTERS : Independent of network protocol level.
  • NODE_BLOOM : Requires version >= 70001 (deployed, deprecated).
  • NODE_UTXO : Requires version >= 70004 (obsolete).
  • NODE_WITNESS : Independent of network protocol level.
  • NODE_NETWORK_LIMITED : Independent of network protocol level.
  • NODE_P2P_V2 : Independent of network protocol level.

Unversioned

In this case a peer simply sends a message of a type that the other is unaware of. Any message must be allowed, making it impossible to enforce message type, size, or content constraints. There are two approaches to unversioned protocol above:

  1. Require an unknown message be accepted at any time.
  2. Require an unknown message be accepted within the handshake.

Recipient behavior may be either relaxed (ignore the message) or strict (drop the peer for protocol noncompliance). Both approaches exist in deployed implementations. These are protocol compatibility breaks.

If the protocol MUST allow for arbitrary messaging, there is no need for a handshake. Each protocol can simply negotiate for itself (precisely the approach proposed by Generic Package Relay and BIP330 above), either within the handshake, or at any time (respectively).

TODO

Users | Developers | License | Copyright © 2011-2024 libbitcoin developers

P2P Network Menu

Clone this wiki locally