152 - Compact Block Relay
BIP: 152 Layer: Peer Services Title: Compact Block Relay Author: Matt Corallo Comments-Summary: Unanimously Recommended for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0152 Status: Final Type: Standards Track Created: 2016-04-27 License: PD ==Abstract== Compact blocks on the wire as a way to save bandwidth for nodes on the P2P network. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. ==Motivation== Historically, the Bitcoin P2P protocol has not been very bandwidth efficient for block relay. Every transaction in a block is included when relayed, even though a large number of the transactions in a given block are already available to nodes before the block is relayed. This causes moderate inbound bandwidth spikes for nodes when receiving blocks, but can cause very significant outbound bandwidt...
111 - NODE_BLOOM service bit
BIP: 111 Layer: Peer Services Title: NODE_BLOOM service bit Author: Matt Corallo Peter Todd Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0111 Status: Proposed Type: Standards Track Created: 2015-08-20 License: PD == Abstract == This BIP extends BIP 37, Connection Bloom filtering, by defining a service bit to allow peers to advertise that they support bloom filters explicitly. It also bumps the protocol version to allow peers to identify old nodes which allow bloom filtering of the connection despite lacking the new service bit. == Motivation == BIP 37 did not specify a service bit for the bloom filter service, thus implicitly assuming that all nodes that serve peers data support it. However, the connection filtering algorithm proposed in BIP 37, and implemented in several clients today, has been shown to provide little to no privacyhttp://eprint.iacr.org/2014/763, as well as being a large DoS risk on s...
21 - URI Scheme
BIP: 21 Layer: Applications Title: URI Scheme Author: Nils Schneider Matt Corallo Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0021 Status: Final Type: Standards Track Created: 2012-01-29 This BIP is a modification of an earlier [[bip-0020.mediawiki|BIP 0020]] by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed. ==Abstract== This BIP proposes a URI scheme for making Bitcoin payments. ==Motivation== The purpose of this URI scheme is to enable users to easily make payments by simply clicking links on webpages or scanning QR Codes. ==Specification== === General rules for handling (important!) === Bitcoin clients MUST NOT act on URIs without getting the user's authorization. They SHOULD require the user to manually approve each payment individually, though in some cases they MAY allow the user to automatically make this deci...
37 - Connection Bloom filtering
BIP: 37 Layer: Peer Services Title: Connection Bloom filtering Author: Mike Hearn Matt Corallo Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0037 Status: Final Type: Standards Track Created: 2012-10-24 License: PD ==Abstract== This BIP adds new support to the peer-to-peer protocol that allows peers to reduce the amount of transaction data they are sent. Peers have the option of setting ''filters'' on each connection they make after the version handshake has completed. A filter is defined as a [http://en.wikipedia.org/wiki/Bloom_filter Bloom filter] on data derived from transactions. A Bloom filter is a probabilistic data structure which allows for testing set membership - they can have false positives but not false negatives. This document will not go into the details of how Bloom filters work and the reader is referred to Wikipedia for an introduction to the topic. ==Motivation== As Bitcoin grows in usag...
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...
372 - Pay-to-contract tweak fields for PSBT
BIP: 372 Layer: Applications Title: Pay-to-contract tweak fields for PSBT Author: Maxim Orlovsky Discussions-To: Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0372 Status: Draft Type: Standards Track Created: 2022-01-16 License: BSD-2-Clause Requires: BIP-174 ==Introduction== ===Abstract=== This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2 that allow for pay-to-contract key tweaking data data to be included in a PSBT of any version. These will represent an extra-transaction information required for the signer to produce valid signatures spending previous outputs. ===Copyright=== This BIP is licensed under the 2-clause BSD license. ===Background=== Key tweaking is a procedure for creating a cryptographic commitment to some message using elliptic curve properties. The procedure uses the discrete log problem (DLP) to commit to an extra-transaction message. This is done by adding to a public key (for which the output owner k...
123 - BIP Classification
BIP: 123 Title: BIP Classification Author: Eric Lombrozo Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0123 Status: Active Type: Process Created: 2015-08-26 License: CC0-1.0 GNU-All-Permissive ==Abstract== This document describes a classification scheme for BIPs. BIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements. The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards BIP belongs. ==Copyright== This BIP is dual-licensed under the Creative Commons CC0 1.0 Universal and GNU All-Permissive licenses. ==Motivation== Bitcoin is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementors a choice of whether to support them. In order to have a BIP process which more closely ...
301 - Blind Merged Mining (Consensus layer)
BIP: 301 Layer: Consensus (soft fork) Title: Blind Merged Mining (Consensus layer) Author: Paul Sztorc CryptAxe Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0301 Status: Draft Type: Standards Track Created: 2019-07-23 License: BSD-2-Clause ==Abstract== Blind Merged Mining (BMM) allows miners to mine a Sidechain/Altcoin, without running its node software (ie, without "looking" at it, hence "blind"). Instead, a separate sidechain user runs their node and constructs the block, paying himself the transaction fees. He then uses an equivalent amount of money to "buy" the right to find this block, from the conventional layer1 Sha256d miners. ==Motivation== "Merged-Mining" (MM) allows miners to reuse their hashing work to secure other chains (for example, as in Namecoin). However, traditional MM has two drawbacks: # Miners must run a full node of the other chain(s). (Thus, they must run "non-Bitcoin" software wh...