Bitcoin Improvement Proposals

Last updated

A Bitcoin Improvement Proposal (BIP) is a design document for introducing features or information to Bitcoin.

Contents

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:

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

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]

List of BIPs

NumberLayerTitleOwnerTypeStatus
1 BIP Purpose and GuidelinesAmir TaakiProcessReplaced
2 BIP process, revisedLuke DashjrProcessActive
8 Version bits with lock-in by heightShaolin Fry, Luke DashjrInformationalDraft
9 Version bits with timeout and delayPieter Wuille, Peter Todd, Greg Maxwell, Rusty RussellInformationalFinal
10 ApplicationsMulti-Sig Transaction DistributionAlan ReinerInformationalWithdrawn
11 ApplicationsM-of-N Standard TransactionsGavin AndresenStandardFinal
12 Consensus (soft fork)OP_EVALGavin AndresenStandardWithdrawn
13 ApplicationsAddress Format for pay-to-script-hashGavin AndresenStandardFinal
14 Peer ServicesProtocol Version and User AgentAmir Taaki, Patrick StratemanStandardFinal
15 ApplicationsAliasesAmir TaakiStandardDeferred
16 Consensus (soft fork)Pay to Script HashGavin AndresenStandardFinal
17 Consensus (soft fork)OP_CHECKHASHVERIFY (CHV)Luke DashjrStandardWithdrawn
18 Consensus (soft fork)hashScriptCheckLuke DashjrStandardProposed
19 ApplicationsM-of-N Standard Transactions (Low SigOp)Luke DashjrStandardRejected
20 ApplicationsURI SchemeLuke DashjrStandardReplaced
21 ApplicationsURI SchemeNils Schneider, Matt CoralloStandardFinal
22 API/RPCgetblocktemplate - FundamentalsLuke DashjrStandardFinal
23 API/RPCgetblocktemplate - Pooled MiningLuke DashjrStandardFinal
30 Consensus (soft fork)Duplicate transactionsPieter WuilleStandardFinal
31 Peer ServicesPong messageMike HearnStandardFinal
32 ApplicationsHierarchical Deterministic WalletsPieter WuilleInformationalFinal
33 Peer ServicesStratized NodesAmir TaakiStandardRejected
34 Consensus (soft fork)Block v2, Height in CoinbaseGavin AndresenStandardFinal
35 Peer Servicesmempool messageJeff GarzikStandardFinal
36 Peer ServicesCustom ServicesStefan ThomasStandardRejected
37 Peer ServicesConnection Bloom filteringMike Hearn, Matt CoralloStandardFinal
38 ApplicationsPassphrase-protected private keyMike Caldwell, Aaron VoisineStandardDraft
39 ApplicationsMnemonic code for generating deterministic keysMarek Palatinus, Pavol Rusnak, Aaron Voisine, Sean BoweStandardProposed
40API/RPCStratum wire protocolMarek PalatinusStandardBIP number allocated
41API/RPCStratum mining protocolMarek PalatinusStandardBIP number allocated
42 Consensus (soft fork)A finite monetary supply for BitcoinPieter WuilleStandardFinal
43 ApplicationsPurpose Field for Deterministic WalletsMarek Palatinus, Pavol RusnakInformationalFinal
44 ApplicationsMulti-Account Hierarchy for Deterministic WalletsMarek Palatinus, Pavol RusnakStandardProposed
45 ApplicationsStructure for Deterministic P2SH Multisignature WalletsManuel Araoz, Ryan X. Charles, Matias Alejo GarciaStandardProposed
47 ApplicationsReusable Payment Codes for Hierarchical Deterministic WalletsJustus RanvierInformationalDraft
49 ApplicationsDerivation scheme for P2WPKH-nested-in-P2SH based accountsDaniel WeiglInformationalFinal
50 March 2013 Chain Fork Post-MortemGavin AndresenInformationalFinal
60 Peer ServicesFixed Length "version" Message (Relay-Transactions Field)Amir TaakiStandardDraft
61 Peer ServicesReject P2P messageGavin AndresenStandardFinal
62 Consensus (soft fork)Dealing with malleabilityPieter WuilleStandardWithdrawn
63ApplicationsStealth AddressesPeter ToddStandardBIP number allocated
64 Peer Servicesgetutxo messageMike HearnStandardObsolete
65 Consensus (soft fork)OP_CHECKLOCKTIMEVERIFYPeter ToddStandardFinal
66 Consensus (soft fork)Strict DER signaturesPieter WuilleStandardFinal
67 ApplicationsDeterministic Pay-to-script-hash multi-signature addresses through public key sortingThomas Kerin, Jean-Pierre Rupp, Ruben de VriesStandardProposed
68 Consensus (soft fork)Relative lock-time using consensus-enforced sequence numbersMark Friedenbach, BtcDrak, Nicolas Dorier, kinoshitajonaStandardFinal
69 ApplicationsLexicographical Indexing of Transaction Inputs and OutputsKristov AtlasInformationalProposed
70 ApplicationsPayment ProtocolGavin Andresen, Mike HearnStandardFinal
71 ApplicationsPayment Protocol MIME typesGavin AndresenStandardFinal
72 Applicationsbitcoin: uri extensions for Payment ProtocolGavin AndresenStandardFinal
73 ApplicationsUse "Accept" header for response type negotiation with Payment Request URLsStephen PairStandardFinal
74 ApplicationsAllow zero value OP_RETURN in Payment ProtocolToby PadillaStandardRejected
75 ApplicationsOut of Band Address Exchange using Payment Protocol EncryptionJustin Newton, Matt David, Aaron Voisine, James MacWhyteStandardFinal
78 ApplicationsA Simple Payjoin ProposalNicolas DorierStandardDraft
79 ApplicationsBustapay :: a practical coinjoin protocolRyan HavarInformationalReplaced
80 Hierarchy for Non-Colored Voting Pool Deterministic Multisig WalletsJustus Ranvier, Jimmy SongInformationalDeferred
81 Hierarchy for Colored Voting Pool Deterministic Multisig WalletsJustus Ranvier, Jimmy SongInformationalDeferred
83 ApplicationsDynamic Hierarchical Deterministic Key TreesEric LombrozoStandardRejected
84 ApplicationsDerivation scheme for P2WPKH based accountsPavol RusnakInformationalDraft
85 ApplicationsDeterministic Entropy From BIP32 KeychainsEthan KosakovskyInformationalDraft
90 Buried DeploymentsSuhas DaftuarInformationalFinal
91 Consensus (soft fork)Reduced threshold Segwit MASFJames HilliardStandardFinal
98 Consensus (soft fork)Fast Merkle TreesMark Friedenbach, Kalle Alm, BtcDrakStandardDraft
99 Motivation and deployment of consensus rule changes ([soft/hard]forks)Jorge TimónInformationalRejected
100 Consensus (hard fork)Dynamic maximum block size by miner voteJeff Garzik, Tom Harding, Dagur Valberg JohannssonStandardRejected
101 Consensus (hard fork)Increase maximum block sizeGavin AndresenStandardWithdrawn
102 Consensus (hard fork)Block size increase to 2MBJeff GarzikStandardRejected
103 Consensus (hard fork)Block size following technological growthPieter WuilleStandardWithdrawn
104 Consensus (hard fork)'Block75' - Max block size like difficultyt.khanStandardRejected
105 Consensus (hard fork)Consensus based block size retargeting algorithmBtcDrakStandardRejected
106 Consensus (hard fork)Dynamically Controlled Bitcoin Block Size Max CapUpal ChakrabortyStandardRejected
107 Consensus (hard fork)Dynamic limit on the block sizeWashington Y. SanchezStandardRejected
109 Consensus (hard fork)Two million byte size limit with sigop and sighash limitsGavin AndresenStandardRejected
111 Peer ServicesNODE_BLOOM service bitMatt Corallo, Peter ToddStandardProposed
112 Consensus (soft fork)CHECKSEQUENCEVERIFYBtcDrak, Mark Friedenbach, Eric LombrozoStandardFinal
113 Consensus (soft fork)Median time-past as endpoint for lock-time calculationsThomas Kerin, Mark FriedenbachStandardFinal
114 Consensus (soft fork)Merkelized Abstract Syntax TreeJohnson LauStandardRejected
115 Consensus (soft fork)Generic anti-replay protection using ScriptLuke DashjrStandardRejected
116 Consensus (soft fork)MERKLEBRANCHVERIFYMark Friedenbach, Kalle Alm, BtcDrakStandardDraft
117 Consensus (soft fork)Tail Call Execution SemanticsMark Friedenbach, Kalle Alm, BtcDrakStandardDraft
118 Consensus (soft fork)SIGHASH_NOINPUTChristian DeckerStandardDraft
119 Consensus (soft fork)CHECKTEMPLATEVERIFYJeremy RubinStandardDraft
120 ApplicationsProof of PaymentKalle RosenbaumStandardWithdrawn
121 ApplicationsProof of Payment URI schemeKalle RosenbaumStandardWithdrawn
122 ApplicationsURI scheme for Blockchain references / explorationMarco PontelloStandardDraft
123 BIP ClassificationEric LombrozoProcessActive
124 ApplicationsHierarchical Deterministic Script TemplatesEric Lombrozo, William SwansonInformationalRejected
125 ApplicationsOpt-in Full Replace-by-Fee SignalingDavid A. Harding, Peter ToddStandardProposed
126 Best Practices for Heterogeneous Input Script TransactionsKristov AtlasInformationalDraft
127 ApplicationsSimple Proof-of-Reserves TransactionsSteven RooseStandardDraft
130 Peer Servicessendheaders messageSuhas DaftuarStandardProposed
131 Consensus (hard fork)"Coalescing Transaction" Specification (wildcard inputs)Chris PriestStandardRejected
132 Committee-based BIP Acceptance ProcessAndy ChaseProcessWithdrawn
133 Peer Servicesfeefilter messageAlex MorcosStandardDraft
134 Consensus (hard fork)Flexible TransactionsTom ZanderStandardRejected
135 Generalized version bits votingSancho PanzaInformationalRejected
136 ApplicationsBech32 Encoded Tx Position ReferencesВелеслав, Jonas Schnelli, Daniel PapeInformationalDraft
137 ApplicationsSignatures of Messages using Private KeysChristopher GilliardStandardFinal
140 Consensus (soft fork)Normalized TXIDChristian DeckerStandardRejected
141 Consensus (soft fork)Segregated Witness (Consensus layer)Eric Lombrozo, Johnson Lau, Pieter WuilleStandardFinal
142 ApplicationsAddress Format for Segregated WitnessJohnson LauStandardWithdrawn
143 Consensus (soft fork)Transaction Signature Verification for Version 0 Witness ProgramJohnson Lau, Pieter WuilleStandardFinal
144 Peer ServicesSegregated Witness (Peer Services)Eric Lombrozo, Pieter WuilleStandardFinal
145 API/RPCgetblocktemplate Updates for Segregated WitnessLuke DashjrStandardFinal
146 Consensus (soft fork)Dealing with signature encoding malleabilityJohnson Lau, Pieter WuilleStandardWithdrawn
147 Consensus (soft fork)Dealing with dummy stack element malleabilityJohnson LauStandardFinal
148 Consensus (soft fork)Mandatory activation of segwit deploymentShaolin FryStandardFinal
149 Consensus (soft fork)Segregated Witness (second deployment)Shaolin FryStandardWithdrawn
150 Peer ServicesPeer AuthenticationJonas SchnelliStandardDraft
151 Peer ServicesPeer-to-Peer Communication EncryptionJonas SchnelliStandardWithdrawn
152 Peer ServicesCompact Block RelayMatt CoralloStandardFinal
154 Peer ServicesRate Limiting via peer specified challengesKarl-Johan AlmStandardWithdrawn
155 Peer Servicesaddrv2 messageWladimir J. van der LaanStandardDraft
156 Peer ServicesDandelion - Privacy Enhancing RoutingBrad Denby, Andrew Miller, Giulia Fanti, Surya Bakshi, Shaileshh Bojja Venkatakrishnan, Pramod ViswanathStandardRejected
157 Peer ServicesClient Side Block FilteringOlaoluwa Osuntokun, Alex Akselrod, Jim PosenStandardDraft
158 Peer ServicesCompact Block Filters for Light ClientsOlaoluwa Osuntokun, Alex AkselrodStandardDraft
159 Peer ServicesNODE_NETWORK_LIMITED service bitJonas SchnelliStandardDraft
171 ApplicationsCurrency/exchange rate information APILuke DashjrStandardRejected
173 ApplicationsBase32 address format for native v0-16 witness outputsPieter Wuille, Greg MaxwellInformationalFinal
174 ApplicationsPartially Signed Bitcoin Transaction FormatAndrew ChowStandardFinal
175 ApplicationsPay to Contract ProtocolOmar Shibli, Nicholas GregoryInformationalRejected
176 Bits DenominationJimmy SongInformationalDraft
178 ApplicationsVersion Extended WIFKarl-Johan AlmStandardDraft
179 Name for payment recipient identifiersEmil Engler, MarcoFalke, Luke DashjrInformationalDraft
180 Peer ServicesBlock size/weight fraud proofLuke DashjrStandardRejected
197 ApplicationsHashed Time-Locked Collateral ContractMatthew Black, Tony CaiStandardDraft
199 ApplicationsHashed Time-Locked Contract transactionsSean Bowe, Daira HopwoodStandardDraft
300 Consensus (soft fork)Hashrate Escrows (Consensus layer)Paul Sztorc, CryptAxeStandardDraft
301 Consensus (soft fork)Blind Merged Mining (Consensus layer)Paul Sztorc, CryptAxeStandardDraft
310 ApplicationsStratum protocol extensionsPavel Moravec, Jan ČapekInformationalDraft
320 nVersion bits for general purpose useBtcDrakStandardDraft
322 ApplicationsGeneric Signed Message FormatKarl-Johan AlmStandardDraft
325 ApplicationsSignetKarl-Johan Alm, Anthony TownsStandardProposed
330 Peer ServicesTransaction announcements reconciliationGleb Naumenko, Pieter WuilleStandardDraft
339 Peer ServicesWTXID-based transaction relaySuhas DaftuarStandardDraft
340 Schnorr Signatures for secp256k1Pieter Wuille, Jonas Nick, Tim RuffingStandardDraft
341 Consensus (soft fork)Taproot: SegWit version 1 spending rulesPieter Wuille, Jonas Nick, Anthony TownsStandardDraft
342 Consensus (soft fork)Validation of Taproot ScriptsPieter Wuille, Jonas Nick, Anthony TownsStandardDraft
350 ApplicationsBech32m format for v1+ witness addressesPieter WuilleStandardDraft

