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