Finance:Bitcoin Improvement Proposals
A Bitcoin Improvement Proposal (BIP) is a design document for introducing features or information to Bitcoin.
The BIP, as amended, has since become the standard way of formally communicating ideas about potential Bitcoin improvements.
History
The concept of the BIP was introduced on 2011-08-19 by Amir Taaki, in the form of the first BIP.[1] The second BIP, 'BIP2 was published 5 years later.[2]
Format
The BIP process closely mimicks the RFC process by which the internet is improved, while building on it by referring to- and requiring a document formatted with an RFC822 style header,[3] addressed to the Bitcoin development mailing list.[4]
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.
Notable BIPs
BIP32
BIP32 is the specification which introduced the standard for hierarchical deterministic (HD) wallets and extended keys to Bitcoin. Deterministic wallets can generate multiple "child" key pair chains from a master private "root" key in a deterministic way.[5][6] With the adoption of this standard, keys could be transferred between wallet software with a single extended private key (xprv), greatly improving the interoperability of wallets.[7]
BIP39
BIP39 is a proposal describing the use of plain language words chosen from a specific word list,[8] and the process for using such a string to derive a random seed used to generate a wallet as described in BIP32. This approach of utilizing a mnemonic phrase offered a much more user friendly experience for backup and recovery of cryptocurrency wallets.[9]
BIP44
BIP44 defines a logical hierarchy for deterministic wallets based on an algorithm described in BIP32 and purpose scheme described in BIP43. It allows the handling of multiple coins, multiple accounts, external and internal chains per account and millions of addresses per chain.[10]
List of BIPs
Number | Layer | Title | Owner | Type | Status |
---|---|---|---|---|---|
1 | BIP Purpose and Guidelines | Amir Taaki | Process | Replaced | |
2 | BIP process, revised | Luke Dashjr | Process | Active | |
8 | Version bits with lock-in by height | Shaolin Fry, Luke Dashjr | Informational | Draft | |
9 | Version bits with timeout and delay | Pieter Wuille, Peter Todd, Greg Maxwell, Rusty Russell | Informational | Final | |
10 | Applications | Multi-Sig Transaction Distribution | Alan Reiner | Informational | Withdrawn |
11 | Applications | M-of-N Standard Transactions | Gavin Andresen | Standard | Final |
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 | Final |
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 | Standard | Withdrawn |
18 | Consensus (soft fork) | hashScriptCheck | Luke Dashjr | Standard | Proposed |
19 | Applications | M-of-N Standard Transactions (Low SigOp) | Luke Dashjr | Standard | Rejected |
20 | Applications | URI Scheme | Luke Dashjr | Standard | Replaced |
21 | Applications | URI Scheme | Nils Schneider, Matt Corallo | Standard | Final |
22 | API/RPC | getblocktemplate - Fundamentals | Luke Dashjr | Standard | Final |
23 | API/RPC | getblocktemplate - Pooled Mining | Luke Dashjr | Standard | Final |
30 | Consensus (soft fork) | Duplicate transactions | Pieter Wuille | Standard | Final |
31 | Peer Services | Pong message | Mike Hearn | Standard | Final |
32 | Applications | Hierarchical Deterministic Wallets | Pieter Wuille | Informational | Final |
33 | Peer Services | Stratized Nodes | Amir Taaki | Standard | Rejected |
34 | Consensus (soft fork) | Block v2, Height in Coinbase | Gavin Andresen | Standard | Final |
35 | Peer Services | mempool message | Jeff Garzik | Standard | Final |
36 | Peer Services | Custom Services | Stefan Thomas | Standard | Rejected |
37 | Peer Services | Connection Bloom filtering | Mike Hearn, Matt Corallo | Standard | Final |
38 | Applications | Passphrase-protected private key | Mike Caldwell, Aaron Voisine | Standard | Draft |
39 | Applications | Mnemonic code for generating deterministic keys | Marek Palatinus, Pavol Rusnak, Aaron Voisine, Sean Bowe | Standard | Proposed |
40 | API/RPC | Stratum wire protocol | Marek Palatinus | Standard | BIP number allocated |
41 | API/RPC | Stratum mining protocol | Marek Palatinus | Standard | BIP number allocated |
42 | Consensus (soft fork) | A finite monetary supply for Bitcoin | Pieter Wuille | Standard | Final |
43 | Applications | Purpose Field for Deterministic Wallets | Marek Palatinus, Pavol Rusnak | Informational | Final |
44 | Applications | Multi-Account Hierarchy for Deterministic Wallets | Marek Palatinus, Pavol Rusnak | Standard | Proposed |
45 | Applications | Structure for Deterministic P2SH Multisignature Wallets | Manuel Araoz, Ryan X. Charles, Matias Alejo Garcia | Standard | Proposed |
47 | Applications | Reusable Payment Codes for Hierarchical Deterministic Wallets | Justus Ranvier | Informational | Draft |
49 | Applications | Derivation scheme for P2WPKH-nested-in-P2SH based accounts | Daniel Weigl | Informational | Final |
50 | March 2013 Chain Fork Post-Mortem | Gavin Andresen | Informational | Final | |
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 | Withdrawn |
63 | Applications | Stealth Addresses | Peter Todd | Standard | BIP number allocated |
64 | Peer Services | getutxo message | Mike Hearn | Standard | Obsolete |
65 | Consensus (soft fork) | OP_CHECKLOCKTIMEVERIFY | Peter Todd | Standard | Final |
66 | Consensus (soft fork) | Strict DER signatures | Pieter Wuille | Standard | Final |
67 | Applications | Deterministic Pay-to-script-hash multi-signature addresses through public key sorting | Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries | Standard | Proposed |
68 | Consensus (soft fork) | Relative lock-time using consensus-enforced sequence numbers | Mark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajona | Standard | Final |
69 | Applications | Lexicographical Indexing of Transaction Inputs and Outputs | Kristov Atlas | Informational | Proposed |
70 | Applications | Payment Protocol | Gavin Andresen, Mike Hearn | Standard | Final |
71 | Applications | Payment Protocol MIME types | Gavin Andresen | Standard | Final |
72 | Applications | bitcoin: uri extensions for Payment Protocol | Gavin Andresen | Standard | Final |
73 | Applications | Use "Accept" header for response type negotiation with Payment Request URLs | Stephen Pair | Standard | Final |
74 | Applications | Allow zero value OP_RETURN in Payment Protocol | Toby Padilla | Standard | Rejected |
75 | Applications | Out of Band Address Exchange using Payment Protocol Encryption | Justin Newton, Matt David, Aaron Voisine, James MacWhyte | Standard | Final |
78 | Applications | A Simple Payjoin Proposal | Nicolas Dorier | Standard | Draft |
79 | Applications | Bustapay :: a practical coinjoin protocol | Ryan Havar | Informational | Replaced |
80 | Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets | Justus Ranvier, Jimmy Song | Informational | Deferred | |
81 | Hierarchy for Colored Voting Pool Deterministic Multisig Wallets | Justus Ranvier, Jimmy Song | Informational | Deferred | |
83 | Applications | Dynamic Hierarchical Deterministic Key Trees | Eric Lombrozo | Standard | Rejected |
84 | Applications | Derivation scheme for P2WPKH based accounts | Pavol Rusnak | Informational | Draft |
85 | Applications | Deterministic Entropy From BIP32 Keychains | Ethan Kosakovsky | Informational | Draft |
90 | Buried Deployments | Suhas Daftuar | Informational | Final | |
91 | Consensus (soft fork) | Reduced threshold Segwit MASF | James Hilliard | Standard | Final |
98 | Consensus (soft fork) | Fast Merkle Trees | Mark Friedenbach, Kalle Alm, BtcDrak | Standard | Draft |
99 | Motivation and deployment of consensus rule changes ([soft/hard]forks) | Jorge Timón | Informational | Rejected | |
100 | Consensus (hard fork) | Dynamic maximum block size by miner vote | Jeff Garzik, Tom Harding, Dagur Valberg Johannsson | Standard | Rejected |
101 | Consensus (hard fork) | Increase maximum block size | Gavin Andresen | Standard | Withdrawn |
102 | Consensus (hard fork) | Block size increase to 2MB | Jeff Garzik | Standard | Rejected |
103 | Consensus (hard fork) | Block size following technological growth | Pieter Wuille | Standard | Withdrawn |
104 | Consensus (hard fork) | 'Block75' - Max block size like difficulty | t.khan | Standard | Rejected |
105 | Consensus (hard fork) | Consensus based block size retargeting algorithm | BtcDrak | Standard | Rejected |
106 | Consensus (hard fork) | Dynamically Controlled Bitcoin Block Size Max Cap | Upal Chakraborty | Standard | Rejected |
107 | Consensus (hard fork) | Dynamic limit on the block size | Washington Y. Sanchez | Standard | Rejected |
109 | Consensus (hard fork) | Two million byte size limit with sigop and sighash limits | Gavin Andresen | Standard | Rejected |
111 | Peer Services | NODE_BLOOM service bit | Matt Corallo, Peter Todd | Standard | Proposed |
112 | Consensus (soft fork) | CHECKSEQUENCEVERIFY | BtcDrak, Mark Friedenbach, Eric Lombrozo | Standard | Final |
113 | Consensus (soft fork) | Median time-past as endpoint for lock-time calculations | Thomas Kerin, Mark Friedenbach | Standard | Final |
114 | Consensus (soft fork) | Merkelized Abstract Syntax Tree | Johnson Lau | Standard | Rejected |
115 | Consensus (soft fork) | Generic anti-replay protection using Script | Luke Dashjr | Standard | Rejected |
116 | Consensus (soft fork) | MERKLEBRANCHVERIFY | Mark Friedenbach, Kalle Alm, BtcDrak | Standard | Draft |
117 | Consensus (soft fork) | Tail Call Execution Semantics | Mark Friedenbach, Kalle Alm, BtcDrak | Standard | Draft |
118 | Consensus (soft fork) | SIGHASH_NOINPUT | Christian Decker | Standard | Draft |
119 | Consensus (soft fork) | CHECKTEMPLATEVERIFY | Jeremy Rubin | Standard | Draft |
120 | Applications | Proof of Payment | Kalle Rosenbaum | Standard | Withdrawn |
121 | Applications | Proof of Payment URI scheme | Kalle Rosenbaum | Standard | Withdrawn |
122 | Applications | URI scheme for Blockchain references / exploration | Marco Pontello | Standard | Draft |
123 | BIP Classification | Eric Lombrozo | Process | Active | |
124 | Applications | Hierarchical Deterministic Script Templates | Eric Lombrozo, William Swanson | Informational | Rejected |
125 | Applications | Opt-in Full Replace-by-Fee Signaling | David A. Harding, Peter Todd | Standard | Proposed |
126 | Best Practices for Heterogeneous Input Script Transactions | Kristov Atlas | Informational | Draft | |
127 | Applications | Simple Proof-of-Reserves Transactions | Steven Roose | Standard | Draft |
130 | Peer Services | sendheaders message | Suhas Daftuar | Standard | Proposed |
131 | Consensus (hard fork) | "Coalescing Transaction" Specification (wildcard inputs) | Chris Priest | Standard | Rejected |
132 | Committee-based BIP Acceptance Process | Andy Chase | Process | Withdrawn | |
133 | Peer Services | feefilter message | Alex Morcos | Standard | Draft |
134 | Consensus (hard fork) | Flexible Transactions | Tom Zander | Standard | Rejected |
135 | Generalized version bits voting | Sancho Panza | Informational | Rejected | |
136 | Applications | Bech32 Encoded Tx Position References | Велеслав, Jonas Schnelli, Daniel Pape | Informational | Draft |
137 | Applications | Signatures of Messages using Private Keys | Christopher Gilliard | Standard | Final |
140 | Consensus (soft fork) | Normalized TXID | Christian Decker | Standard | Rejected |
141 | Consensus (soft fork) | Segregated Witness (Consensus layer) | Eric Lombrozo, Johnson Lau, Pieter Wuille | Standard | Final |
142 | Applications | Address Format for Segregated Witness | Johnson Lau | Standard | Withdrawn |
143 | Consensus (soft fork) | Transaction Signature Verification for Version 0 Witness Program | Johnson Lau, Pieter Wuille | Standard | Final |
144 | Peer Services | Segregated Witness (Peer Services) | Eric Lombrozo, Pieter Wuille | Standard | Final |
145 | API/RPC | getblocktemplate Updates for Segregated Witness | Luke Dashjr | Standard | Final |
146 | Consensus (soft fork) | Dealing with signature encoding malleability | Johnson Lau, Pieter Wuille | Standard | Withdrawn |
147 | Consensus (soft fork) | Dealing with dummy stack element malleability | Johnson Lau | Standard | Final |
148 | Consensus (soft fork) | Mandatory activation of segwit deployment | Shaolin Fry | Standard | Final |
149 | Consensus (soft fork) | Segregated Witness (second deployment) | Shaolin Fry | Standard | Withdrawn |
150 | Peer Services | Peer Authentication | Jonas Schnelli | Standard | Draft |
151 | Peer Services | Peer-to-Peer Communication Encryption | Jonas Schnelli | Standard | Withdrawn |
152 | Peer Services | Compact Block Relay | Matt Corallo | Standard | Final |
154 | Peer Services | Rate Limiting via peer specified challenges | Karl-Johan Alm | Standard | Withdrawn |
155 | Peer Services | addrv2 message | Wladimir J. van der Laan | Standard | Draft |
156 | Peer Services | Dandelion - Privacy Enhancing Routing | Brad Denby, Andrew Miller, Giulia Fanti, Surya Bakshi, Shaileshh Bojja Venkatakrishnan, Pramod Viswanath | Standard | Rejected |
157 | Peer Services | Client Side Block Filtering | Olaoluwa Osuntokun, Alex Akselrod, Jim Posen | Standard | Draft |
158 | Peer Services | Compact Block Filters for Light Clients | Olaoluwa Osuntokun, Alex Akselrod | Standard | Draft |
159 | Peer Services | NODE_NETWORK_LIMITED service bit | Jonas Schnelli | Standard | Draft |
171 | Applications | Currency/exchange rate information API | Luke Dashjr | Standard | Rejected |
173 | Applications | Base32 address format for native v0-16 witness outputs | Pieter Wuille, Greg Maxwell | Informational | Final |
174 | Applications | Partially Signed Bitcoin Transaction Format | Andrew Chow | Standard | Final |
175 | Applications | Pay to Contract Protocol | Omar Shibli, Nicholas Gregory | Informational | Rejected |
176 | Bits Denomination | Jimmy Song | Informational | Draft | |
178 | Applications | Version Extended WIF | Karl-Johan Alm | Standard | Draft |
179 | Name for payment recipient identifiers | Emil Engler, MarcoFalke, Luke Dashjr | Informational | Draft | |
180 | Peer Services | Block size/weight fraud proof | Luke Dashjr | Standard | Rejected |
197 | Applications | Hashed Time-Locked Collateral Contract | Matthew Black, Tony Cai | Standard | Draft |
199 | Applications | Hashed Time-Locked Contract transactions | Sean Bowe, Daira Hopwood | Standard | Draft |
300 | Consensus (soft fork) | Hashrate Escrows (Consensus layer) | Paul Sztorc, CryptAxe | Standard | Draft |
301 | Consensus (soft fork) | Blind Merged Mining (Consensus layer) | Paul Sztorc, CryptAxe | Standard | Draft |
310 | Applications | Stratum protocol extensions | Pavel Moravec, Jan Čapek | Informational | Draft |
320 | nVersion bits for general purpose use | BtcDrak | Standard | Draft | |
322 | Applications | Generic Signed Message Format | Karl-Johan Alm | Standard | Draft |
325 | Applications | Signet | Karl-Johan Alm, Anthony Towns | Standard | Proposed |
330 | Peer Services | Transaction announcements reconciliation | Gleb Naumenko, Pieter Wuille | Standard | Draft |
339 | Peer Services | WTXID-based transaction relay | Suhas Daftuar | Standard | Draft |
340 | Schnorr Signatures for secp256k1 | Pieter Wuille, Jonas Nick, Tim Ruffing | Standard | Draft | |
341 | Consensus (soft fork) | Taproot: SegWit version 1 spending rules | Pieter Wuille, Jonas Nick, Anthony Towns | Standard | Draft |
342 | Consensus (soft fork) | Validation of Taproot Scripts | Pieter Wuille, Jonas Nick, Anthony Towns | Standard | Draft |
350 | Applications | Bech32m format for v1+ witness addresses | Pieter Wuille | Standard | Draft |
Notes
- ↑ "BIP Purpose and Guidelines". https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki.
- ↑ "BIP process, revised". 2016-02-03. https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki.
- ↑ "RFC 822 - Standard for the Format of Arpa Internet Text Messages". https://tools.ietf.org/html/rfc822.
- ↑ "BIP Purpose and Guidelines". https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki.
- ↑ "Bip32". University of Texas at Austin. https://www.cs.utexas.edu/users/moore/acl2/manuals/current/manual/index-seo.php/BITCOIN____BIP32.
- ↑ "How does Add Account Work". https://docs.binance.org/smart-chain/wallet/extension/add-account.html.
- ↑ "BIP 32 (Hierarchical Deterministic Wallets)". River Financial. https://river.com/learn/terms/b/bip-32/.
- ↑ Palatinus, Marek; Rusnak, Pavol; Voisine, Aaron; Bowe, Sean (10 September 2013). "BIP-0039: Mnemonic code for generating deterministic keys". https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki.
- ↑ "Bitcoin.org Developer Guide". https://developer.bitcoin.org/devguide/wallets.html?highlight=bip39.
- ↑ Palatinus, Marek; Rusnak, Pavol (24 April 2014). "BIP-0044: Multi-Account Hierarchy for Deterministic Wallets". https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki.
See also