BIPs bitcoin improvement proposals

179 - Name for payment recipient identifiers

BIP: 179 source 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 Table of ContentsAbstractSpecificationMotivationRationaleBackwards CompatibilityAcknowledgementsCopyright 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 t...

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

BIP: 19 source 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 Table of ContentsAbstractCopyrightMotivationSpecificationTemplatesRationaleImplementation 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 ...

145 - getblocktemplate Updates for Segregated Witness

BIP: 145 source 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 Table of ContentsAbstractSpecificationBlock TemplateTransactions Object FormatSigopsBlock Assembly with Witness TransactionsMotivationRationaleReference ImplementationSee AlsoCopyright Abstract This BIP describes modifications to the getblocktemplate JSON-RPC call (BIP 22) to support segregated witness as defined by BIP 141. Specification Block Template The template Object is revised to include a new key: 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 "se...

17 - OP_CHECKHASHVERIFY (CHV)

BIP: 17 source 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 Table of ContentsAbstractCopyrightMotivationSpecificationExampleRationaleBackwards CompatibilityReference ImplementationSee Also 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 complicat...

20 - URI Scheme

BIP: 20 source 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 Table of ContentsAbstractCopyrightMotivationSpecificationGeneral rules for handling (important!)Operating system integrationBNF grammarQuery KeysTransfer amount/sizeRationalePayment identifiers, not person identifiersAccessibility (URI scheme name)Forward compatibilityAppendixSimpler syntaxExamplesSending money via private keyReference ImplementationsBitcoin clientsParsing amountECMAScriptPythonC# 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 c...

115 - Generic anti-replay protection using Script

BIP: 115 source 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 Table of ContentsAbstractCopyrightSpecificationDeploymentMotivationSecurely recovering from double spendsReplay protection in the event of a persistent blockchain splitBest practices for walletsRationaleBackwards CompatibilityReference Implementation 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 to...

18 - hashScriptCheck

BIP: 18 source 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 Table of ContentsAbstractCopyrightMotivationSpecificationSignature operation limits for scriptCheckRationaleBackwards CompatibilityForwards CompatibilityReference ImplementationSee Also 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 arbi...

180 - Block size/weight fraud proof

BIP: 180 source 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 Table of ContentsAbstractCopyrightDefinitionsSpecificationProof formatProof verificationNetwork protocolInformationCreation of proofsMotivationRationaleBackwards compatibilityReference implementation 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 se...

22 - getblocktemplate - Fundamentals

BIP: 22 source 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 Table of ContentsAbstractCopyrightSpecificationBlock Template RequestTransactions Object FormatBlock SubmissionOptional: Long PollingOptional: Template TweakingAppendix: Example Rejection ReasonsMotivationRationaleReference ImplementationSee Also 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...

23 - getblocktemplate - Pooled Mining

BIP: 23 source 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 Table of ContentsAbstractCopyrightSpecificationSummary Support LevelsBasic Pool ExtensionsBlock ProposalMutationsSubmission AbbreviationFormat of Data for Merkle-Only SharesLogical ServicesMotivationRationaleReference ImplementationSee Also 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 22. Summary Support Levels Something can be said to have BIP 23 Level 1 support if it implements at least: RFC 1945JSON-RPC 1.0BIP 22 (non-optional sections)BIP 22 Long PollingBIP 23 Basic Pool ...

171 - Currency/exchange rate information API

BIP: 171 source 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 Table of ContentsAbstractCopyrightSpecificationEnumerating supported currency-pair tokensCurrency-pair informationCurrent exchange rateHistorical exchange ratesMotivationRationaleBackwards compatibilityReference implementationSee also 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 ...

8 - Version bits with lock-in by height

BIP: 8 source 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 Table of ContentsAbstractMotivationSpecificationParametersSelection guidelinesStatesBit flagsNew consensus rulesState transitionsMandatory signallingWarning mechanismgetblocktemplate changesReference implementationContrasted with BIP 9Backwards compatibilityDeploymentsReferencesCopyright Abstract This document specifies an alternative to 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", "SH...

2 - BIP process, revised

BIP: 2 source 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 Table of ContentsAbstractCopyrightBIP workflowTransferring BIP OwnershipBIP EditorsBIP Editor Responsibilities & WorkflowBIP format and structureSpecificationBIP header preambleAuxiliary FilesBIP typesBIP status fieldSpecificationProgression to Final statusRationaleBIP commentsSpecificationRationaleBIP licensingSpecificationRecommended licensesNot recommended, but acceptable licensesNot acceptable licensesRationaleChanges from BIP 1See Also 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 ratio...

21 - URI Scheme

BIP: 21 source 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 by Luke Dashjr. BIP 0020 was based off an earlier document by Nils Schneider. The alternative payment amounts in BIP 0020 have been removed. Table of ContentsAbstractMotivationSpecificationGeneral rules for handling (important!)Operating system integrationGeneral FormatABNF grammarQuery KeysTransfer amountRationalePayment identifiers, not person identifiersAccessibility (URI scheme name)Forward compatibilityBackward compatibilityAppendixSimpler syntaxExamplesReference Implementation 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 webp...

343 - Mandatory activation of taproot deployment

BIP: 343 source 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: Final Type: Standards Track Created: 2021-04-25 License: BSD-3-Clause CC0-1.0 Table of ContentsAbstractMotivationSpecificationReference implementationBackward CompatibilityCompatibility with later alternative activationsRationaleAcknowledgementsReferencesCopyright 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...

123 - BIP Classification

BIP: 123 source 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 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 GNU All-Permissive licenses. Motivation Bitcoin is a system involving a number of different standards. Some standards are abso...

372 - Pay-to-contract tweak fields for PSBT

BIP: 372 source 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 Table of ContentsIntroductionAbstractCopyrightBackgroundMotivationDesignSpecificationSecurity considerationsRationaleCompatibilityReference implementationAcknowledgementsTest vectorsReferences Introduction Abstract This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2 that allow for pay-to-contract key tweaking 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 ellipti...