This article may rely excessively on sources too closely associated with the subject , potentially preventing the article from being verifiable and neutral.(February 2021) |
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.
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]
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]
There are three types of BIPs:
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 is a deprecated 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] Some of the same authors later produced SLIP39 [10] to replace BIP39.
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. [11]
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 |
Comments-Summary: Unanimously Discourage for implementation
This SLIP describes a standard and interoperable implementation of Shamirs secret-sharing (SSS) and a specification for its use in backing up Hierarchical Deterministic Wallets described in BIP-0032.
In cryptography, the Elliptic Curve Digital Signature Algorithm (ECDSA) offers a variant of the Digital Signature Algorithm (DSA) which uses elliptic-curve cryptography.
Digital currency is any currency, money, or money-like asset that is primarily managed, stored or exchanged on digital computer systems, especially over the internet. Types of digital currencies include cryptocurrency, virtual currency and central bank digital currency. Digital currency may be recorded on a distributed database on the internet, a centralized electronic computer database owned by a company or bank, within digital files or even on a stored-value card.
The security of cryptographic systems depends on some secret data that is known to authorized persons but unknown and unpredictable to others. To achieve this unpredictability, some randomization is typically employed. Modern cryptographic protocols often require frequent generation of random quantities. Cryptographic attacks that subvert or exploit weaknesses in this process are known as random number generator attacks.
JSON is an open standard file format and data interchange format that uses human-readable text to store and transmit data objects consisting of attribute–value pairs and arrays. It is a common data format with diverse uses in electronic data interchange, including that of web applications with servers.
The GUID Partition Table (GPT) is a standard for the layout of partition tables of a physical computer storage device, such as a hard disk drive or solid-state drive, using universally unique identifiers, which are also known as globally unique identifiers (GUIDs). Forming a part of the Unified Extensible Firmware Interface (UEFI) standard, it is nevertheless also used for some BIOS systems, because of the limitations of master boot record (MBR) partition tables, which use 32 bits for logical block addressing (LBA) of traditional 512-byte disk sectors.
A binary-to-text encoding is encoding of data in plain text. More precisely, it is an encoding of binary data in a sequence of printable characters. These encodings are necessary for transmission of data when the channel does not allow binary data or is not 8-bit clean. PGP documentation uses the term "ASCII armor" for binary-to-text encoding when referring to Base64.
The PGP Word List is a list of words for conveying data bytes in a clear unambiguous way via a voice channel. They are analogous in purpose to the NATO phonetic alphabet used by pilots, except a longer list of words is used, each word corresponding to one of the 256 distinct numeric byte values.
Shamir's Secret Sharing (SSS) is an efficient secret sharing algorithm for distributing private information in such a way that no individual holds intelligible information about the secret. To achieve this, the secret is converted into parts from which the secret can be reassembled when a sufficient number of shares are combined but not otherwise. SSS has the unusual property of information theoretic security, meaning an adversary without enough shares cannot reconstruct the secret even with infinite time and computing capacity. A standard SSS specification for cryptocurrency wallets has been widely implemented.
Bitcoin is a decentralized digital currency that can be transferred on the peer-to-peer bitcoin network. Bitcoin transactions are verified by network nodes through cryptography and recorded in a public distributed ledger called a blockchain. The cryptocurrency was invented in 2008 by an unknown person or group of people using the name Satoshi Nakamoto. The currency began use in 2009, when its implementation was released as open-source software.
In cryptography, scrypt is a password-based key derivation function created by Colin Percival in March 2009, originally for the Tarsnap online backup service. The algorithm was specifically designed to make it costly to perform large-scale custom hardware attacks by requiring large amounts of memory. In 2016, the scrypt algorithm was published by IETF as RFC 7914. A simplified version of scrypt is used as a proof-of-work scheme by a number of cryptocurrencies, first implemented by an anonymous programmer called ArtForz in Tenebrix and followed by Fairbrix and Litecoin soon after.
A cryptocurrency, crypto-currency, or crypto is a digital currency designed to work as a medium of exchange through a computer network that is not reliant on any central authority, such as a government or bank, to uphold or maintain it. It is a decentralized system for verifying that the parties to a transaction have the money they claim to have, eliminating the need for traditional intermediaries, such as banks, when funds are being transferred between two entities.
The tables below compare cryptography libraries that deal with cryptography algorithms and have API function calls to each of the supported features.
Firo, formerly known as Zcoin, is a cryptocurrency aimed at using cryptography to provide better privacy for its users compared to other cryptocurrencies such as Bitcoin.
The Bitcoin scalability problem refers to the limited capability of the Bitcoin network to handle large amounts of transaction data on its platform in a short span of time. It is related to the fact that records in the Bitcoin blockchain are limited in size and frequency.
Cyphal is a lightweight protocol designed for reliable intra-vehicle communications using various communications transports, originally destined for CAN bus but targeting various network types in subsequent revisions. OpenCyphal is an open-source project that aims to provide MIT-licensed implementations of the Cyphal protocol. The project was known as UAVCAN prior to rebranding in March 2022.
A cryptocurrency wallet is a device, physical medium, program or a service which stores the public and/or private keys for cryptocurrency transactions. In addition to this basic function of storing the keys, a cryptocurrency wallet more often also offers the functionality of encrypting and/or signing information. Signing can for example result in executing a smart contract, a cryptocurrency transaction, identification or legally signing a 'document'.
Hashgraph is a distributed ledger technology that has been described as an alternative to blockchains. The hashgraph technology is currently patented, is used by the public ledger Hedera, and there is a grant to implement the patent as a result of the Apache 2.0's Grant of Patent License so long as the implementation conforms to the terms of the Apache license. The native cryptocurrency of the Hedera Hashgraph system is HBAR.
Avalanche is a decentralized, open-source proof of stake blockchain with smart contract functionality. AVAX is the native cryptocurrency of the platform.