BIP

In short

Bitcoin Improvement Proposal. Formal process allowing the community to propose, discuss, and document improvements to the Bitcoin protocol.

Detailed explanation
Acronym for "Bitcoin Improvement Proposal." A Bitcoin Improvement Proposal (BIP) is a formalized process for proposing and documenting improvements and changes to the Bitcoin protocol and its standards. Since Bitcoin has no central authority to decide on updates, BIPs allow the community to suggest, discuss, and implement improvements in a structured and transparent way.
Each BIP details the objectives of the proposed improvement, the justifications, potential impacts on compatibility, as well as the advantages and disadvantages. BIPs can be written by any member of the community, but must be approved by other developers and the editors who maintain the Bitcoin Core GitHub database: Bryan Bishop, Jon Atack, Luke Dashjr, Mark Erhardt (Murch), Olaoluwa Osuntokun, and Ruben Somsen. Their editorial role does not imply control over Bitcoin itself. Even if a proposal is not accepted through the formal BIP process, it can still be presented directly to the Bitcoin community or implemented in a separate fork. The BIP process provides formality and a centralized reference point to facilitate debate and reduce fragmentation among Bitcoin users, aiming to implement updates by consensus. Ultimately, economic majority determines influence and decision‑making within the protocol.
BIPs are classified into three main categories:
  • Standards Track BIPs: Concern modifications that directly affect Bitcoin implementations, such as transaction and block validation rules;
  • Informational BIPs: Provide information or recommendations without proposing direct changes to the protocol;
  • Process BIPs: Describe changes in the procedures surrounding Bitcoin, such as governance processes.
Standards Track and Informational BIPs are also classified by "Layer":
  • Consensus Layer: Proposals that modify Bitcoin's consensus rules (e.g., block or transaction validation rules). These can be implemented as either soft forks (backward-compatible changes) or hard forks (non-backward-compatible changes). SegWit and Taproot BIPs fall into this category.
  • Peer Services: Proposals relating to how nodes discover and communicate with each other over the network.
  • API/RPC: Changes to Application Programming Interfaces (APIs) and Remote Procedure Calls (RPCs) used for software-to-node interaction.
  • Applications Layer: Standards for applications built on top of Bitcoin, such as wallet formats.
Submitting a BIP begins with conceptualizing and discussing the idea on the Bitcoin-dev mailing list. If promising, the author drafts the BIP following a standardized format and submits it as a Pull Request to the GitHub repository. The editors review this proposal to verify that it meets all the criteria. The BIP must be technically feasible, beneficial to the protocol, comply with the required formatting, and be in accordance with Bitcoin's philosophy. If the BIP meets these conditions, it is officially integrated into the GitHub repository of BIPs. It is then assigned a number. This number is generally decided by the editor, often Luke Dashjr, and is assigned logically: BIPs dealing with similar subjects often receive consecutive numbers.
BIPs then go through different statuses over their lifecycle. The current status is specified in the header of each BIP:
  • Draft: The proposal is still in the drafting and debate phase;
  • Proposed: The BIP is considered complete and ready for review by the community;
  • Deferred: The BIP is put on hold for later by the author or an editor;
  • Rejected: A BIP is classified as rejected if it has shown no activity for 3 years. Its author may choose to resume it later, which would allow it to return to the draft status;
  • Withdrawn: The BIP has been withdrawn by its author;
  • Final: The BIP is accepted and widely implemented on Bitcoin;
  • Active: For process BIPs only, this status is assigned once a certain consensus is reached;
  • Replaced / Obsolete: The BIP is no longer applicable or has been replaced by a more recent proposal that renders it unnecessary.
