BIPs bitcoin improvement proposals

19 - M-of-N Standard Transactions (Low SigOp)

BIP: 19 Layer: Applications Title: M-of-N Standard Transactions (Low SigOp) Author: Luke Dashjr Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0019 Status: Rejected Type: Standards Track Created: 2012-01-30 License: BSD-2-Clause ==Abstract== This BIP proposes M-of-N-signatures required transactions as a new 'standard' transaction type using the existing scripting system without significant modifications. ==Copyright== This BIP is licensed under the BSD 2-clause license. ==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 use...

145 - getblocktemplate Updates for Segregated Witness

BIP: 145 Layer: API/RPC Title: getblocktemplate Updates for Segregated Witness Author: Luke Dashjr Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0145 Status: Final Type: Standards Track Created: 2016-01-30 License: BSD-2-Clause OPL ==Abstract== This BIP describes modifications to the getblocktemplate JSON-RPC call ([[bip-0022.mediawiki|BIP 22]]) to support segregated witness as defined by [[bip-0141.mediawiki|BIP 141]]. ==Specification== ===Block Template=== The template Object is revised to include a new key: {| class="wikitable" !colspan=4| template |- ! Key !! Required !! Type !! Description |- | weightlimit || No || Number || total weight allowed in blocks |} The '!' rule prefix MUST be enabled on the "segwit" rule for templates including transactions with witness data. In particular, note that even if the client's "rules" list lacks "segwit", server MAY support old miners by producing a witness-free te...

17 - OP_CHECKHASHVERIFY (CHV)

BIP: 17 Layer: Consensus (soft fork) Title: OP_CHECKHASHVERIFY (CHV) Author: Luke Dashjr Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0017 Status: Withdrawn Type: Standards Track Created: 2012-01-18 License: BSD-2-Clause ==Abstract== This BIP describes a new opcode (OP_CHECKHASHVERIFY) 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. ==Copyright== This BIP is licensed under the BSD 2-clause license. ==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== OP...

20 - URI Scheme

BIP: 20 Layer: Applications Title: URI Scheme Author: Luke Dashjr Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0020 Status: Replaced Type: Standards Track Created: 2011-01-10 License: BSD-2-Clause BIP 0020 is based off an earlier document by Nils Schneider. '''And has been replaced by BIP 0021''' ==Abstract== This BIP proposes a URI scheme for making Bitcoin payments. ==Copyright== This BIP is licensed under the BSD 2-clause license. ==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 decision. === Operating system integration === Graph...

115 - Generic anti-replay protection using Script

BIP: 115 Layer: Consensus (soft fork) Title: Generic anti-replay protection using Script Author: Luke Dashjr Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0115 Status: Rejected Type: Standards Track Created: 2016-09-23 License: BSD-2-Clause ==Abstract== This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin scripting system that allows construction of transactions which are valid only on specific blockchains. ==Copyright== This BIP is licensed under the BSD 2-clause license. ==Specification== OP_CHECKBLOCKATHEIGHT redefines the existing OP_NOP5 opcode. When this opcode is executed: * If the stack has fewer than 2 elements, the script fails. * If the top item on the stack cannot be interpreted as a minimal-length 32-bit CScriptNum, the script fails. * The top item on the stack is interpreted as a block height (ParamHeight). * If the blockchain (in the context of the execution) does not have ParamHeight ...

18 - hashScriptCheck

BIP: 18 Layer: Consensus (soft fork) Title: hashScriptCheck Author: Luke Dashjr Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0018 Status: Proposed Type: Standards Track Created: 2012-01-27 License: BSD-2-Clause ==Abstract== This BIP modifies the basic format of transaction inputs and outputs, replacing the current scriptSig and scriptPubKey (scripts executed to validate a transaction) with new contents: dataSig, scriptCheck, and hashScriptCheck. ==Copyright== This BIP is licensed under the BSD 2-clause license. ==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== scriptSig and scr...

180 - Block size/weight fraud proof

BIP: 180 Layer: Peer Services Title: Block size/weight fraud proof Author: Luke Dashjr Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0180 Status: Rejected Type: Standards Track Created: 2017-03-17 License: BSD-2-Clause ==Abstract== A fraud proof that enables light clients to detect oversized (or overweight) blocks. ==Copyright== This BIP is licensed under the BSD 2-clause license. ==Definitions== ; full tx size proof : SHA2 midstate and tail data proving the size of the full transaction data being hashed. ; size component : Either a merkle link and height in the merkle tree thereof, or a full tx size proof. ; full-size proof : The set of size components proving the lower-bound size of the block. ; stripped-size proof : The set of size components proving the lower-bound size of the block when stripped of segwit witness data. ==Specification== ===Proof format=== * varint: ceil(log2(number of transactions in block)) * vari...

171 - Currency/exchange rate information API

