130 - sendheaders message
BIP: 130 Layer: Peer Services Title: sendheaders message Author: Suhas Daftuar Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0130 Status: Proposed Type: Standards Track Created: 2015-05-08 License: PD ==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 hash # A 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 itself # N responds with a "headers" message (with the header for the new block along with any preceding ...
339 - WTXID-based transaction relay
BIP: 339 Layer: Peer Services Title: WTXID-based transaction relay Author: Suhas Daftuar Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0339 Status: Draft Type: Standards Track Created: 2020-02-03 License: BSD-2-Clause ==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 nod...
90 - Buried Deployments
BIP: 90 Title: Buried Deployments Author: Suhas Daftuar Comments-Summary: Mostly Recommended for implementation, with some Discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0090 Status: Final Type: Informational Created: 2016-11-08 License: PD ==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 version (N) in use on the network, and those rules became enforced under the following conditions: # 75% rule: If 750 o...
338 - Disable transaction relay message
BIP: 338 Layer: Peer Services Title: Disable transaction relay message Author: Suhas Daftuar Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0338 Status: Draft Type: Standards Track Created: 2020-09-03 License: BSD-2-Clause ==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 mess...