Bitcoin Improvement Proposals
A Bitcoin Improvement Proposal (BIP) is a design document for introducing features or information to Bitcoin. This is the standard way of communicating ideas since Bitcoin has no formal structure.
The first BIP (BIP 0001) was submitted by Amir Taaki on 2011-08-19 and described what a BIP is.
BIP Types
There are three types of BIPs:
- Standards Track BIPs - Changes to the network protocol, block or transaction validation, or anything affecting interoperability.
- Informational BIPs - Design issues, general guidelines. This type of BIP is NOT for proposing new features and do not represent community consensus
- Process BIPs - Describes or proposes a change in process. Similar to Standards BIPs but apply outside the Bitcoin protocol.
BIP Workflow
As described in BIP 0001 the workflow of a BIP is as follows:
List of BIPs
|
Please do not modify this page. This is a mirror of the BIP from the source Git repository here. |
People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell <gmaxwell@gmail.com>. After copy-editing and acceptance, it will be published here.
We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.
Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community.
Those proposing changes should consider that ultimately consent may rest with the consensus of the Bitcoin users (see also: economic majority).
| Number | Title | Owner | Type | Status |
|---|---|---|---|---|
| 1 | BIP Purpose and Guidelines | Amir Taaki | Standard | Active |
| 10 | Multi-Sig Transaction Distribution | Alan Reiner | Informational | Withdrawn |
| 11 | M-of-N Standard Transactions | Gavin Andresen | Standard | Accepted |
| 12 | OP_EVAL | Gavin Andresen | Standard | Withdrawn |
| 13 | Address Format for pay-to-script-hash | Gavin Andresen | Standard | Final |
| 14 | Protocol Version and User Agent | Amir Taaki, Patrick Strateman | Standard | Accepted |
| 15 | Aliases | Amir Taaki | Standard | Deferred |
| 16 | Pay To Script Hash | Gavin Andresen | Standard | Final |
| 17 | OP_CHECKHASHVERIFY (CHV) | Luke Dashjr | Standard | Withdrawn |
| 18 | hashScriptCheck | Luke Dashjr | Standard | Draft |
| 19 | M-of-N Standard Transactions (Low SigOp) | Luke Dashjr | Standard | Draft |
| 20 | URI Scheme | Luke Dashjr | Standard | Replaced |
| 21 | URI Scheme | Nils Schneider, Matt Corallo | Standard | Accepted |
| 22 | getblocktemplate - Fundamentals | Luke Dashjr | Standard | Accepted |
| 23 | getblocktemplate - Pooled Mining | Luke Dashjr | Standard | Accepted |
| 30 | Duplicate transactions | Pieter Wuille | Standard | Final |
| 31 | Pong message | Mike Hearn | Standard | Accepted |
| 32 | Hierarchical Deterministic Wallets | Pieter Wuille | Informational | Accepted |
| 33 | Stratized Nodes | Amir Taaki | Standard | Draft |
| 34 | Block v2, Height in coinbase | Gavin Andresen | Standard | Accepted |
| 35 | mempool message | Jeff Garzik | Standard | Accepted |
| 36 | Custom Services | Stefan Thomas | Standard | Draft |
| 37 | Bloom filtering | Mike Hearn and Matt Corallo | Standard | Accepted |
| 38 | Passphrase-protected private key | Mike Caldwell | Standard | Draft |
| 39 | Mnemonic code for generating deterministic keys | Slush | Standard | Draft |
| 40 | Stratum wire protocol | Slush | Standard | BIP number allocated |
| 41 | Stratum mining protocol | Slush | Standard | BIP number allocated |
| 42 | A finite monetary supply for Bitcoin | Pieter Wuille | Standard | Draft |
| 43 | Purpose Field for Deterministic Wallets | Slush | Standard | Draft |
| 44 | Multi-Account Hierarchy for Deterministic Wallets | Slush | Standard | Draft |
| 45 | Structure for Deterministic P2SH Multisignature Wallets | Manuel Araoz | Standard | Draft |
| 50 | March 2013 Chain Fork Post-Mortem | Gavin Andresen | Informational | Draft |
| 60 | Fixed Length "version" Message (Relay-Transactions Field) | Amir Taaki | Standard | Draft |
| 61 | "reject" P2P message | Gavin Andresen | Standard | Final |
| 62 | Dealing with malleability | Pieter Wuille | Standard | Draft |
| 63 | Stealth Addresses | Peter Todd | Standard | BIP number allocated |
| 64 | getutxos message | Mike Hearn | Standard | Draft |
| 65 | OP_CHECKLOCKTIMEVERIFY | Peter Todd | Standard | Draft |
| 66 | Strict DER signatures | Pieter Wuille | Standard | Draft |
| 67 | Deterministic P2SH multi-signature addresses | Thomas Kerin | Standard | Draft |
| 68 | Consensus-enforced transaction replacement signalled via sequence numbers | Mark Friedenbach | Standard | Draft |
| 70 | Payment protocol | Gavin Andresen | Standard | Final |
| 71 | Payment protocol MIME types | Gavin Andresen | Standard | Final |
| 72 | Payment protocol URIs | Gavin Andresen | Standard | Final |
| 73 | Use "Accept" header with Payment Request URLs | Stephen Pair | Standard | Draft |