130 - sendheaders message
BIP: 130 source Layer: Peer Services Title: sendheaders message Authors: Suhas Daftuar Status: Deployed Type: Specification Assigned: 2015-05-08 License: PD Table of ContentsAbstractMotivationSpecificationAdditional constraintsBackward compatibilityImplementationCopyright Abstract Add a new message, "sendheaders", which indicates that a node prefers to receive new block announcements via a "headers" message rather than an "inv". Motivation Since the introduction of "headers-first" downloading of blocks in 0.10, blocks will not be processed unless they are able to connect to a (valid) headers chain. Consequently, block relay generally works as follows: A node (N) announces the new tip with an "inv" message, containing the block hashA peer (P) responds to the "inv" with a "getheaders" message (to request headers up to the new tip) and a "getdata" message for the new tip itselfN responds with a "headers" message (with the header for the new block along with any precedi...
339 - WTXID-based transaction relay
BIP: 339 source Layer: Peer Services Title: WTXID-based transaction relay Authors: Suhas Daftuar Status: Deployed Type: Specification Assigned: 2020-02-03 License: BSD-2-Clause Table of ContentsAbstractMotivationSpecificationBackward compatibilityImplementationCopyright Abstract This BIP describes two changes to the p2p protocol to support transaction relay based on the BIP 141 wtxid of a transaction, rather than its txid. Motivation Historically, the inv messages sent on the Bitcoin peer-to-peer network to announce transactions refer to transactions by their txid, which is a hash of the transaction that does not include the witness (see BIP 141). This has been the case even since Segregated Witness (BIP 141/143/144) has been adopted by the network. Not committing to the witness in transaction announcements creates inefficiencies: because a transaction's witness can be malleated without altering the txid, a node in receipt of a witness transaction that the node does not...
90 - Buried Deployments
BIP: 90 source Title: Buried Deployments Authors: Suhas Daftuar Comments-Summary: Mostly Recommended for implementation, with some Discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0090 Status: Deployed Type: Informational Assigned: 2016-11-08 License: PD Table of ContentsAbstractMotivationConsiderationsSpecificationImplementationReferencesAcknowledgementsCopyright Abstract Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers. Now that the chain has long since passed the blocks at which those consensus rules have triggered, we can (as a simplification) replace the trigger mechanism by caching the block heights at which those consensus rules became enforced. Motivation BIPs 34, 65 and 66 were deployed on mainnet using miner signaling using block version numbers. In short, new consensus rules were proposed for use in blocks with a higher version number (N+1) than the prevailing block v...
338 - Disable transaction relay message
BIP: 338 source Layer: Peer Services Title: Disable transaction relay message Authors: Suhas Daftuar Status: Closed Type: Specification Assigned: 2020-09-03 License: BSD-2-Clause Table of ContentsAbstractMotivationSpecificationCompatibilityImplementationReferencesCopyright Abstract This BIP describes a change to the p2p protocol to allow a node to tell a peer that a connection will not be used for transaction relay, to support block-relay-only connections that are currently in use on the network. Motivation This proposal is part of an effort to increase the number of inbound connections that a peer can service, by distinguishing peers which will not relay transactions from those that do. Since 2019, software has been deployed[1] which initiates connections on the Bitcoin network and sets the transaction relay field (introduced by BIP 37 and also defined in BIP 60) to false, to prevent transaction relay from occurring on the connection. Additionally, addr messages receiv...
433 - Pay to Anchor (P2A)
BIP: 433 source Layer: Applications Title: Pay to Anchor (P2A) Authors: Gregory Sanders Status: Draft Type: Informational Assigned: 2025-12-08 License: BSD-3-Clause Discussion: 2024-06-27: https://github.com/bitcoin/bitcoin/pull/30352 Github PR 2024-10-10: https://bitcoinops.org/en/bitcoin-core-28-wallet-integration-guide/ wallet integration guide Table of ContentsAbstractMotivationSpecificationImplementationRelated WorkBackward CompatibilityAcknowledgementsReferences and Rationale Abstract This document describes a new standard output script called Pay to Anchor (P2A) and prescribes making spending of this output type standard. This output is "keyless" meaning no signature or witness data at all are required to spend this output typea. Motivation The "anchor" output type is a commonly used pattern in Bitcoin layer 2 systems such as Lightning Network and beyond. This pattern allows transactions which are presigned far in advance to leave a "hook" for CPF...