320 - nVersion bits for general purpose use
BIP: 320 source Title: nVersion bits for general purpose use Author: BtcDrak Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0320 Status: Draft Type: Standards Track Created: 2018-03-01 License: BSD-3-Clause CC0-1.0 Table of ContentsAbstractMotivationExample UsesSpecificationReference ImplementationBackwards CompatibilityAcknowledgementsReferencesCopyright Abstract This BIP reserves 16 bits of the block header nVersion field for general purpose use and removes their meaning for the purpose of version bits soft-fork signalling. 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 There are a variety of things that miners may desire to use some of the nVersion field bits for. However, due to their use to coordinate miner activated soft-forks, full node softwar...
105 - Consensus based block size retargeting algorithm
BIP: 105 source Layer: Consensus (hard fork) Title: Consensus based block size retargeting algorithm Author: BtcDrak Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0105 Status: Rejected Type: Standards Track Created: 2015-08-21 License: PD Table of ContentsAbstractMotivationRationaleSpecificationAcknowledgementsReferencesCopyright Abstract A method of altering the maximum allowed block size of the Bitcoin protocol using a consensus based approach. Motivation There is a belief that Bitcoin cannot easily respond to raising the blocksize limit if popularity was to suddenly increase due to a mass adoption curve, because co-ordinating a hard fork takes considerable time, and being unable to respond in a timely manner would irreparably harm the credibility of bitcoin. Additionally, predetermined block size increases are problematic because they attempt to predict the future, and if too large could have unintended consequ...
116 - MERKLEBRANCHVERIFY
BIP: 116 source Layer: Consensus (soft fork) Title: MERKLEBRANCHVERIFY Author: Mark Friedenbach Kalle Alm BtcDrak 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 Table of ContentsAbstractCopyrightSpecificationMotivationRationaleApplications1-of-N for large NHoneypotsImplementationDeploymentCompatibilityReferences 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 whic...
112 - CHECKSEQUENCEVERIFY
BIP: 112 source Layer: Consensus (soft fork) Title: CHECKSEQUENCEVERIFY Author: BtcDrak Mark Friedenbach Eric Lombrozo 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 Table of ContentsAbstractSummaryMotivationContracts With Expiration DeadlinesEscrow with TimeoutRetroactive InvalidationHash Time-Locked ContractsBidirectional Payment ChannelsLightning Network2-Way Pegged SidechainsSpecificationReference ImplementationDeploymentCreditsReferencesCopyright 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 w...
68 - Relative lock-time using consensus-enforced sequence numbers
BIP: 68 source Layer: Consensus (soft fork) Title: Relative lock-time using consensus-enforced sequence numbers Author: Mark Friedenbach BtcDrak Nicolas Dorier kinoshitajona 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 Table of ContentsAbstractMotivationSpecificationImplementationAcknowledgmentsDeploymentCompatibilityReferences 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 impl...
117 - Tail Call Execution Semantics
BIP: 117 source Layer: Consensus (soft fork) Title: Tail Call Execution Semantics Author: Mark Friedenbach Kalle Alm BtcDrak 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 Table of ContentsAbstractCopyrightSpecificationMotivationRationaleGeneralized MASTComparison with BIP114ImplementationDeploymentCompatibilityReferences 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 ...
98 - Fast Merkle Trees
BIP: 98 source Layer: Consensus (soft fork) Title: Fast Merkle Trees Author: Mark Friedenbach Kalle Alm BtcDrak 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 Table of ContentsAbstractCopyrightMotivationSpecificationRationaleInclusion ProofsExampleRationaleFast Merkle ListsImplementationDeploymentCompatibilityReferences 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 s...
67 - Deterministic Pay-to-script-hash multi-signature addresses through public key sorting
BIP: 67 source Layer: Applications Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting Author: Thomas Kerin Jean-Pierre Rupp Ruben de Vries Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0067 Status: Proposed Type: Standards Track Created: 2015-02-08 License: PD Table of ContentsAbstractMotivationSpecificationCompatibilityTest vectorsAcknowledgementsUsage & ImplementationsReferencesCopyright Abstract This BIP describes a method to deterministically generate multi-signature pay-to-script-hash transaction scripts. It focuses on defining how the public keys must be encoded and sorted so that the redeem script and corresponding P2SH address are always the same for a given set of keys and number of required signatures. Motivation Pay-to-script-hash (BIP-0011[1]) is a transaction type that allows funding of arbitrary scripts, where the recipient carries the...
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...