-
Notifications
You must be signed in to change notification settings - Fork 58
Protocol Versioning
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 dating to the creation of the Bitcoin Improvement Proposal (BIP) system by Amir Taaki in 2011.
- Protocol Version and User Agent
- Created: 2011-11-10
- Status: deployed
- Negotiation: N/A
- Behavior: Interpretation of an unused version field (compatible).
The currently unused sub_version_num field in "version" packets will become the new user-agent string.
- 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.
- 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).
- Connection Bloom filtering
- Created: 2012-10-24
- Status: deployed
- Negotiation: version >= 70001
- Behavior: Versioned protocol change, but broken (incompatible, 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.
- 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.
- 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.
- 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.
- NODE_BLOOM service bit
- Created: 2015-08-20
- Status: deployed
- Negotiation: version >= [undocumented], service bit NODE_BLOOM
- Behavior: Versioned protocol change, and service bit (compatible).
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.
- 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.
- Peer Authentication
- Peer-to-Peer Communication Encryption
- Created: 2016-03-23
- Status: withdrawn
- Negotiation: assumes older peers ignore invalid messages during handshake
- Behavior: Unversioned protocol change (not compatible, but withdrawn).
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.
- 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.
- Client Side Block Filtering
- Compact Block Filters for Light Clients
- Created: 2017-05-24
- Status: deployed
- Negotiation: service bit NODE_COMPACT_FILTERS
- Behavior: Signaled protocol change (compatible).
NODE_COMPACT_FILTERS = (1 << 6): If enabled, the node MUST respond to all BIP 157 messages for filter type 0x00.
- Version 2 Peer-to-Peer Message Transport Protocol
- Created: 2019-03-08
- Status: proposed
- Negotiation: service bit NODE_P2P_V2
- Behavior: Signaled protocol change (compatible).
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.
- Transaction announcements reconciliation
- Created: 2019-09-25
- Status: proposed
- Negotiation: assumes older peer ignores invalid messages
- Behavior: Unversioned protocol change (not compatible, but not merged).
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.
- addrv2 message
- Created: 2019-02-27
- Status: deployed
- Negotiation: version flags: 0x20000000 and 0x40000000
- Behavior: Versioned protocol change (compatible).
The sendaddrv2 message MUST only be sent in response to the version message from a peer and prior to sending the verack message.
This implements an undocumented change to all preceding behavior of the version field, treating the version as bit flags vs. a monotonically-increasing sequence:
/**
* A flag that is ORed into the protocol version to designate that addresses
* should be serialized in (unserialized from) v2 format (BIP155).
* Make sure that this does not collide with any of the values in `version.h`
* or with `SERIALIZE_TRANSACTION_NO_WITNESS`.
*/
static const int ADDRV2_FORMAT = 0x20000000;
/**
* A flag that is ORed into the protocol version to designate that a transaction
* should be (un)serialized without witness data.
* Make sure that this does not collide with any of the values in `version.h`
* or with `ADDRV2_FORMAT`.
*/
static const int SERIALIZE_TRANSACTION_NO_WITNESS = 0x40000000;
// Add ADDRV2_FORMAT to the version so that the CNetAddr
// serialize method produces an address in v2 format.
s.SetVersion(s.GetVersion() | ADDRV2_FORMAT);
// Add ADDRV2_FORMAT to the version so that the CNetAddr
// unserialize method expects an address in v2 format.
s.SetVersion(s.GetVersion() | ADDRV2_FORMAT);
- 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.
- Disable transaction relay message
- Created: 2020-09-03
- Status: deployed
- Negotiation: version >= 70017
- Behavior: Versioned protocol change (compatible).
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).
- 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.
Users | Developers | License | Copyright © 2011-2024 libbitcoin developers