0123 - Active - Process - Aug. 26, 2015 (10 years, 10 months ago)
26
2015
BIP: 123
Title: BIP Classification
Author: Eric Lombrozo <[email protected]>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP 123
Status: Active
Type: Process
Created: 2015-08-26
License: CC0-1.0
GNU-All-Permissive
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.
This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and GNU All-Permissive licenses.
Bitcoin is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementers 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:
Non-standards BIPs may be placed in these layers, or none at all.
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 |
|---|---|---|---|---|---|
|
Process |
Active |
||||
|
Process |
Draft |
||||
|
Informational |
Final |
||||
|
Applications |
Multi-Sig Transaction Distribution |
Informational |
Withdrawn |
||
|
Applications |
Standard |
Final |
|||
|
Consensus (soft fork) |
Gavin Andresen |
Standard |
Withdrawn |
||
|
Applications |
Address Format for pay-to-script-hash |
Gavin Andresen |
Standard |
Final |
|
|
Peer Services |
Amir Taaki, Patrick Strateman |
Standard |
Final |
||
|
Applications |
Amir Taaki |
Standard |
Deferred |
||
|
Consensus (soft fork) |
Pay to Script Hash |
Gavin Andresen |
Standard |
Final |
|
|
Consensus (soft fork) |
Luke Dashjr |
Standard |
Withdrawn |
||
|
Consensus (soft fork) |
Luke Dashjr |
Standard |
Accepted |
||
|
Applications |
Luke Dashjr |
Standard |
Draft |
||
|
Applications |
Luke Dashjr |
Standard |
Replaced |
||
|
Applications |
Standard |
Final |
|||
|
API/RPC |
Luke Dashjr |
Standard |
Final |
||
|
API/RPC |
getblocktemplate - Pooled Mining |
Luke Dashjr |
Standard |
Final |
|
|
Consensus (soft fork) |
Pieter Wuille |
Standard |
Final |
||
|
Peer Services |
Standard |
Final |
|||
|
Applications |
Pieter Wuille |
Informational |
Final |
||
|
Peer Services |
Amir Taaki |
Standard |
Draft |
||
|
Consensus (soft fork) |
Gavin Andresen |
Standard |
Final |
||
|
Peer Services |
Standard |
Final |
|||
|
Peer Services |
Standard |
Draft |
|||
|
Peer Services |
Mike Hearn, Matt Corallo |
Standard |
Final |
||
|
Applications |
Standard |
Draft |
|||
|
Applications |
Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe |
Standard |
Accepted |
||
|
Consensus (soft fork) |
Pieter Wuille |
Standard |
Draft |
||
|
Applications |
Purpose Field for Deterministic Wallets |
Marek Palatinus, Pavol Rusnak |
Informational |
Draft |
|
|
Applications |
Marek Palatinus, Pavol Rusnak |
Standard |
Accepted |
||
|
Applications |
Structure for Deterministic P2SH Multisignature Wallets |
Standard |
Accepted |
||
|
Applications |
Reusable Payment Codes for Hierarchical Deterministic Wallets |
Informational |
Draft |
||
|
Applications |
Derivation scheme for P2WPKH-nested-in-P2SH based accounts |
Informational |
Draft |
||
|
Gavin Andresen |
Informational |
Final |
|||
|
Peer Services |
Fixed Length "version" Message (Relay-Transactions Field) |
Amir Taaki |
Standard |
Draft |
|
|
Peer Services |
Reject P2P message |
Gavin Andresen |
Standard |
Final |
|
|
Consensus (soft fork) |
Pieter Wuille |
Standard |
Withdrawn |
||
|
Peer Services |
Mike Hearn |
Standard |
Draft |
||
|
Consensus (soft fork) |
Peter Todd |
Standard |
Final |
||
|
Consensus (soft fork) |
Pieter Wuille |
Standard |
Final |
||
|
Applications |
Deterministic Pay-to-script-hash multi-signature addresses through public key sorting |
Standard |
Accepted |
||
|
Consensus (soft fork) |
Relative lock-time using consensus-enforced sequence numbers |
Standard |
Final |
||
|
Applications |
Lexicographical Indexing of Transaction Inputs and Outputs |
Informational |
Accepted |
||
|
Applications |
Gavin Andresen, Mike Hearn |
Standard |
Final |
||
|
Applications |
Gavin Andresen |
Standard |
Final |
||
|
Applications |
Gavin Andresen |
Standard |
Final |
||
|
Applications |
Use "Accept" header for response type negotiation with Payment Request URLs |
Standard |
Final |
||
|
Applications |
Allow zero value OP_RETURN in Payment Protocol |
Standard |
Draft |
||
|
Applications |
Out of Band Address Exchange using Payment Protocol Encryption |
Justin Newton, Matt David, Aaron Voisine, James MacWhyte |
Standard |
Draft |
|
|
Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets |
Justus Ranvier, Jimmy Song |
Informational |
Deferred |
||
|
Hierarchy for Colored Voting Pool Deterministic Multisig Wallets |
Justus Ranvier, Jimmy Song |
Informational |
Deferred |
||
|
Applications |
Eric Lombrozo |
Standard |
Draft |
||
|
Motivation and deployment of consensus rule changes ([soft/hard]forks) |
Informational |
Draft |
|||
|
Consensus (hard fork) |
Gavin Andresen |
Standard |
Withdrawn |
||
|
Consensus (hard fork) |
Block size increase to 2MB |
Jeff Garzik |
Standard |
Draft |
|
|
Consensus (hard fork) |
Pieter Wuille |
Standard |
Draft |
||
|
Consensus (hard fork) |
BtcDrak |
Standard |
Draft |
||
|
Consensus (hard fork) |
Standard |
Draft |
|||
|
Consensus (hard fork) |
Standard |
Draft |
|||
|
Consensus (hard fork) |
Two million byte size limit with sigop and sighash limits |
Gavin Andresen |
Standard |
Draft |
|
|
Peer Services |
Matt Corallo, Peter Todd |
Standard |
Accepted |
||
|
Consensus (soft fork) |
BtcDrak, Mark Friedenbach, Eric Lombrozo |
Standard |
Final |
||
|
Consensus (soft fork) |
Thomas Kerin, Mark Friedenbach |
Standard |
Final |
||
|
Consensus (soft fork) |
Standard |
Draft |
|||
|
Applications |
Standard |
Draft |
|||
|
Applications |
Kalle Rosenbaum |
Standard |
Draft |
||
|
Applications |
Standard |
Draft |
|||
|
BIP Classification |
Eric Lombrozo |
Process |
Draft |
||
|
Applications |
Eric Lombrozo, William Swanson |
Informational |
Draft |
||
|
Applications |
David A. Harding, Peter Todd |
Standard |
Accepted |
||
|
Best Practices for Heterogeneous Input Script Transactions |
Kristov Atlas |
Informational |
Draft |
||
|
Peer Services |
Standard |
Accepted |
|||
|
Consensus (hard fork) |
Standard |
Draft |
|||
|
Process |
Withdrawn |
||||
|
Peer Services |
Standard |
Draft |
|||
|
Consensus (hard fork) |
Standard |
Draft |
|||
|
Consensus (soft fork) |
Normalized TXID |
Standard |
Draft |
||
|
Consensus (soft fork) |
Segregated Witness (Consensus layer) |
Eric Lombrozo, Johnson Lau, Pieter Wuille |
Standard |
Draft |
|
|
Applications |
Johnson Lau |
Standard |
Deferred |
||
|
Consensus (soft fork) |
Transaction Signature Verification for Version 0 Witness Program |
Johnson Lau, Pieter Wuille |
Standard |
Draft |
|
|
Peer Services |
Eric Lombrozo, Pieter Wuille |
Standard |
Draft |
||
|
API/RPC |
Luke Dashjr |
Standard |
Draft |
||
|
Consensus (soft fork) |
Johnson Lau, Pieter Wuille |
Standard |
Draft |
||
|
Consensus (soft fork) |
Johnson Lau |
Standard |
Draft |
||
|
Peer Services |
Standard |
Draft |
|||
|
Peer Services |
Peer-to-Peer Communication Encryption |
Jonas Schnelli |
Standard |
Draft |
|
|
Peer Services |
Matt Corallo |
Standard |
Draft |