BIP 123: BIP Classification
View on GitHub
  BIP: 123
  Title: BIP Classification
  Author: Eric Lombrozo <>
  Comments-Summary: No comments yet.
  Status: Active
  Type: Process
  Created: 2015-08-26
  License: CC0-1.0


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

Non-standards BIPs may be placed in these layers, or none at all.

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

1BIP Purpose and GuidelinesAmir TaakiProcessActive
2BIP process, revisedLuke DashjrProcessDraft
9Version bits with timeout and delayPieter Wuille, Peter Todd, Greg Maxwell, Rusty RussellInformationalFinal
10ApplicationsMulti-Sig Transaction DistributionAlan ReinerInformationalWithdrawn
11ApplicationsM-of-N Standard TransactionsGavin AndresenStandardFinal
12Consensus (soft fork)OP_EVALGavin AndresenStandardWithdrawn
13ApplicationsAddress Format for pay-to-script-hashGavin AndresenStandardFinal
14Peer ServicesProtocol Version and User AgentAmir Taaki, Patrick StratemanStandardFinal
15ApplicationsAliasesAmir TaakiStandardDeferred
16Consensus (soft fork)Pay to Script HashGavin AndresenStandardFinal
17Consensus (soft fork)OP_CHECKHASHVERIFY (CHV)Luke DashjrStandardWithdrawn
18Consensus (soft fork)hashScriptCheckLuke DashjrStandardAccepted
19ApplicationsM-of-N Standard Transactions (Low SigOp)Luke DashjrStandardDraft
20ApplicationsURI SchemeLuke DashjrStandardReplaced
21ApplicationsURI SchemeNils Schneider, Matt CoralloStandardFinal
22API/RPCgetblocktemplate - FundamentalsLuke DashjrStandardFinal
23API/RPCgetblocktemplate - Pooled MiningLuke DashjrStandardFinal
30Consensus (soft fork)Duplicate transactionsPieter WuilleStandardFinal
31Peer ServicesPong messageMike HearnStandardFinal
32ApplicationsHierarchical Deterministic WalletsPieter WuilleInformationalFinal
33Peer ServicesStratized NodesAmir TaakiStandardDraft
34Consensus (soft fork)Block v2, Height in CoinbaseGavin AndresenStandardFinal
35Peer Servicesmempool messageJeff GarzikStandardFinal
36Peer ServicesCustom ServicesStefan ThomasStandardDraft
37Peer ServicesConnection Bloom filteringMike Hearn, Matt CoralloStandardFinal
38ApplicationsPassphrase-protected private keyMike Caldwell, Aaron VoisineStandardDraft
39ApplicationsMnemonic code for generating deterministic keysMarek Palatinus, Pavol Rusnak, Aaron Voisine, Sean BoweStandardAccepted
42Consensus (soft fork)A finite monetary supply for BitcoinPieter WuilleStandardDraft
43ApplicationsPurpose Field for Deterministic WalletsMarek Palatinus, Pavol RusnakInformationalDraft
44ApplicationsMulti-Account Hierarchy for Deterministic WalletsMarek Palatinus, Pavol RusnakStandardAccepted
45ApplicationsStructure for Deterministic P2SH Multisignature WalletsManuel Araoz, Ryan X. Charles, Matias Alejo GarciaStandardAccepted
47ApplicationsReusable Payment Codes for Hierarchical Deterministic WalletsJustus RanvierInformationalDraft
49ApplicationsDerivation scheme for P2WPKH-nested-in-P2SH based accountsDaniel WeiglInformationalDraft
50March 2013 Chain Fork Post-MortemGavin AndresenInformationalFinal
60Peer ServicesFixed Length "version" Message (Relay-Transactions Field)Amir TaakiStandardDraft
61Peer ServicesReject P2P messageGavin AndresenStandardFinal
62Consensus (soft fork)Dealing with malleabilityPieter WuilleStandardWithdrawn
64Peer Servicesgetutxo messageMike HearnStandardDraft
65Consensus (soft fork)OP_CHECKLOCKTIMEVERIFYPeter ToddStandardFinal
66Consensus (soft fork)Strict DER signaturesPieter WuilleStandardFinal
67ApplicationsDeterministic Pay-to-script-hash multi-signature addresses through public key sortingThomas Kerin, Jean-Pierre Rupp, Ruben de VriesStandardAccepted
68Consensus (soft fork)Relative lock-time using consensus-enforced sequence numbersMark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajonaStandardFinal
69ApplicationsLexicographical Indexing of Transaction Inputs and OutputsKristov AtlasInformationalAccepted
70ApplicationsPayment ProtocolGavin Andresen, Mike HearnStandardFinal
71ApplicationsPayment Protocol MIME typesGavin AndresenStandardFinal
72Applicationsbitcoin: uri extensions for Payment ProtocolGavin AndresenStandardFinal
73ApplicationsUse "Accept" header for response type negotiation with Payment Request URLsStephen PairStandardFinal
74ApplicationsAllow zero value OP_RETURN in Payment ProtocolToby PadillaStandardDraft
75ApplicationsOut of Band Address Exchange using Payment Protocol EncryptionJustin Newton, Matt David, Aaron Voisine, James MacWhyteStandardDraft
80Hierarchy for Non-Colored Voting Pool Deterministic Multisig WalletsJustus Ranvier, Jimmy SongInformationalDeferred
81Hierarchy for Colored Voting Pool Deterministic Multisig WalletsJustus Ranvier, Jimmy SongInformationalDeferred
83ApplicationsDynamic Hierarchical Deterministic Key TreesEric LombrozoStandardDraft
99Motivation and deployment of consensus rule changes ([soft/hard]forks)Jorge TimónInformationalDraft
101Consensus (hard fork)Increase maximum block sizeGavin AndresenStandardWithdrawn
102Consensus (hard fork)Block size increase to 2MBJeff GarzikStandardDraft
103Consensus (hard fork)Block size following technological growthPieter WuilleStandardDraft
105Consensus (hard fork)Consensus based block size retargeting algorithmBtcDrakStandardDraft
106Consensus (hard fork)Dynamically Controlled Bitcoin Block Size Max CapUpal ChakrabortyStandardDraft
107Consensus (hard fork)Dynamic limit on the block sizeWashington Y. SanchezStandardDraft
109Consensus (hard fork)Two million byte size limit with sigop and sighash limitsGavin AndresenStandardDraft
111Peer ServicesNODE_BLOOM service bitMatt Corallo, Peter ToddStandardAccepted
112Consensus (soft fork)CHECKSEQUENCEVERIFYBtcDrak, Mark Friedenbach, Eric LombrozoStandardFinal
113Consensus (soft fork)Median time-past as endpoint for lock-time calculationsThomas Kerin, Mark FriedenbachStandardFinal
114Consensus (soft fork)Merkelized Abstract Syntax TreeJohnson LauStandardDraft
120ApplicationsProof of PaymentKalle RosenbaumStandardDraft
121ApplicationsProof of Payment URI schemeKalle RosenbaumStandardDraft
122ApplicationsURI scheme for Blockchain references / explorationMarco PontelloStandardDraft
123BIP ClassificationEric LombrozoProcessDraft
124ApplicationsHierarchical Deterministic Script TemplatesEric Lombrozo, William SwansonInformationalDraft
125ApplicationsOpt-in Full Replace-by-Fee SignalingDavid A. Harding, Peter ToddStandardAccepted
126Best Practices for Heterogeneous Input Script TransactionsKristov AtlasInformationalDraft
130Peer Servicessendheaders messageSuhas DaftuarStandardAccepted
131Consensus (hard fork)"Coalescing Transaction" Specification (wildcard inputs)Chris PriestStandardDraft
132Committee-based BIP Acceptance ProcessAndy ChaseProcessWithdrawn
133Peer Servicesfeefilter messageAlex MorcosStandardDraft
134Consensus (hard fork)Flexible TransactionsTom ZanderStandardDraft
140Consensus (soft fork)Normalized TXIDChristian DeckerStandardDraft
141Consensus (soft fork)Segregated Witness (Consensus layer)Eric Lombrozo, Johnson Lau, Pieter WuilleStandardDraft
142ApplicationsAddress Format for Segregated WitnessJohnson LauStandardDeferred
143Consensus (soft fork)Transaction Signature Verification for Version 0 Witness ProgramJohnson Lau, Pieter WuilleStandardDraft
144Peer ServicesSegregated Witness (Peer Services)Eric Lombrozo, Pieter WuilleStandardDraft
145API/RPCgetblocktemplate Updates for Segregated WitnessLuke DashjrStandardDraft
146Consensus (soft fork)Dealing with signature encoding malleabilityJohnson Lau, Pieter WuilleStandardDraft
147Consensus (soft fork)Dealing with dummy stack element malleabilityJohnson LauStandardDraft
150Peer ServicesPeer AuthenticationJonas SchnelliStandardDraft
151Peer ServicesPeer-to-Peer Communication EncryptionJonas SchnelliStandardDraft
152Peer ServicesCompact Block RelayMatt CoralloStandardDraft



See an issue with rendering or formatting? Please submit an issue on GitHub is presented by nickmonad

Stay humble. Stack sats.

All content is owned and licensed by the respective author(s). This website makes no claim of ownership.