BIP: 123 Layer: Process Title: BIP Classification Author: Eric Lombrozo <elombrozo@gmail.com> 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:
- Consensus
- Peer Services
- API/RPC
- Applications
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.
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.
In a hard fork, structures that were invalid under the old rules become valid under the new rules.
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.
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.
The applications layer specifies high level structures, abstractions, and conventions that allow different applications to support similar features and share data.
| Number | Layer | Title | Owner | Type | Status |
|---|---|---|---|---|---|
| 1 | Process | BIP Purpose and Guidelines | Amir Taaki | Standard | Active |
| 9 | Consensus (soft fork) | Version bits with timeout and delay | Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell | Informational | Draft |
| 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 |
| 80 | Applications | Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets | Monetas | Informational | Draft |
| 83 | Applications | Dynamic Hierarchical Deterministic Key Trees | Eric Lombrozo | Standard | Draft |
| 99 | Informational | Motivation and deployment of consensus rule changes ([soft/hard]forks) | Jorge Timón | Informational / Process | Draft |
| 101 | Consensus (hard fork) | Increase maximum block size | Gavin Andresen | Standard | Draft |
| 102 | Consensus (hard fork) | Block size increase to 2MB | Jeff Garzik | Standard | Draft |
| 103 | Consensus (hard fork) | Block size following technological growth | Pieter Wuille | Standard | Draft |
| 105 | Consensus (hard fork) | Consensus based block size retargetting algorithm | BtcDrak | Standard | Draft |
| 106 | Consensus (hard fork) | Dynamically Controlled Bitcoin Block Size Max Cap | Upal Chakraborty | Standard | Draft |
| 107 | Consensus (hard fork) | Dynamic limit on the block size | Washington Y. Sanchez | Standard | Draft |
| 111 | Peer Services | NODE_BLOOM service bit | Matt Corallo, Peter Todd | Standard | Draft |
| 112 | Consensus (soft fork) | CHECKSEQUENCEVERIFY | BtcDrak, Mark Friedenbach, Eric Lombrozo | Standard | Draft |
| 113 | Consensus (soft fork) | Median time-past as endpoint for locktime calculations | Thomas Kerin, Mark Friedenbach | Standard | Draft |
| 120 | Applications | Proof of Payment | Kalle Rosenbaum | Standard | Draft |
| 121 | Applications | Proof of Payment URI scheme | Kalle Rosenbaum | Standard | Draft |
| 122 | Applications | URI scheme for Blockchain references / exploration | Marco Pontello | Standard | Draft |
| 123 | Process | BIP Classification | Eric Lombrozo | Standard | Draft |
| 124 | Applications | Hierarchical Deterministic Script Templates | Eric Lombrozo, William Swanson | Standard | Draft |
| 125 | Peer Services | Opt-in Full Replace-by-Fee Signaling | David Harding, Peter Todd | Standard | Draft |
| 130 | Peer Services | sendheaders message | Suhas Daftuar | Standard | Draft |
| 131 | Consensus (hard fork) | "Coalescing Transaction" Specification (wildcard inputs) | Chris Priest | Standard | Draft |
| 132 | Process | Committee-based BIP Acceptance Process | Andy Chase | Process | Draft |
| 140 | Consensus (soft fork) | Normalized TXID | Christian Decker | Standard | Draft |
| 141 | Consensus (soft fork) | Segregated Witness (Consensus layer) | Eric Lombrozo, Johnson Lau, Pieter Wuille | Standard | Draft |
| 142 | Applications | Address Format for Segregated Witness | Johnson Lau | Standard | Draft |
| 143 | Consensus (soft fork) | Transaction Signature Verification for Version 0 Witness Program | Johnson Lau, Pieter Wuille | Standard | Draft |
| 144 | Peer Services | Segregated Witness (Peer Services) | Eric Lombrozo, Pieter Wuille | Standard | Draft |