Handshake: Version (“version”)

The version message is a part of the node connection handshake and indicates various connection settings, networking information, and the services provided by the sending node (see Services Bitmask below).

The node connection is not considered established until both nodes have sent and received both a version and verack message.

Message Format

Field Length Format Description
version number 4 bytes unsigned integer(LE) The version number supported by the sending node.
services 8 bytes bitmask(LE) An indication of the services supported by the sending node. See Services Bitmask section below.
timestamp 8 bytes unix timestamp(LE) The time the message was generated on the sending node.
remote address 26 bytes network address The network address of the remote node.

NOTE: this does not contain the timestamp normally included with network addresses.

local address 26 bytes network address The network address of the sending node.

NOTE: this does not contain the timestamp normally included with network addresses.

nonce 8 bytes bytes(LE) Random nonce for the connection, used to detect connections to self.
user agent variable variable length string A user agent string identifying the node implementation.
block height 4 bytes unsigned integer(LE) The height of the block with the highest height known to the sending node.
relay flag 1 byte boolean Indicates whether the sending node would like all broadcasted transactions relayed to it. See BIP-37. This flag is sometimes referred to as "fRelay".

Note: Protocol version 70001 introduced the optional relay flag. Transmitting the relay flag byte to Nodes with a version less than 70001 may result in incompatibility with versions that validate the Version message for a specific byte count.

Note: Historically, transmitting extra data after the relay flag would result in the connection being banned by some Nodes. Modern Nodes ignore extra data after the relay flag.

Version Number

The most recent version of the network protocol is 70015. The version value often correlates to new behavior, parsing formats, and available services; for more details review the network protocol's version history. Nodes should use version and the services bitmask to determine if the node should accept the incoming connection.

Related: node connection handshake.

Services Bitmask

The services field is an 8 byte little-endian-serialized bitfield that described peer capabilities. The following capabilities are defined, by bit position:

Standard Services

Example Serialized Data

Net Magic(BE) E3E1F3E8

Command String ("version")(BE) 76657273696F6E0000000000

Payload Byte Count(LE) 6A000000

Payload Checksum(LE) 8FC7709F

Version Number 7F110100

Node Features 3500000000000000

Timestamp ("1576101548") AC66F15D00000000

Remote Address ("5.6.7.8:8333") 240000000000000000000000000000000000FFFF0506070820

Local Address ("1.2.3.4:8333") 8D350000000000000000000000000000000000FFFF01020304

Nonce 208D00F0E6495B9B

User Agent ("/Bitcoin Node:1.2.3/") 4350142F426974636F696E204E6F64653A312E322E332F

Current Block Height ("612918L") 365A0900

Relay Transactions Flag ("true") 01

Node Specific Messages

Bitcoin ABC

Bitcoin Unlimited

Bitcoin Verde

Other Proposed/Previously Used Service Flags

Node-Specific Behavior

Generally, though node implementations may be aware of services they do not provide, they generally ignore those they don't supported. Any notable deviations from that behavior are documented below.

Bitcoin ABC

Bitcoin ABC nodes may, once they have reached their maximum number of peers, selectively disconnect from nodes that do not supported "desired services", though it appears currently this just NODE_NETWORK and/or NODE_NETWORK_LIMITED. That is, it may prefer nodes that store and serve blocks.

Bitcoin Verde

Bitcoin Verde nodes ignore any data after the relay flag field.