BIPs bitcoin improvement proposals

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

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

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