BIPs bitcoin improvement proposals

65 - OP_CHECKLOCKTIMEVERIFY

<pre> BIP: 65 Layer: Consensus (soft fork) Title: OP_CHECKLOCKTIMEVERIFY Author: Peter Todd <pete@petertodd.org> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0065 Status: Final Type: Standards Track Created: 2014-10-01 License: PD </pre> ==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; or * the top item on the stack is less than 0; or * the lock-time type (height vs. timestamp) of the top stack item and the nLockTime field are not the same; or * the top stack item is greater than the transaction's nLockTime field; or * the nSequence field of the txin is 0xffffffff; Ot...

111 - NODE_BLOOM service bit

<pre> BIP: 111 Layer: Peer Services Title: NODE_BLOOM service bit Author: Matt Corallo <bip111@bluematt.me> Peter Todd <pete@petertodd.org> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0111 Status: Proposed Type: Standards Track Created: 2015-08-20 License: PD </pre> == 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<ref>http://...

125 - Opt-in Full Replace-by-Fee Signaling

<pre> BIP: 125 Layer: Applications Title: Opt-in Full Replace-by-Fee Signaling Author: David A. Harding <dave@dtrt.org> Peter Todd <pete@petertodd.org> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0125 Status: Proposed Type: Standards Track Created: 2015-12-04 License: PD </pre> ==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 this signal, * Nodes may allow transactions containing this signal to be replaced in their mempools. * The re...

9 - Version bits with timeout and delay

<pre> BIP: 9 Title: Version bits with timeout and delay Author: Pieter Wuille <pieter.wuille@gmail.com> Peter Todd <pete@petertodd.org> Greg Maxwell <greg@xiph.org> Rusty Russell <rusty@rustcorp.com.au> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0009 Status: Final Type: Informational Created: 2015-10-04 License: PD </pre> ==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-0034.mediawiki|BIP 34]] introduced a mech...

147 - Dealing with dummy stack element malleability

<pre> BIP: 147 Layer: Consensus (soft fork) Title: Dealing with dummy stack element malleability Author: Johnson Lau <jl2012@xbt.hk> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0147 Status: Final Type: Standards Track Created: 2016-09-02 License: PD </pre> ==Abstract== This document specifies proposed changes to the Bitcoin transaction validity rules to fix a malleability vector in the extra stack element consumed by <code>OP_CHECKMULTISIG</code> and <code>OP_CHECKMULTISIGVERIFY</code>. ==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 <code>txid</code> and invalidate any unconfirmed child transactions. Although the <code>txid</code> of segregated witness ([https://github.com/bitcoin/bips/b...

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

66 - Strict DER signatures

<pre> BIP: 66 Layer: Consensus (soft fork) Title: Strict DER signatures Author: Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0066 Status: Final Type: Standards Track Created: 2015-01-10 License: BSD-2-Clause </pre> ==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 recen...