116 - MERKLEBRANCHVERIFY
BIP: 116 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 ==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, restricts the size of possible scripts due to push limits, and impacts both privacy and...
117 - Tail Call Execution Semantics
BIP: 117 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 ==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 commit to a practically unbounded number of code pathways, and then reveal the actu...
98 - Fast Merkle Trees
BIP: 98 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 ==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 Database as CVE-2012-2459[1], and also suffers from less than optimal performance d...
2 - BIP process, revised
BIP: 2 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 ==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 rationale for the feature. We intend BIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Bitcoin. The BIP author is responsible for building consensus within the community and documenting dissenting opinions. Because the BIPs are maintained as text files in a versioned repository, their revision history is the historical record of the fe...