TermDefinition
51% attack
An attack where a malicious actor controls more than half of the mining hash power, allowing them to manipulate transactions, notably by performing double spends.
Account
In an HD wallet, a derivation level (depth 3) allowing hierarchical organization of keys and addresses.
Activation method
The process by which the Bitcoin community decides to activate a soft fork, seeking consensus among miners and users to avoid a blockchain split.
Adaptor signature
A cryptographic technique linking a signature to a secret, such that publishing the signature reveals the secret. Useful for atomic swaps without a trusted intermediary.
Addr
An old Bitcoin network message that allowed communicating IP addresses of nodes accepting connections. Replaced by addrv2 (BIP155) to support longer address formats.
Addr.dat
An old file in Bitcoin Core that stored information about network peers. Replaced by peers.dat since version 0.7.0.
Address reuse
A discouraged practice of using the same Bitcoin address multiple times to receive payments, which harms privacy by allowing funds to be traced.
Address spoofing
An attack where a malicious actor creates an address closely resembling the victim's to deceive them and divert their payments.
Addrv2
A new network message format (BIP155) allowing the broadcasting of Bitcoin node addresses. Supports longer addresses such as Tor v3 or I2P.
Agorism
A libertarian political philosophy advocating economic action outside of state control (counter-economy) to progressively undermine state power.
Air cooling
A cooling system for mining machines using fans to dissipate heat. The most widespread and least expensive method.
Altcoin
Designates any cryptocurrency other than Bitcoin. A contraction of alternative and coin.
Aluvm
A virtual machine designed for deterministic execution of smart contracts, notably within the context of the RGB protocol on Bitcoin.
Analysis heuristic
An empirical method used to trace Bitcoin flows on the blockchain based on observable characteristics within transactions.
Ancestor mining
A principle whereby a miner selects transactions taking into account the fees of parent transactions, not only their own fees. Also called CPFP.
Anchor
In the RGB protocol, a set of data proving the inclusion of a commitment in a Bitcoin transaction, without publicly revealing its content.
Anchor outputs
A mechanism on Lightning allowing adjustment of the fees of a commitment transaction after its creation, to ensure quick channel closure.
Anchors.dat
A Bitcoin Core file storing IP addresses of nodes the client was connected to before shutdown, to facilitate reconnection on restart.
Anonsets (anonymity sets)
Indicators measuring the degree of privacy of a UTXO by counting the number of indistinguishable UTXOs in a set, typically after a coinjoin.
Anyprevout (apo)
A proposal (BIP118) adding new SigHash flags allowing the creation of signatures that do not cover any specific input of the transaction.
51% attack
An attack where a malicious actor controls more than half of the mining hash power, allowing them to manipulate transactions, notably by performing double spends.
Account
In an HD wallet, a derivation level (depth 3) allowing hierarchical organization of keys and addresses.
Activation method
The process by which the Bitcoin community decides to activate a soft fork, seeking consensus among miners and users to avoid a blockchain split.
Adaptor signature
A cryptographic technique linking a signature to a secret, such that publishing the signature reveals the secret. Useful for atomic swaps without a trusted intermediary.
Addr
An old Bitcoin network message that allowed communicating IP addresses of nodes accepting connections. Replaced by addrv2 (BIP155) to support longer address formats.
Addr.dat
An old file in Bitcoin Core that stored information about network peers. Replaced by peers.dat since version 0.7.0.
Address reuse
A discouraged practice of using the same Bitcoin address multiple times to receive payments, which harms privacy by allowing funds to be traced.
Address spoofing
An attack where a malicious actor creates an address closely resembling the victim's to deceive them and divert their payments.
Addrv2
A new network message format (BIP155) allowing the broadcasting of Bitcoin node addresses. Supports longer addresses such as Tor v3 or I2P.
Agorism
A libertarian political philosophy advocating economic action outside of state control (counter-economy) to progressively undermine state power.
Air cooling
A cooling system for mining machines using fans to dissipate heat. The most widespread and least expensive method.
Altcoin
Designates any cryptocurrency other than Bitcoin. A contraction of alternative and coin.
Aluvm
A virtual machine designed for deterministic execution of smart contracts, notably within the context of the RGB protocol on Bitcoin.
Analysis heuristic
An empirical method used to trace Bitcoin flows on the blockchain based on observable characteristics within transactions.
Ancestor mining
A principle whereby a miner selects transactions taking into account the fees of parent transactions, not only their own fees. Also called CPFP.
Anchor
In the RGB protocol, a set of data proving the inclusion of a commitment in a Bitcoin transaction, without publicly revealing its content.
Anchor outputs
A mechanism on Lightning allowing adjustment of the fees of a commitment transaction after its creation, to ensure quick channel closure.
Anchors.dat
A Bitcoin Core file storing IP addresses of nodes the client was connected to before shutdown, to facilitate reconnection on restart.
Anonsets (anonymity sets)
Indicators measuring the degree of privacy of a UTXO by counting the number of indistinguishable UTXOs in a set, typically after a coinjoin.
Anyprevout (apo)
A proposal (BIP118) adding new SigHash flags allowing the creation of signatures that do not cover any specific input of the transaction.