DEP 0001: Version Message Info
status: accepted
Motivation
Currently version
messages are empty, but before releasing in order
to anticipate protocol upgrades, we should include the protocol
version. This is for the moment inside verack
, but should be moved to
version
since it allows immediately dropping the connection if the
protocol version is incorrect (and indeed is the main purpose of the
version message).
Additionally it should include further info which makes debugging connections and negotiation easier.
Proposal
Type | Description | Comment |
---|---|---|
u32 | version | Identifies protocol version being used by the node |
u64 | timestamp | UNIX timestamp |
u16 | nonce | Random nonce, randomly generated everytime a version packet is sent. This nonce is used to detect connections to self. |
Url | connect_recv_addr | Network address of the node receiving this message (before resolving) |
Option<Url> | resolv_recv_addr | Network address of the node receiving this message (after resolving) |
Vec<String> | ext_send_addr | (Optional) External address of the node sending this message |
Vec<(String, u32)> | (services, version) | List of features to be enabled for this connection |
resolv_recv_addr
is optional as inbound connections do not have such
an address.
ext_send_addr
is empty when no external address is set.
The (services, version)
field can be used to enable certain features
in protocols, or even to upgrade protocols to new versions. When
protocols are first attached, they can add their own data to this field
which will be communicated in the subsequent version exchange. Any
further negotiation needed can be done using protocol specific messages
afterwards.