Protocol specification v3

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 the current protocol specification, which includes the version 3 changes, as a reference for all formats which are not mentioned in this description.

New features in version 3
Here are the new features of the version 3 of Bitmessage protocol in keywords:


 * object type is now coded inside the message
 * objects may have a variable time to live
 * The POW is more difficult but can be easier if you lower the time to live
 * The protocol is tolerant for further message extension
 * The protocol is tolerant for further object extension
 * A lower maximum object size

Variable length integer
The shortest possible encoding MUST be used. In version 2 the decimal value 10 could be encoded as 0x0A, 0xFD000A, 0xFE0000000A, or 0xFF000000000000000A. In version 3 only the shortest representation, 0x0A, is allowed. The 9-byte form is no longer useful and SHOULD NOT be used.

Here is an example address which uses malformed varints: BM-CVA3RC7Mvy7JDNSpQChktwrSe4KNMaEdDdcymfUo. This address is invalid.

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 summarized into one single message.

version
The version message is identical to version 2 version message.

verack
The verack message is identical to version 2 verack message.

addr
The addr message is identical to version 2 addr message.

inv
The inv message is identical to version 2 inv message.

getdata
The getdata message is identical to version 2 getdata message.

error
Version 3 of the protocol defined a special error (or debug) message. This message may be silently ignored (and therefor handled like any other "unknown" message). The message is intended to inform the other node about protocol errors and can be used for debugging and improving code.

Unsupported messages
If a node receives an unknown message it must 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 they understand.

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 summarized 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.

Proof of Work
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 flood the network with data. In addition to that it is possible in version 3 to lower the time to live of a message (for example when doing a live chat) and getting an easier POW for that.



payloadLengthExtraBytes = 1000

nonceTrialsPerByte = 1000

Maximum object size
In version 2 the maximum object size was defined to be 170 MBytes. This object size is totally unrealistic for a normal use (POW), but is perfectly for a network attack. It will be to big to handle for clients with low bandwidth. Currently an average bitmessage "msg" object has the size of 2 kBytes. So version 3 limits the objects to a maximum size of 256 KiB(the payload of the object, starting from the POW nonce can have 262144 bytes at maximum).