Difference between revisions of "Protocol specification v3"
Line 30: | Line 30: | ||
The getdata message is identically to protocol version 2. you can lookup details [https://bitmessage.org/wiki/Protocol_specification#getdata here] | The getdata message is identically to protocol version 2. you can lookup details [https://bitmessage.org/wiki/Protocol_specification#getdata here] | ||
− | === | + | === unsupported messages === |
− | If a node receives an unknown message is shall silently ignore it. This is for further extensions of the protocol with other messages. Nodes that don't understand such a new message type shall be able to work correct with the message | + | If a node receives an unknown message is shall silently ignore it. This is for further extensions of the protocol with other messages. Nodes that don't understand such a new message type shall be able to work correct with the message types it understands. |
− | Maybe some version 2 nodes did already implement it that way, but in version 3 it is part of the protocol specification, that a node must silently ignore | + | Maybe some version 2 nodes did already implement it that way, but in version 3 it is part of the protocol specification, that a node must silently ignore unsupported messages. |
== Object type == | == Object type == |
Revision as of 07:30, 5 July 2014
Contents
Introduction
This is a DRAFT for the protocol version 3. It describes the changes in protocol version 3 versus version 2. Things which are unchanged from version 2 are not described in detail. So you should use this as a reference for all formates which are not mentioned in this description.
Message types
Most message types are unchanged from version 2 to version 3. Only the four "objecttype" messages are not valid any more. They are summerized into one single message.
version
The version message is identically to protocol version 2. you can lookup details here
verack
The verack message is identically to protocol version 2. you can lookup details here
addr
The addr message is identically to protocol version 2. you can lookup details here
inv
The inv message is identically to protocol version 2. you can lookup details here
getdata
The getdata message is identically to protocol version 2. you can lookup details here
unsupported messages
If a node receives an unknown message is shall silently ignore it. This is for further extensions of the protocol with other messages. Nodes that don't understand such a new message type shall be able to work correct with the message types it understands.
Maybe some version 2 nodes did already implement it that way, but in version 3 it is part of the protocol specification, that a node must silently ignore unsupported messages.
Object type
The four former object types "getpubkey", "pubkey", "msg" and "broadcast" are summarizes into a single Message type "object". The four Messages as they did exist in version 2 protocol are not valid any more.
Objects are shared throughout a stream. A client should advertise objects until their end of life time is reached. To be a valid object, the Proof Of Work has to be done.
Field Size | Description | Data type | Comments |
---|---|---|---|
8 | POW nonce | uint64_t |
Random nonce used for the Proof Of Work |
8 | time | uint32_t |
The "end of life" time of this object (be aware, in version 2 of the protocol this was the generation time). Objects shall be broadcast until its end of life time has been reached. The node shall store the inventory vector of that object for at least another hour to avoid reloading it from another node with a small time delay. The maximum value for the "time to life" of an object is 28 days. so the "end of life time" is 28 days in the future at maximum. |
4 | object type | uint32_t |
This field specifies the content of the object. Valid values are (at the moment) 0-"getpubkey", 1-"pubkey", 2-"msg", 3-"broadcast". all other values are reserved. Nodes shall transport objects with unknown types, too. This will make further protocol changes more easy. |
? | payload | uchar[] |
This field varies depending on the object type. For a detailed description of their content look here |
Do a POW
Generally the POW is done exactly like in version 2
The "target" (the difficulty of the POW) is defined a little bit lower (more difficult) in version 3. This is, because practice did show, it is to easy to float the network with data. In addition to that it is possible in version 3 to lower the time to life of a message (for example when doing a life chat) and getting an easier POW for that.
payload = EndOfLifeTime + ObjectType + payload
PayloadLenInBytes * TimeToLiveInSeconds loadvalue = --------------------------------------- + payloadLengthExtraBytes + 8 3600
2^64 target = ------------------------------------------------ loadvalue * averageProofOfWorkNonceTrialsPerByte