71 - Payment Protocol MIME types
BIP: 71 source Layer: Applications Title: Payment Protocol MIME types Authors: Gavin Andresen Status: Deployed Type: Specification Assigned: 2013-07-29 Table of ContentsAbstractMotivationSpecificationExample 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 with the following headers: Content-Type: application/bitcoin-paymentrequest Content-Trans...
72 - bitcoin
BIP: 72 source Layer: Applications Title: bitcoin: uri extensions for Payment Protocol Authors: Gavin Andresen Status: Deployed Type: Specification Assigned: 2013-07-29 Table of ContentsAbstractMotivationSpecificationCompatibilityExamplesReferences 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 omitted (the URI will be of th...
34 - Block v2, Height in Coinbase
BIP: 34 source Layer: Consensus (soft fork) Title: Block v2, Height in Coinbase Authors: Gavin Andresen Status: Deployed Type: Specification Assigned: 2012-07-06 Table of ContentsAbstractMotivationSpecificationBackward compatibilityImplementationResult 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 coinbase transaction'...
13 - Address Format for pay-to-script-hash
BIP: 13 source Layer: Applications Title: Address Format for pay-to-script-hash Authors: Gavin Andresen Status: Deployed Type: Specification Assigned: 2011-10-18 Table of ContentsAbstractMotivationSpecificationRationaleBackwards CompatibilityReference ImplementationSee Also 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 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 the same manner as existing ...
61 - Reject P2P message
BIP: 61 source Layer: Peer Services Title: Reject P2P message Authors: Gavin Andresen Comments-Summary: Controversial; some recommendation, and some discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0061 Status: Deployed Type: Specification Assigned: 2014-06-18 Table of ContentsAbstractMotivationSpecificationrejectcommon payloadrejection codes common to all message typesreject version codesreject tx payload, codespayload, reject blockCompatibilityImplementation notes 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 ty...
11 - M-of-N Standard Transactions
BIP: 11 source Layer: Applications Title: M-of-N Standard Transactions Authors: Gavin Andresen Status: Deployed Type: Specification Assigned: 2011-10-18 Discussion: 2011-10-02 Table of ContentsAbstractMotivationSpecificationRationaleImplementationPost History 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 transaction and tha...
109 - Two million byte size limit with sigop and sighash limits
BIP: 109 source Layer: Consensus (hard fork) Title: Two million byte size limit with sigop and sighash limits Authors: Gavin Andresen Status: Closed Type: Specification Assigned: 2016-01-28 License: PD Table of ContentsAbstractMotivationSpecificationMAX_BLOCK_SIZE increased to 2,000,000 bytesSwitch to accurately-counted sigop limit of 20,000 per blockAdd a new limit of 1,300,000,000 bytes hashed to compute transaction signatures per blockActivation: 75% hashpower support trigger, followed by 28-day 'grace period'Expiration: 1-Jan-2018Backward compatibilityRationaleImplementationCopyright 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 serial...
12 - OP_EVAL
BIP: 12 source Layer: Consensus (soft fork) Title: OP_EVAL Authors: Gavin Andresen Status: Closed Type: Specification Assigned: 2011-10-18 Table of ContentsAbstractMotivationSpecificationRationaleBackwards CompatibilityReference ImplementationSee Also Abstract This BIP describes a new opcode (OP_EVAL) for the 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 the item is not a valid script th...
50 - March 2013 Chain Fork Post-Mortem
BIP: 50 source Title: March 2013 Chain Fork Post-Mortem Authors: Gavin Andresen Status: Deployed Type: Informational Assigned: 2013-03-20 License: PD Table of ContentsWhat went wrongWhat went rightRoot causeAction itemsImmediatelyAlert systemSafe modeTestingDouble spendingResolutionCopyright 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...
16 - Pay to Script Hash
BIP: 16 source Layer: Consensus (soft fork) Title: Pay to Script Hash Authors: Gavin Andresen Status: Deployed Type: Specification Assigned: 2012-01-03 Table of ContentsAbstractMotivationSpecificationRationaleBackwards Compatibility520-byte limitation on serialized script sizeReference ImplementationSee AlsoReferences 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_HA...
101 - Increase maximum block size
BIP: 101 source Layer: Consensus (hard fork) Title: Increase maximum block size Authors: Gavin Andresen Status: Closed Type: Specification Assigned: 2015-06-22 Table of ContentsAbstractMotivationSpecificationDeploymentTest networkRationaleObjections to this proposalCentralization of full nodesCentralization of mining: costsCentralization of mining: big-block attacksUnspent Transaction Output GrowthLong-term fee incentivesOther solutions consideredOne-time increaseDynamic limit proposalsCompatibilityImplementation 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 Deploymen...
70 - Payment Protocol
BIP: 70 source Layer: Applications Title: Payment Protocol Authors: Gavin Andresen Mike Hearn Status: Deployed Type: Specification Assigned: 2013-07-29 Table of ContentsAbstractMotivationProtocolMessagesOutputPaymentDetails/PaymentRequestPaymentPaymentACKLocalizationCertificatesExtensibilityReferencesReference implementationSee Also 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: lin...
106 - Dynamically Controlled Bitcoin Block Size Max Cap
BIP: 106 source Layer: Consensus (hard fork) Title: Dynamically Controlled Bitcoin Block Size Max Cap Authors: Upal Chakraborty Status: Closed Type: Specification Assigned: 2015-08-24 Table of ContentsAbstractMotivationSpecificationProposal 1 : Depending only on previous block size calculationProposal 2 : Depending on previous block size calculation and previous Tx fee collected by minersRationaleProposal 1 : Depending only on previous block size calculationProposal 2 : Depending on previous block size calculation and previous Tx fee collected by minersCompatibilityOther solutions consideredDeployment 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 fe...
123 - BIP Classification
BIP: 123 source Title: BIP Classification Authors: Eric Lombrozo Status: Deployed Type: Process Assigned: 2015-08-26 License: CC0-1.0 OR FSFAP Table of ContentsAbstractCopyrightMotivationSpecification1. Consensus LayerSoft ForksHard Forks2. Peer Services Layer3. API/RPC Layer4. Applications LayerClassification of existing BIPs 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 FSF 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 implementers a choice of whether to su...