Network
P2P network protocol changes. 25 proposals.
- BIP 14: Protocol Version and User Agent: Deployed. Separates the version of the Bitcoin network protocol from the version of any one program, and adds a "user agent" label identifying the software a node runs. As alternative clients appeared, this…
- BIP 31: Pong message: Deployed. Adds a "pong" reply that a node sends back when it receives a "ping" containing a random number. This lets software reliably tell whether a connection to another node is still alive.
- BIP 33: Stratized Nodes: Closed. Proposed specialized node roles so lightweight clients could rely on full nodes that serve them only the data they need. It aimed to keep Bitcoin usable for ordinary users as the blockchain grew too…
- BIP 35: mempool message: Deployed. Adds a "mempool" message that lets a node ask a peer for the unconfirmed transactions it is holding. This helps lightweight wallets and freshly started nodes learn quickly about payments still…
- BIP 36: Custom Services: Closed. Proposed a way for nodes to announce custom or optional services during their initial handshake without using up the small set of standard service flags. It would have made it easier to add new…
- BIP 37: Connection Bloom filtering: Deployed. Lets lightweight wallets hand a full node a Bloom filter (a compact, approximate summary of what they care about) so they receive only relevant transactions. This made phone wallets practical,…
- BIP 60: Fixed Length "version" Message (Relay-Transactions Field): Closed. Proposed making the "relay transactions" flag a fixed, always-present part of the initial handshake message rather than an optional extra. The optional field, introduced by BIP 37, made message…
- BIP 61: Reject P2P message: Deployed. Adds a "reject" message so a node can tell a peer why it refused a transaction or block. This made troubleshooting easier for wallet and node developers, though Bitcoin Core later removed the message.
- BIP 64: getutxo message: Closed. Proposed a network message letting a node ask peers whether specific coins are still unspent. It was aimed at lightweight clients but was not adopted, partly because peers' answers could not be…
- BIP 106: Dynamically Controlled Bitcoin Block Size Max Cap: Closed. Proposed letting the maximum block size rise or fall at each difficulty adjustment based on how full recent blocks were, with a variant that also considered miners' fee income. The idea was to adapt…
- BIP 111: NODE_BLOOM service bit: Deployed. Adds a way for nodes to announce whether they offer 'bloom filtering', a service that lets lightweight wallets request only transactions relevant to them. Nodes can then decline to provide this…
- BIP 130: sendheaders message: Deployed. Adds a message by which a node asks its peers to announce new blocks by sending the block headers directly instead of a short notice to request later. This saves a round of messages and helps new…
- BIP 133: feefilter message: Deployed. Adds a 'feefilter' message by which a node tells its peers not to announce transactions paying fees below a chosen rate. This reduces wasted bandwidth by avoiding transactions the node would reject…
- BIP 150: Peer Authentication: Closed. Describes a way for Bitcoin nodes to prove their identity to trusted peers, for example so an operator can securely connect their own wallet to their own node. It is designed so that outsiders…
- BIP 151: Peer-to-Peer Communication Encryption: Closed. Proposed encrypting the traffic between Bitcoin nodes so that internet providers and eavesdroppers could not easily read or tamper with it. This early design was later superseded by the version 2…
- BIP 152: Compact Block Relay: Deployed. Introduces compact blocks, where nodes announce a new block using short transaction identifiers instead of sending every transaction again. Since peers usually already have most transactions, this…
- BIP 154: Rate Limiting via peer specified challenges: Closed. Proposes that nodes under heavy load could ask connecting peers to solve a small computational puzzle (proof of work) before receiving service. This would make it more costly for attackers to flood…
- BIP 155: addrv2 message: Deployed. Adds a new message for sharing node addresses that are longer than the old format allows. This was necessary to support newer Tor onion addresses, I2P, and other privacy networks, helping nodes…
- BIP 156: Dandelion - Privacy Enhancing Routing: Closed. Dandelion changes how new transactions travel through the network: each one is first passed quietly along a single random path before being broadcast widely. This makes it much harder for observers…
- BIP 157: Client Side Block Filtering: Deployed. Defines a protocol for lightweight wallets in which full nodes publish compact summaries (filters) of each block, and wallets download them to check locally which blocks matter. Unlike the older…
- BIP 158: Compact Block Filters for Light Clients: Deployed. Specifies how to build the compact block filters used by the BIP 157 light-client protocol, a compressed summary of the addresses and data touched in each block. Wallets use these filters to decide…
- BIP 159: NODE_NETWORK_LIMITED service bit: Deployed. Defines a signal that pruned nodes, which keep only recent blocks to save disk space, can use to advertise that they can serve recent history. This lets pruned nodes contribute more to the network…
- BIP 332: Stale Tip Relay: Draft. Defines an optional message for nodes to tell peers about recent stale blocks, valid blocks that did not end up in the main chain. Sharing them helps researchers and operators monitor mining…
- BIP 431: Topology Restrictions for Pinning: Draft. Explains 'pinning', a problem where someone can block a transaction from being replaced with a higher-fee version, which can endanger time-sensitive protocols like Lightning. It describes stricter…
- BIP 434: Peer Feature Negotiation: Complete. Defines a peer-to-peer message that nodes can exchange while first connecting, to announce and agree on support for new network features. This gives a cleaner, uniform way to roll out future…