BIP 0014

Work In Progress

  BIP: 14
  Title: BIP Protocol Version and User Agent
  Author: Amir Taaki <genjix@riseup.net>
  Status: Draft
  Type: Standards Track
  Created: 10-11-2011
  Post-History: 02-11-2011

In this document, bitcoin will be used to refer to the protocol while Satoshi will refer to the current client in order to prevent confusion.

Past Situation

Bitcoin as a protocol began life with the Satoshi client. Now that the community is diversifying, a number of alternative clients with their own codebases written in a variety of languages (Java, Python, Javascript, C++) are rapidly developing their own feature-sets.

Embedded in the protocol is a version number. Primarily this version number is in the "version" and "getblocks" messages, but is also in the "block" message to indicate the software version that created that block. Currently this version number is the same version number as that of the client. This document is a proposal to separate the protocol version from the client version, together with a proposed method to do so.

Rationale

Every release of the Satoshi client will increase its internal version number currently. Primarily this holds every other client hostage to a game of catch-up with Satoshi version number schemes. This plays against the decentralised nature of bitcoin, by forcing every software release to remain in step with the release schedule of one group of bitcoin developers.

Version bumping can also introduce incompatibilities and fracture the network. In order that the health of the network is maintained, the development of the protocol as a shared common collaborative process should be split off from the implementation of that protocol. Neutral third entities to guide the protocol with representatives from all groups, present the chance for bitcoin to grow in a positive manner with minimal risks.

By using a protocol version, we set all implementations on the network to a common standard. Everybody is able to agree within their confines what is protocol and what is implementation-dependent. A user agent string is offered as a 'vanity-plate' for clients to distinguish themselves in the network.

Separation of the network protocol from the implemention, and forming development of said protocol by means of a mutual consensus among participants, has the democratic disadvantage when agreement is hard to reach on contentious issues. To mitigate this issue, strong communication channels and fast release schedules are needed, and are outside the scope of this document (concerning a process-BIP type).

User agents provide extra tracking information that is useful for keeping tabs on network data such as client implementations used or common architectures/operating-systems. In the rare case they may even provide an emergency method of shunning faulty clients that threaten network health- although this is strongly unrecommended and extremely bad form. The user agent does not provide a method for clients to work around and behave differently to different implementations, as this will lead to protocol fracturing.

In short:

• Protocol version: way to distinguish between nodes and behave different accordingly.
• User agent: simple informational tool. Protocol should not be modified depending on user agent.

• • Potential problems (people hacking around problems)
  • Response to those problems

Browser User-Agents

• User agents on websites

Proposal

• Modified bitcoin user agent
  • Why modified?
  • Explain standard

Timeline

• Timeline/path for inclusion