71 - Payment Protocol MIME types
BIP: 71 Layer: Applications Title: Payment Protocol MIME types Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0071 Status: Final Type: Standards Track Created: 2013-07-29 ==Abstract== This BIP defines a MIME (RFC 2046) Media Type for Bitcoin payment request messages. ==Motivation== Wallet or server software that sends payment protocol messages over email or http should follow Internet standards for properly encapsulating the messages. ==Specification== The Media Type (Content-Type in HTML/email headers) for bitcoin protocol messages shall be: {| | Message || Type/Subtype |- | PaymentRequest || application/bitcoin-paymentrequest |- | Payment || application/bitcoin-payment |- | PaymentACK || application/bitcoin-paymentack |} Payment protocol messages are encoded in binary. ==Example== A web server generating a PaymentRequest message to initiate the payment protocol would precede the binary message data ...
72 - bitcoin
BIP: 72 Layer: Applications Title: bitcoin: uri extensions for Payment Protocol Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0072 Status: Final Type: Standards Track Created: 2013-07-29 ==Abstract== This BIP describes an extension to the bitcoin: URI scheme (BIP 21) to support the payment protocol (BIP 70). ==Motivation== Allow users to click on a link in a web page or email to initiate the payment protocol, while being backwards-compatible with existing bitcoin wallets. ==Specification== The bitcoin: URI scheme is extended with an additional, optional "r" parameter, whose value is a URL from which a PaymentRequest message should be fetched (characters not allowed within the scope of a query parameter must be percent-encoded as described in RFC 3986 and bip-0021). If the "r" parameter is provided and backwards compatibility is not required, then the bitcoin address portion of the URI may be omitt...
34 - Block v2, Height in Coinbase
BIP: 34 Layer: Consensus (soft fork) Title: Block v2, Height in Coinbase Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0034 Status: Final Type: Standards Track Created: 2012-07-06 ==Abstract== Bitcoin blocks and transactions are versioned binary structures. Both currently use version 1. This BIP introduces an upgrade path for versioned transactions and blocks. A unique value is added to newly produced coinbase transactions, and blocks are updated to version 2. ==Motivation== # Clarify and exercise the mechanism whereby the bitcoin network collectively consents to upgrade transaction or block binary structures, rules and behaviors. # Enforce block and transaction uniqueness, and assist unconnected block validation. ==Specification== # Treat transactions with a version greater than 1 as non-standard (official Satoshi client will not mine or relay them). # Add height as the first item in the coinbas...
13 - Address Format for pay-to-script-hash
BIP: 13 Layer: Applications Title: Address Format for pay-to-script-hash Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0013 Status: Final Type: Standards Track Created: 2011-10-18 ==Abstract== This BIP describes a new type of Bitcoin address to support arbitrarily complex transactions. Complexity in this context is defined as what information is needed by the recipient to respend the received coins, in contrast to needing a single ECDSA private key as in current implementations of Bitcoin. In essence, an address encoded under this proposal represents the encoded hash of a [https://en.bitcoin.it/wiki/Script script], rather than the encoded hash of an ECDSA public key. ==Motivation== Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions. Enable third-party wallet security services. ==Specification== The new bitcoin address type is constructed in ...
11 - M-of-N Standard Transactions
BIP: 11 Layer: Applications Title: M-of-N Standard Transactions Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0011 Status: Final Type: Standards Track Created: 2011-10-18 Post-History: 2011-10-02 ==Abstract== This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type. ==Motivation== Enable secured wallets, escrow transactions, and other use cases where redeeming funds requires more than a single signature. A couple of motivating use cases: * A wallet secured by a "wallet protection service" (WPS). 2-of-2 signatures required transactions will be used, with one signature coming from the (possibly compromised) computer with the wallet and the second signature coming from the WPS. When sending protected bitcoins, the user's bitcoin client will contact the WPS with the proposed transaction and it can then contact the user for confirmation that they initiated the ...
61 - Reject P2P message
BIP: 61 Layer: Peer Services Title: Reject P2P message Author: Gavin Andresen Comments-Summary: Controversial; some recommendation, and some discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0061 Status: Final Type: Standards Track Created: 2014-06-18 ==Abstract== This BIP describes a new message type for the Bitcoin peer-to-peer network. ==Motivation== Giving peers feedback about why their blocks or transactions are rejected, or why they are being banned for not following the protocol helps interoperability between different implementations. It also gives SPV (simplified payment verification) clients a hint that something may be wrong when their transactions are rejected due to insufficient priority or fees. ==Specification== Data types in this specification are as described at https://en.bitcoin.it/wiki/Protocol_specification ===reject=== One new message type "reject" is introduced. It is sent directly to a peer in response to a "version", "tx...
109 - Two million byte size limit with sigop and sighash limits
BIP: 109 Layer: Consensus (hard fork) Title: Two million byte size limit with sigop and sighash limits Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0109 Status: Rejected Type: Standards Track Created: 2016-01-28 License: PD ==Abstract== One-time increase in total amount of transaction data permitted in a block from 1MB to 2MB, with limits on signature operations and hashing. ==Motivation== # Continue current economic policy. # Exercise hard fork network upgrade. # Mitigate potential CPU exhaustion attacks ==Specification== === MAX_BLOCK_SIZE increased to 2,000,000 bytes === The maximum number of bytes in a canonically serialized block shall be increased from 1,000,000 bytes to 2,000,000 bytes. === Switch to accurately-counted sigop limit of 20,000 per block === The existing MAX_SIGOPS limit of 20,000 signature operations per block shall be retained, but only ECDSA verifications actually performed...
12 - OP_EVAL
BIP: 12 Layer: Consensus (soft fork) Title: OP_EVAL Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0012 Status: Withdrawn Type: Standards Track Created: 2011-10-18 ==Abstract== This BIP describes a new opcode (OP_EVAL) for the [https://en.bitcoin.it/wiki/Script Bitcoin scripting system], and a new 'standard' transaction type that uses it to enables the receiver of bitcoins to specify the transaction type needed to re-spend them. ==Motivation== Enable "end-to-end" secure wallets and payments to fund escrow transactions or other complex transactions in a way that is backwards-compatible for old clients and miners. ==Specification== OP_EVAL will re-define the existing OP_NOP1 opcode, and will function as follows: * When executed during transaction verification, pops the item from the top of the stack, deserializes it, and executes the resulting script. * If there is no item on the top of the stack or ...
50 - March 2013 Chain Fork Post-Mortem
BIP: 50 Title: March 2013 Chain Fork Post-Mortem Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0050 Status: Final Type: Informational Created: 2013-03-20 License: PD ==What went wrong== A block that had a larger number of total transaction inputs than previously seen was mined and broadcasted. Bitcoin 0.8 nodes were able to handle this, but some pre-0.8 Bitcoin nodes rejected it, causing an unexpected fork of the blockchain. The pre-0.8-incompatible chain (from here on, the 0.8 chain) at that point had around 60% of the mining hash power ensuring the split did not automatically resolve (as would have occurred if the pre-0.8 chain outpaced the 0.8 chain in total work, forcing 0.8 nodes to reorganise to the pre-0.8 chain). In order to restore a canonical chain as soon as possible, BTCGuild and Slush downgraded their Bitcoin 0.8 nodes to 0.7 so their pools would also reject the larger block. Thi...
16 - Pay to Script Hash
BIP: 16 Layer: Consensus (soft fork) Title: Pay to Script Hash Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0016 Status: Final Type: Standards Track Created: 2012-01-03 ==Abstract== This BIP describes a new "standard" transaction type for the Bitcoin scripting system, and defines additional validation rules that apply only to the new transactions. ==Motivation== The purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer. The benefit is allowing a sender to fund any arbitrary transaction, no matter how complicated, using a fixed-length 20-byte hash that is short enough to scan from a QR code or easily copied and pasted. ==Specification== A new standard transaction type that is relayed and included in mined blocks is defined: OP_HASH160 [20-byte-hash-value] OP_EQUAL [20-byte-hash-value] shall be...
101 - Increase maximum block size
BIP: 101 Layer: Consensus (hard fork) Title: Increase maximum block size Author: Gavin Andresen Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0101 Status: Withdrawn Type: Standards Track Created: 2015-06-22 ==Abstract== This BIP proposes replacing the fixed one megabyte maximum block size with a maximum size that grows over time at a predictable rate. ==Motivation== Transaction volume on the Bitcoin network has been growing, and will soon reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte maximum block size. Increasing the maximum size reduces the impact of that limit on Bitcoin adoption and growth. ==Specification== After deployment (see the Deployment section for details), the maximum allowed size of a block on the main network shall be calculated based on the timestamp in the block header. The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC (timestamp 1452470400...
70 - Payment Protocol
BIP: 70 Layer: Applications Title: Payment Protocol Author: Gavin Andresen Mike Hearn 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 ==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 and their wallet is launched with the amount to be paid. # Customer authoriz...
106 - Dynamically Controlled Bitcoin Block Size Max Cap
BIP: 106 Layer: Consensus (hard fork) Title: Dynamically Controlled Bitcoin Block Size Max Cap Author: Upal Chakraborty Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0106 Status: Rejected Type: Standards Track Created: 2015-08-24 ==Abstract== This BIP proposes replacing the fixed one megabyte maximum block size with a dynamically controlled maximum block size that may increase or decrease with difficulty change depending on various network factors. I have two proposals regarding this... i. Depending only on previous block size calculation. ii. Depending on previous block size calculation and previous Tx fee collected by miners. ==Motivation== With increased adoption, transaction volume on bitcoin network is bound to grow. If the one megabyte max cap is not changed to a flexible one which changes itself with changing network demand, then adoption will hamper and bitcoin's growth may choke up. Following graph shows the c...
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 ...