BIP 0123

From Wiki
Jump to: navigation, search
  BIP: 123
  Layer: Process
  Title: BIP Classification
  Author: Eric Lombrozo
  Status: Draft
  Type: Process
  Created: 2015-08-26


This document describes a classification scheme for BIPs.

BIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements.

The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards BIP belongs.


Bitcoin is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementors a choice of whether to support them.

In order to have a BIP process which more closely reflects the interoperability requirements, it is necessary to categorize BIPs accordingly. Lower layers present considerably greater challenges in getting standards accepted and deployed.


Standards BIPs are placed in one of four layers:

  1. Consensus
  2. Peer Services
  3. API/RPC
  4. Applications

1. Consensus Layer

The consensus layer defines cryptographic commitment structures. Its purpose is ensuring that anyone can locally evaluate whether a particular state and history is valid, providing settlement guarantees, and assuring eventual convergence.

The consensus layer is not concerned with how messages are propagated on a network.

Disagreements over the consensus layer can result in network partitioning, or forks, where different nodes might end up accepting different incompatible histories. We further subdivide consensus layer changes into soft forks and hard forks.

Soft Forks

In a soft fork, some structures that were valid under the old rules are no longer valid under the new rules. Structures that were invalid under the old rules continue to be invalid under the new rules.

Hard Forks

In a hard fork, structures that were invalid under the old rules become valid under the new rules.

2. Peer Services Layer

The peer services layer specifies how nodes find each other and propagate messages.

Only a subset of all specified peer services are required for basic node interoperability. Nodes can support further optional extensions.

It is always possible to add new services without breaking compatibility with existing services, then gradually deprecate older services. In this manner, the entire network can be upgraded without serious risks of service disruption.

3. API/RPC Layer

The API/RPC layer specifies higher level calls accessible to applications. Support for these BIPs is not required for basic network interoperability but might be expected by some client applications.

There's room at this layer to allow for competing standards without breaking basic network interoperability.

4. Applications Layer

The applications layer specifies high level structures, abstractions, and conventions that allow different applications to support similar features and share data.

Classification of existing BIPs

Number Layer Title Owner Type Status
1 Process BIP Purpose and Guidelines Amir Taaki Standard Active
10 Applications Multi-Sig Transaction Distribution Alan Reiner Informational Withdrawn
11 Peer Services M-of-N Standard Transactions Gavin Andresen Standard Accepted
12 Consensus (soft fork) OP_EVAL Gavin Andresen Standard Withdrawn
13 Applications Address Format for pay-to-script-hash Gavin Andresen Standard Final
14 Peer Services Protocol Version and User Agent Amir Taaki, Patrick Strateman Standard Accepted
15 Applications Aliases Amir Taaki Standard Deferred
16 Consensus (soft fork) Pay To Script Hash Gavin Andresen Standard Final
17 Consensus (soft fork) OP_CHECKHASHVERIFY (CHV) Luke Dashjr Withdrawn Draft
18 Consensus (soft fork) hashScriptCheck Luke Dashjr Standard Draft
19 Peer Services M-of-N Standard Transactions (Low SigOp) Luke Dashjr Standard Draft
20 Applications URI Scheme Luke Dashjr Standard Replaced
21 Applications URI Scheme Nils Schneider, Matt Corallo Standard Accepted
22 API/RPC getblocktemplate - Fundamentals Luke Dashjr Standard Accepted
23 API/RPC getblocktemplate - Pooled Mining Luke Dashjr Standard Accepted
30 Consensus (soft fork) Duplicate transactions Pieter Wuille Standard Final
31 Peer Services Pong message Mike Hearn Standard Accepted
32 Applications Hierarchical Deterministic Wallets Pieter Wuille Informational Accepted
33 API/RPC Stratized Nodes Amir Taaki Standard Draft
34 Consensus (soft fork) Block v2, Height in coinbase Gavin Andresen Standard Accepted
35 Peer Services mempool message Jeff Garzik Standard Accepted
36 Peer Services Custom Services Stefan Thomas Standard Draft
37 Peer Services Bloom filtering Mike Hearn and Matt Corallo Standard Accepted
38 Applications Passphrase-protected private key Mike Caldwell Standard Draft
39 Applications Mnemonic code for generating deterministic keys Slush Standard Draft
40 Applications Stratum wire protocol Slush Standard BIP number allocated
41 Applications Stratum mining protocol Slush Standard BIP number allocated
42 Consensus (soft fork) A finite monetary supply for Bitcoin Pieter Wuille Standard Draft
43 Applications Purpose Field for Deterministic Wallets Slush Standard Draft
44 Applications Multi-Account Hierarchy for Deterministic Wallets Slush Standard Draft
45 Applications Structure for Deterministic P2SH Multisignature Wallets Manuel Araoz Standard Draft
50 Informational March 2013 Chain Fork Post-Mortem Gavin Andresen Informational Draft
60 Peer Services Fixed Length "version" Message (Relay-Transactions Field) Amir Taaki Standard Draft
61 Peer Services "reject" P2P message Gavin Andresen Standard Final
62 Consensus (soft fork) Dealing with malleability Pieter Wuille Standard Draft
63 Applications Stealth Addresses Peter Todd Standard BIP number allocated
64 Peer Services getutxos message Mike Hearn Standard Draft
65 Consensus (soft fork) OP_CHECKLOCKTIMEVERIFY Peter Todd Standard Draft
66 Consensus (soft fork) Strict DER signatures Pieter Wuille Standard Draft
67 Applications Deterministic P2SH multi-signature addresses Thomas Kerin Standard Draft
68 Consensus (soft fork) Consensus-enforced transaction replacement signalled via sequence numbers Mark Friedenbach Standard Draft
70 Applications Payment protocol Gavin Andresen Standard Final
71 Applications Payment protocol MIME types Gavin Andresen Standard Final
72 Applications Payment protocol URIs Gavin Andresen Standard Final
73 Applications Use "Accept" header with Payment Request URLs Stephen Pair Standard Draft
101 Consensus (hard fork) Increase maximum block size Gavin Andresen Standard Draft