BIPs bitcoin improvement proposals

113 - Median time-past as endpoint for lock-time calculations

<pre> BIP: 113 Layer: Consensus (soft fork) Title: Median time-past as endpoint for lock-time calculations Author: Thomas Kerin <me@thomaskerin.io> Mark Friedenbach <mark@friedenbach.org> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0113 Status: Final Type: Standards Track Created: 2015-08-10 License: PD </pre> ==Abstract== This BIP is a proposal to redefine the semantics used in determining a time-locked transaction's eligibility for inclusion in a block. The median of the last 11 blocks is used instead of the block's timestamp, ensuring that it increases monotonically with each block. ==Motivation== At present, transactions are excluded from inclusion in a block if the present time or block height is less than or equal to that specified in the locktime. Since the consensus rules do not mandate strict ordering of block timestamps, this has the unfortunate outcome of creating a perverse incentive ...

116 - MERKLEBRANCHVERIFY

<pre> BIP: 116 Layer: Consensus (soft fork) Title: MERKLEBRANCHVERIFY Author: Mark Friedenbach <mark@friedenbach.org> Kalle Alm <kalle.alm@gmail.com> BtcDrak <btcdrak@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0116 Status: Draft Type: Standards Track Created: 2017-08-25 License: CC-BY-SA-4.0 License-Code: MIT </pre> ==Abstract== A general approach to bitcoin contracts is to fully enumerate the possible spending conditions and then program verification of these conditions into a single script. At redemption, the spending condition used is explicitly selected, e.g. by pushing a value on the witness stack which cascades through a series if if/else constructs. This approach has significant downsides, such as requiring all program pathways to be visible in the scriptPubKey or redeem script, even those which are not used at validation. This wastes space on the block chain, restrict...

117 - Tail Call Execution Semantics

<pre> BIP: 117 Layer: Consensus (soft fork) Title: Tail Call Execution Semantics Author: Mark Friedenbach <mark@friedenbach.org> Kalle Alm <kalle.alm@gmail.com> BtcDrak <btcdrak@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0117 Status: Draft Type: Standards Track Created: 2017-08-25 License: CC-BY-SA-4.0 License-Code: MIT </pre> ==Abstract== BIP16 (Pay to Script Hash)[1] and BIP141 (Segregated Witness)[2] provide mechanisms by which script policy can be revealed at spend time as part of the execution witness. In both cases only a single script can be committed to by the construct. While useful for achieving the goals of these proposals, they still require that all policies be specified within the confine of a single script, regardless of whether the policies are needed at the time of spend. This BIP, in conjunction with BIP116 (MERKLEBRANCHVERIFY)[3] allows for a script to comm...

112 - CHECKSEQUENCEVERIFY

<pre> BIP: 112 Layer: Consensus (soft fork) Title: CHECKSEQUENCEVERIFY Author: BtcDrak <btcdrak@gmail.com> Mark Friedenbach <mark@friedenbach.org> Eric Lombrozo <elombrozo@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0112 Status: Final Type: Standards Track Created: 2015-08-10 License: PD </pre> ==Abstract== This BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin scripting system that in combination with BIP 68 allows execution pathways of a script to be restricted based on the age of the output being spent. ==Summary== CHECKSEQUENCEVERIFY redefines the existing NOP3 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 top item on the stack has the disable flag (1 << 31) unset; and ** the transaction version is less tha...

98 - Fast Merkle Trees

<pre> BIP: 98 Layer: Consensus (soft fork) Title: Fast Merkle Trees Author: Mark Friedenbach <mark@friedenbach.org> Kalle Alm <kalle.alm@gmail.com> BtcDrak <btcdrak@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0098 Status: Draft Type: Standards Track Created: 2017-08-24 License: CC-BY-SA-4.0 License-Code: MIT </pre> ==Abstract== In many applications it is useful to prove membership of a data element in a set without having to reveal the entire contents of that set. The Merkle hash-tree, where inner/non-leaf nodes are labeled with the hash of the labels or values of its children, is a cryptographic tool that achieves this goal. Bitcoin uses a Merkle hash-tree construct for committing the transactions of a block into the block header. This particular design, created by Satoshi, suffers from a serious flaw related to duplicate entries documented in the National Vulnerability Databa...

68 - Relative lock-time using consensus-enforced sequence numbers

<pre> BIP: 68 Layer: Consensus (soft fork) Title: Relative lock-time using consensus-enforced sequence numbers Author: Mark Friedenbach <mark@friedenbach.org> BtcDrak <btcdrak@gmail.com> Nicolas Dorier <nicolas.dorier@gmail.com> kinoshitajona <kinoshitajona@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0068 Status: Final Type: Standards Track Created: 2015-05-28 </pre> ==Abstract== This BIP introduces relative lock-time (RLT) consensus-enforced semantics of the sequence number field to enable a signed transaction input to remain invalid for a defined period of time after confirmation of its corresponding outpoint. ==Motivation== Bitcoin transactions have a sequence number field for each input. The original idea appears to have been that a transaction in the mempool would be replaced by using the same input with a higher sequence value. Although this was not properly imple...

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