BIPs bitcoin improvement proposals

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

<pre> BIP: 19 Layer: Applications Title: M-of-N Standard Transactions (Low SigOp) Author: Luke Dashjr <luke+bip17@dashjr.org> 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 </pre> ==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...

145 - getblocktemplate Updates for Segregated Witness

<pre> BIP: 145 Layer: API/RPC Title: getblocktemplate Updates for Segregated Witness Author: Luke Dashjr <luke+bip22@dashjr.org> 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 </pre> ==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 s...

17 - OP_CHECKHASHVERIFY (CHV)

<pre> BIP: 17 Layer: Consensus (soft fork) Title: OP_CHECKHASHVERIFY (CHV) Author: Luke Dashjr <luke+bip17@dashjr.org> 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 </pre> ==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...

20 - URI Scheme

<pre> BIP: 20 Layer: Applications Title: URI Scheme Author: Luke Dashjr <luke+bip@dashjr.org> 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 </pre> 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 decis...

115 - Generic anti-replay protection using Script

<pre> BIP: 115 Layer: Consensus (soft fork) Title: Generic anti-replay protection using Script Author: Luke Dashjr <luke+bip@dashjr.org> 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 </pre> ==Abstract== This BIP describes a new opcode (<code>OP_CHECKBLOCKATHEIGHT</code>) 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== <code>OP_CHECKBLOCKATHEIGHT</code> redefines the existing <code>OP_NOP5</code> 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 (ParamHe...

18 - hashScriptCheck

<pre> BIP: 18 Layer: Consensus (soft fork) Title: hashScriptCheck Author: Luke Dashjr <luke+bip17@dashjr.org> 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 </pre> ==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 copi...

180 - Block size/weight fraud proof

<pre> BIP: 180 Layer: Peer Services Title: Block size/weight fraud proof Author: Luke Dashjr <luke+bip@dashjr.org> 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 </pre> ==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: ...

171 - Currency/exchange rate information API

<pre> BIP: 171 Layer: Applications Title: Currency/exchange rate information API Author: Luke Dashjr <luke+bip@dashjr.org> 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 </pre> ==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 authenti...

22 - getblocktemplate - Fundamentals

<pre> BIP: 22 Layer: API/RPC Title: getblocktemplate - Fundamentals Author: Luke Dashjr <luke+bip22@dashjr.org> 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 </pre> ==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"]]....

23 - getblocktemplate - Pooled Mining

<pre> BIP: 23 Layer: API/RPC Title: getblocktemplate - Pooled Mining Author: Luke Dashjr <luke+bip22@dashjr.org> 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 </pre> ==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...

2 - BIP process, revised

<pre> BIP: 2 Title: BIP process, revised Author: Luke Dashjr <luke+bip@dashjr.org> 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 </pre> ==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 hi...

8 - Version bits with lock-in by height

<pre> BIP: 8 Title: Version bits with lock-in by height Author: Shaolin Fry <shaolinfry@protonmail.ch> Luke Dashjr <luke+bip@dashjr.org> 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 </pre> ==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 depl...

179 - Name for payment recipient identifiers

<pre> BIP: 179 Title: Name for payment recipient identifiers Author: Emil Engler <me@emilengler.com> MarcoFalke <falke.marco@gmail.com> Luke Dashjr <luke+bip@dashjr.org> 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 </pre> ==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 th...

21 - URI Scheme

<pre> BIP: 21 Layer: Applications Title: URI Scheme Author: Nils Schneider <nils.schneider@gmail.com> Matt Corallo <bip21@bluematt.me> 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 </pre> 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 i...

343 - Mandatory activation of taproot deployment

<pre> BIP: 343 Layer: Consensus (soft fork) Title: Mandatory activation of taproot deployment Author: Shinobius <quantumedusa@gmail.com> Michael Folkson <michaelfolkson@gmail.com> 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 </pre> ==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 incl...

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