version

The version message provides information about the transmitting node to the receiving node at the beginning of a connection. Until both peers have exchanged “version” messages, no other messages will be accepted.

If a “version” message is accepted, the receiving node should send a “verack” message—but no node should send a “verack” message before initializing its half of the connection by first sending a “version” message.

Name

Data Type

Bytes

Required/Optional

Description

version

int32

4

Required

The highest protocol version understood by the transmitting node. See the protocol version section.

services

uint64

8

Required

The services supported by the transmitting node encoded as a bitfield. See the list of service codes below.

timestamp

int64

8

Required

The current Unix epoch time according to the transmitting node’s clock. Because nodes will reject blocks with timestamps more than two hours in the future, this field can help other nodes to determine that their clock is wrong.

addr_recv

Address

26

Required

Address of receiving node including the services supported by the receiving node as perceived by the transmitting node.

addr_trans

Address

26

Required

Address of transmitting node including the services supported by the transmitting node. The services in the address should be identical to the services field above.

nonce

uint64

8

Required

A random nonce which can help a node detect a connection to itself. If the nonce is 0, the nonce field is ignored. If the nonce is anything else, a node should terminate the connection on receipt of a “version” message with a nonce it previously sent.

user_agent

string

Varies

Required

User agent as defined by BIP-14. If it is an empty string no user agent field is sent.

start_height

int32

4

Required

The height of the transmitting node’s best block chain or, in the case of an SPV client, best block header chain.

relay

bool

1

Optional

Transaction relay flag. If 0x00, no “inv” messages or “tx” messages announcing new transactions should be sent to this client until it sends a “filterload” message or “filterclear” message. If the relay field is not present or is set to 0x01, this node wants “inv” messages and “tx” messages announcing new transactions.

The following service identifiers have been assigned. Each service is represented by one bit in the field. Bits can be ORed together to represent a node capable of multiple services.

Value

Name

Description

0x00

Unnamed

This node is not a full node. It may not be able to provide any data except for the transactions it originates.

0x01

NODE_NETWORK

(Bit 0) This is a full node and can be asked for full blocks. It should implement all protocol features available in its self-reported protocol version.

0x02

NODE_GETUTXO

(Bit 1) The node is capable of responding to the getutxo protocol request. unit-e does not support this. See BIP-64 for details on how this is implemented.

0x04

NODE_BLOOM

(Bit 2) The node is capable and willing to handle bloom-filtered connections.

0x08

NODE_WITNESS

(Bit 3) The node can be asked for blocks and transactions including witness data.

0x10

NODE_XTHIN

(Bit 4) The node supports Xtreme Thinblocks. If this is turned off then the node will not service nor make xthin requests.

0x400

NODE_NETWORK_LIMITED

(Bit 10) NODE_NETWORK_LIMITED means the same as NODE_NETWORK with the limitation of only serving the last 288 (2 day) blocks. See BIP-159 for details on how this is implemented.

0x8000

NODE_SNAPSHOT

(Bit 15) The node generates periodically snapshots and is capable of responding to the getsnapshot protocol request. See UIP-11 for details.

Bits 24-31 are reserved for temporary experiments. Just pick a bit that isn’t getting used, or one not being used much, and notify the Unit-e community. Remember that service bits are just unauthenticated advertisements, so your code must be robust against collisions and other cases where nodes may be advertising a service they do not actually support. Other service bits should be allocated via the UIP process.

The following annotated hexdump shows a “version” message. (The message header has been omitted and the actual IP addresses have been replaced with RFC5737 reserved IP addresses.)

72110100 ........................... Protocol version: 70002
0100000000000000 ................... Services: NODE_NETWORK
bc8f5e5400000000 ................... [Epoch time][unix epoch time]: 1415483324

0100000000000000 ................... Receiving node's services
00000000000000000000ffffc61b6409 ... Receiving node's IPv6 address
208d ............................... Receiving node's port number

0100000000000000 ................... Transmitting node's services
00000000000000000000ffffcb0071c0 ... Transmitting node's IPv6 address
208d ............................... Transmitting node's port number

128035cbc97953f8 ................... Nonce

11 ................................. Bytes in user agent string: 0x11 (17)
2f46657565726c616e643a302e312e302f.. User agent: /Feuerland:0.1.0/

cf050500 ........................... Start height: 0x505cf (329167)
01 ................................. Relay flag: true