Notes

  1. Amir Taaki. "BIP Purpose and Guidelines". Github.com. Retrieved 4 February 2021.
  2. Luke Dashjr (2016-02-03). "BIP process, revised". GitHub .
  3. "RFC 822 - Standard for the Format of Arpa Internet Text Messages".
  4. Amir Taaki. "BIP Purpose and Guidelines". Github.com. Retrieved 4 February 2021.
  5. "Bip32". University of Texas at Austin . Retrieved 17 October 2021.
  6. "How does Add Account Work". Binance.org . Retrieved 17 October 2021.
  7. "BIP 32 (Hierarchical Deterministic Wallets)". River Financial . Retrieved 17 October 2021.
  8. Palatinus, Marek; Rusnak, Pavol; Voisine, Aaron; Bowe, Sean (10 September 2013). "BIP-0039: Mnemonic code for generating deterministic keys". GitHub . Retrieved 17 October 2021. Comments-Summary: Unanimously Discourage for implementation
  9. "Bitcoin.org Developer Guide". Bitcoin.org. Retrieved 4 February 2021.
  10. Rusnak, Pavol; Kozlik, Andrew; Vejpustek, Ondrej; Susanka, Tomas; Palatinus, Marek; Hoenicke, Jochen (2017-12-18). "SLIP-0039 : Shamir's Secret-Sharing for Mnemonic Codes". GitHub . SatoshiLabs. Retrieved 2022-10-03. 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.
  11. Palatinus, Marek; Rusnak, Pavol (24 April 2014). "BIP-0044: Multi-Account Hierarchy for Deterministic Wallets". GitHub . Retrieved 17 October 2021.

See also

Related Research Articles

In cryptography, the Elliptic Curve Digital Signature Algorithm (ECDSA) offers a variant of the Digital Signature Algorithm (DSA) which uses elliptic-curve cryptography.

<span class="mw-page-title-main">Digital currency</span> Currency stored on electronic systems

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.

<span class="mw-page-title-main">JSON</span> Open standard file format and data interchange

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.

<span class="mw-page-title-main">GUID Partition Table</span> Computer disk partitioning standard

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.

<span class="mw-page-title-main">Cryptocurrency</span> Encrypted medium of digital exchange

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.

<span class="mw-page-title-main">Firo (cryptocurrency)</span> Cryptocurrency

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.

<span class="mw-page-title-main">Bitcoin scalability problem</span> Scaling problem in bitcoin processing

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.

<span class="mw-page-title-main">Cyphal</span>

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.

<span class="mw-page-title-main">Avalanche (blockchain platform)</span> Open-source blockchain computing platform

Avalanche is a decentralized, open-source proof of stake blockchain with smart contract functionality. AVAX is the native cryptocurrency of the platform.