BIPs bitcoin improvement proposals

173 - Base32 address format for native v0-16 witness outputs

<pre> BIP: 173 Layer: Applications Title: Base32 address format for native v0-16 witness outputs Author: Pieter Wuille <pieter.wuille@gmail.com> Greg Maxwell <greg@xiph.org> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0173 Status: Final Type: Informational Created: 2017-03-20 License: BSD-2-Clause Replaces: 142 </pre> ==Introduction== ===Abstract=== This document proposes a checksummed base32 format, "Bech32", and a standard for native segregated witness output addresses using it. ===Copyright=== This BIP is licensed under the 2-clause BSD license. ===Motivation=== For most of its history, Bitcoin has relied on base58 addresses with a truncated double-SHA256 checksum. They were part of the original software and their scope was extended in [https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki BIP13] for Pay-to-script-hash ([https://github.com/bitcoin/bips/blob/master/bip-0016.mediawik...

9 - Version bits with timeout and delay

<pre> BIP: 9 Title: Version bits with timeout and delay Author: Pieter Wuille <pieter.wuille@gmail.com> Peter Todd <pete@petertodd.org> Greg Maxwell <greg@xiph.org> Rusty Russell <rusty@rustcorp.com.au> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0009 Status: Final Type: Informational Created: 2015-10-04 License: PD </pre> ==Abstract== This document specifies a proposed change to the semantics of the 'version' field in Bitcoin blocks, allowing multiple backward-compatible changes (further called "soft forks") to be deployed in parallel. It relies on interpreting the version field as a bit vector, where each bit can be used to track an independent change. These are tallied each retarget period. Once the consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes. ==Motivation== [[bip-0034.mediawiki|BIP 34]] introduced a mech...

90 - Buried Deployments

<pre> BIP: 90 Title: Buried Deployments Author: Suhas Daftuar <sdaftuar@chaincode.com> Comments-Summary: Mostly Recommended for implementation, with some Discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0090 Status: Final Type: Informational Created: 2016-11-08 License: PD </pre> ==Abstract== Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner signaling in block version numbers. Now that the chain has long since passed the blocks at which those consensus rules have triggered, we can (as a simplification) replace the trigger mechanism by caching the block heights at which those consensus rules became enforced. ==Motivation== BIPs 34, 65 and 66 were deployed on mainnet using miner signaling using block version numbers. In short, new consensus rules were proposed for use in blocks with a higher version number (N+1) than the prevailing block version (N) in use on the network, and those rules became enforced under the...

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

66 - Strict DER signatures

<pre> BIP: 66 Layer: Consensus (soft fork) Title: Strict DER signatures Author: Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0066 Status: Final Type: Standards Track Created: 2015-01-10 License: BSD-2-Clause </pre> ==Abstract== This document specifies proposed changes to the Bitcoin transaction validity rules to restrict signatures to strict DER encoding. ==Copyright== This BIP is licensed under the 2-clause BSD license. ==Motivation== Bitcoin's reference implementation currently relies on OpenSSL for signature validation, which means it is implicitly defining Bitcoin's block validity rules. Unfortunately, OpenSSL is not designed for consensus-critical behaviour (it does not guarantee bug-for-bug compatibility between versions), and thus changes to it can - and have - affected Bitcoin software. One specifically critical area is the encoding of signatures. Until recen...