111 - NODE_BLOOM service bit
BIP: 111 source Layer: Peer Services Title: NODE_BLOOM service bit Authors: Matt Corallo Peter Todd Status: Deployed Type: Specification Assigned: 2015-08-20 License: PD Table of ContentsAbstractMotivationSpecificationDesign rationalReference ImplementationCopyrightReferences Abstract This BIP extends BIP 37, Connection Bloom filtering, by defining a service bit to allow peers to advertise that they support bloom filters explicitly. It also bumps the protocol version to allow peers to identify old nodes which allow bloom filtering of the connection despite lacking the new service bit. Motivation BIP 37 did not specify a service bit for the bloom filter service, thus implicitly assuming that all nodes that serve peers data support it. However, the connection filtering algorithm proposed in BIP 37, and implemented in several clients today, has been shown to provide little to no privacy[1], as well as being a large DoS risk on some nodes[2]. Thus, allowing no...
125 - Opt-in Full Replace-by-Fee Signaling
BIP: 125 source Layer: Applications Title: Opt-in Full Replace-by-Fee Signaling Authors: David A. Harding Peter Todd Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0125 Status: Deployed Type: Specification Assigned: 2015-12-04 License: PD Table of ContentsAbstractSummaryImplementation DetailsReceiving wallet policySpending wallet policyMotivationDeploymentBackwards compatibilitySee alsoCopyright Abstract Many nodes today will not replace any transaction in their mempool with another transaction that spends the same inputs, making it difficult for spenders to adjust their previously-sent transactions to deal with unexpected confirmation delays or to perform other useful replacements. The opt-in full Replace-by-Fee (opt-in full-RBF) signaling policy described here allows spenders to add a signal to a transaction indicating that they want to be able to replace that transaction in the future. In response to ...
147 - Dealing with dummy stack element malleability
BIP: 147 source Layer: Consensus (soft fork) Title: Dealing with dummy stack element malleability Authors: Johnson Lau Status: Deployed Type: Specification Assigned: 2016-09-02 License: PD Table of ContentsAbstractMotivationSpecificationDeploymentCompatibilityImplementationAcknowledgementsCopyright Abstract This document specifies proposed changes to the Bitcoin transaction validity rules to fix a malleability vector in the extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY. Motivation Signature malleability refers to the ability of any relay node on the network to transform the signature in transactions, with no access to the relevant private keys required. For non-segregated witness transactions, signature malleability will change the txid and invalidate any unconfirmed child transactions. Although the txid of segregated witness (BIP141) transactions is not third party malleable, this malleability vector will change the wtxid and may reduce ...
65 - OP_CHECKLOCKTIMEVERIFY
BIP: 65 source Layer: Consensus (soft fork) Title: OP_CHECKLOCKTIMEVERIFY Authors: Peter Todd Status: Deployed Type: Specification Assigned: 2014-10-01 License: PD Table of ContentsAbstractSummaryMotivationEscrowNon-interactive time-locked refundsTwo-factor walletsPayment ChannelsTrustless Payments for Publishing DataProving sacrifice to miners' feesFreezing FundsReplacing the nLockTime field entirelyDetailed SpecificationDeploymentSPV ClientsCreditsReferencesImplementationsCopyright Abstract This BIP describes a new opcode (OP_CHECKLOCKTIMEVERIFY) for the Bitcoin scripting system that allows a transaction output to be made unspendable until some point in the future. Summary CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode. When executed, if any of the following conditions are true, the script interpreter will terminate with an error: the stack is empty; orthe top item on the stack is less than 0; orthe lock-time type (height vs. timestamp) of the top stack...
9 - Version bits with timeout and delay
BIP: 9 source Title: Version bits with timeout and delay Authors: Pieter Wuille Peter Todd Greg Maxwell Rusty Russell Status: Deployed Type: Informational Assigned: 2015-10-04 License: PD Table of ContentsAbstractMotivationSpecificationSelection guidelinesStatesBit flagsNew consensus rulesState transitionsWarning mechanismgetblocktemplate changesSupport for future changesRationaleDeploymentsCopyright Abstract This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called "soft forks") to be deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes. Motivation BIP 34 introduced a mechanism fo...
372 - Pay-to-contract tweak fields for PSBT
BIP: 372 source Layer: Applications Title: Pay-to-contract tweak fields for PSBT Authors: Maxim Orlovsky Status: Draft Type: Specification Assigned: 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 (P2C) key tweaking data to be included in a PSBT of any version. These will represent 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 a message using elliptic curve properties. The procedure uses the discrete log problem (DLP) to commit to an extr...
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...
66 - Strict DER signatures
BIP: 66 source Layer: Consensus (soft fork) Title: Strict DER signatures Authors: Pieter Wuille Status: Deployed Type: Specification Assigned: 2015-01-10 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecificationDER encoding referenceExamplesDeploymentCompatibilityImplementationAcknowledgementsDisclosures Abstract This document specifies proposed changes to the Bitcoin transaction validity rules to restrict signatures to strict DER encoding. Copyright This BIP is licensed under the 2-clause BSD license. Motivation Bitcoin's reference implementation currently relies on OpenSSL for signature validation, which means it is implicitly defining Bitcoin's block validity rules. Unfortunately, OpenSSL is not designed for consensus-critical behaviour (it does not guarantee bug-for-bug compatibility between versions), and thus changes to it can - and have - affected Bitcoin software. One specifically critical area is the encoding of signatures. Until recently...