BIP: 171 Layer: Applications Title: Currency/exchange rate information API Author: Luke Dashjr Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0171 Status: Rejected Type: Standards Track Created: 2017-03-04 License: BSD-2-Clause ==Abstract== A common interface for requesting currency exchange rate information from a server. ==Copyright== This BIP is licensed under the BSD 2-clause license. ==Specification== Four requests are defined, which are all made by a GET request to a common URI with parameters encoded in application/x-www-form-urlencoded format. All matching parameters may be specified with multiple comma-separated values, which are to be interpreted as "any of these". Each result is always in JSON format, with a line-feed (never a carriage-return) separating multiple results. Authentication for subscription-based services MAY be supported using standard HTTP authentication. It is recommended to use TLS (HTTPS) a...

22 - getblocktemplate - Fundamentals

BIP: 22 Layer: API/RPC Title: getblocktemplate - Fundamentals Author: Luke Dashjr Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0022 Status: Final Type: Standards Track Created: 2012-02-28 License: BSD-2-Clause ==Abstract== This BIP describes a new JSON-RPC method for "smart" Bitcoin miners and proxies. Instead of sending a simple block header for hashing, the entire block structure is sent, and left to the miner to (optionally) customize and assemble. ==Copyright== This BIP is licensed under the BSD 2-clause license. ==Specification== ===Block Template Request=== A JSON-RPC method is defined, called "getblocktemplate". It accepts exactly one argument, which MUST be an Object of request parameters. If the request parameters include a "mode" key, that is used to explicitly select between the default "template" request or a [[bip-0023.mediawiki#Block Proposal|"proposal"]]. Block template creation can be influenced by var...

23 - getblocktemplate - Pooled Mining

BIP: 23 Layer: API/RPC Title: getblocktemplate - Pooled Mining Author: Luke Dashjr Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0023 Status: Final Type: Standards Track Created: 2012-02-28 License: BSD-2-Clause ==Abstract== This BIP describes extensions to the getblocktemplate JSON-RPC call to enhance pooled mining. ==Copyright== This BIP is licensed under the BSD 2-clause license. ==Specification== Note that all sections of this specification are optional extensions on top of [[bip-0022.mediawiki|BIP 22]]. ===Summary Support Levels=== Something can be said to have BIP 23 Level 1 support if it implements at least: * [http://www.ietf.org/rfc/rfc1945.txt RFC 1945] * [http://json-rpc.org/wiki/specification JSON-RPC 1.0] * [[bip-0022.mediawiki|BIP 22 (non-optional sections)]] * [[bip-0022.mediawiki#Optional: Long Polling|BIP 22 Long Polling]] * [[#Basic Pool Extensions|BIP 23 Basic Pool Extensions]] * [[#Mutations|BIP 23 ...

2 - BIP process, revised

BIP: 2 Title: BIP process, revised Author: Luke Dashjr Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0002 Status: Active Type: Process Created: 2016-02-03 License: BSD-2-Clause OPL Replaces: 1 ==Abstract== A Bitcoin Improvement Proposal (BIP) is a design document providing information to the Bitcoin community, or describing a new feature for Bitcoin or its processes or environment. The BIP should provide a concise technical specification of the feature and a rationale for the feature. We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions. Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the fe...

179 - Name for payment recipient identifiers

BIP: 179 Title: Name for payment recipient identifiers Author: Emil Engler Luke Dashjr Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0179 Status: Draft Type: Informational Created: 2019-10-17 License: CC0-1.0 ==Abstract== This BIP proposes a new term for 'address' ==Specification== The new term is: ''Bitcoin'' '''Invoice''' ''Address'' The ''Bitcoin'' and ''Address'' parts are optional. The address suffix should only be used as a transitional step. A ''Bitcoin'' Invoice ''Address'' is a string of characters that can be used to indicate the intended recipient and purpose of a transaction. ==Motivation== Bitcoin addresses are intended to be only used '''once''' and you should generate a new one for every new incoming payment. The term 'address' however indicates consistency because nearly everything on the internet or the offline world with the term 'address' is something that rarely or even never changes (po...

8 - Version bits with lock-in by height

BIP: 8 Title: Version bits with lock-in by height Author: Shaolin Fry Luke Dashjr Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0008 Status: Draft Type: Informational Created: 2017-02-01 License: BSD-3-Clause CC0-1.0 ==Abstract== This document specifies an alternative to [[bip-0009.mediawiki|BIP9]] that corrects for a number of perceived mistakes. Block heights are used for start and timeout rather than POSIX timestamps. It additionally introduces an activation parameter that can guarantee activation of backward-compatible changes (further called "soft forks"). 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== BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is...

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...

343 - Mandatory activation of taproot deployment

BIP: 343 Layer: Consensus (soft fork) Title: Mandatory activation of taproot deployment Author: Shinobius Michael Folkson Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0343 Status: Proposed Type: Standards Track Created: 2021-04-25 License: BSD-3-Clause CC0-1.0 ==Abstract== This document specifies a BIP8 (LOT=true) deployment to activate taproot. ==Motivation== The Taproot soft fork upgrade has been assessed to have overwhelming community consensus and hence should attempt to be activated. Lessons have been learned from the BIP148 and BIP91 deployments in 2017 with regards to giving many months of advance warning before the mandatory signaling is attempted. The mandatory signaling is only required if miners have failed to meet the signaling threshold during the BIP8 deployment. It is important that mandatory signaling is included as without it miners would effectively have the ability to indef...

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 ...