BIPs bitcoin improvement proposals

31 - Pong message

<pre> BIP: 31 Layer: Peer Services Title: Pong message Author: Mike Hearn <hearn@google.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0031 Status: Final Type: Standards Track Created: 2012-04-11 </pre> ==Abstract== This document describes a trivial protocol extension that makes it easier for clients to detect dead peer connections. ==Motivation== Today there are a few network related problems that can degrade the Bitcoin user experience: 1) Some Bitcoin clients run on platforms that can go to sleep and essentially stop running at any time without warning. Notably, this is very common on both mobiles and laptops (shut the lid). When the system comes back, TCP connections that existed before the sleep still exist but may no longer function correctly, eg, because the IP address has changed, or because the remote peer went away or the connection was timed out by some other system. Currently it can often take a...

64 - getutxo message

<pre> BIP: 64 Layer: Peer Services Title: getutxo message Author: Mike Hearn <hearn@vinumeris.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0064 Status: Obsolete Type: Standards Track Created: 2014-06-10 </pre> ==Abstract== This document describes a small P2P protocol extension that performs UTXO lookups given a set of outpoints. ==Motivation== All full Bitcoin nodes maintain a database called the unspent transaction output set. This set is how double spending is checked for: to be valid a transaction must identify unspent outputs in this set using an identifier called an "outpoint", which is merely the hash of the output's containing transaction plus an index. The ability to query this can sometimes be useful for a lightweight/SPV client which does not have the full UTXO set at hand. For example, it can be useful in applications implementing assurance contracts to do a quick check when a new pledge become...

70 - Payment Protocol

<pre> BIP: 70 Layer: Applications Title: Payment Protocol Author: Gavin Andresen <gavinandresen@gmail.com> Mike Hearn <mhearn@bitcoinfoundation.org> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0070 Status: Final Type: Standards Track Created: 2013-07-29 </pre> ==Abstract== This BIP describes a protocol for communication between a merchant and their customer, enabling both a better customer experience and better security against man-in-the-middle attacks on the payment process. ==Motivation== The current, minimal Bitcoin payment protocol operates as follows: # Customer adds items to an online shopping basket, and decides to pay using Bitcoin. # Merchant generates a unique payment address, associates it with the customer's order, and asks the customer to pay. # Customer copies the Bitcoin address from the merchant's web page and pastes it into whatever wallet they are using OR follows a bitcoin: link ...

37 - Connection Bloom filtering

<pre> BIP: 37 Layer: Peer Services Title: Connection Bloom filtering Author: Mike Hearn <hearn@google.com> Matt Corallo <bip37@bluematt.me> 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 </pre> ==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 introducti...

42 - A finite monetary supply for Bitcoin

<pre> BIP: 42 Layer: Consensus (soft fork) Title: A finite monetary supply for Bitcoin Author: Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: Unanimously Recommended for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0042 Status: Final Type: Standards Track Created: 2014-04-01 License: PD </pre> ==Abstract== Although it is widely believed that Satoshi was an inflation-hating goldbug he never said this, and in fact programmed Bitcoin's money supply to grow indefinitely, forever. He modeled the monetary supply as 4 gold mines being discovered per mibillenium (1024 years), with equal intervals between them, each one being depleted over the course of 140 years. This poses obvious problems, however. Prominent among them is the discussion on what to call 1 billion Bitcoin, which symbol color to use for it, and when wallet clients should switch to it by default. To combat this, this document proposes a controversial change: ma...

123 - BIP Classification

<pre> BIP: 123 Title: BIP Classification Author: Eric Lombrozo <elombrozo@gmail.com> 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 </pre> ==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. ...