BIPs bitcoin improvement proposals

30 - Duplicate transactions

<pre> BIP: 30 Layer: Consensus (soft fork) Title: Duplicate transactions Author: Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0030 Status: Final Type: Standards Track Created: 2012-02-22 License: BSD-2-Clause </pre> ==Abstract== This document gives a specification for dealing with duplicate transactions in the block chain, in an attempt to solve certain problems the reference implementation has with them. ==Copyright== This BIP is licensed under the 2-clause BSD license. ==Motivation== So far, the Bitcoin reference implementation always assumed duplicate transactions (transactions with the same identifier) didn't exist. This is not true; in particular coinbases are easy to duplicate, and by building on duplicate coinbases, duplicate normal transactions are possible as well. Recently, an attack that exploits the reference implementation's dealing with duplicate transacti...

42 - A finite monetary supply for Bitcoin

<pre> BIP: 42 Layer: Consensus (soft fork) Title: A finite monetary supply for Bitcoin Author: Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: Unanimously Recommended for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0042 Status: Final Type: Standards Track Created: 2014-04-01 License: PD </pre> ==Abstract== Although it is widely believed that Satoshi was an inflation-hating goldbug he never said this, and in fact programmed Bitcoin's money supply to grow indefinitely, forever. He modeled the monetary supply as 4 gold mines being discovered per mibillenium (1024 years), with equal intervals between them, each one being depleted over the course of 140 years. This poses obvious problems, however. Prominent among them is the discussion on what to call 1 billion Bitcoin, which symbol color to use for it, and when wallet clients should switch to it by default. To combat this, this document proposes a controversial change: ma...

103 - Block size following technological growth

<pre> BIP: 103 Layer: Consensus (hard fork) Title: Block size following technological growth Author: Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0103 Status: Withdrawn Type: Standards Track Created: 2015-07-21 License: BSD-2-Clause </pre> ==Abstract== This BIP proposes a block size growth intended to accommodate for hardware and other technological improvements for the foreseeable future. ==Copyright== This BIP is licensed under the 2-clause BSD license. ==Motivation== Many people want to see Bitcoin scale over time, allowing an increasing number of transactions on the block chain. It would come at an increased cost for the ecosystem (bandwidth, processing, and storage for relay nodes, as well as an impact on propagation speed of blocks on the network), but technology also improves over time. When all technologies depended on have improved as well as their availabili...

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

62 - Dealing with malleability

'''NOTICE: This document is a work in progress and is not complete, implemented, or otherwise suitable for deployment.''' <pre> BIP: 62 Layer: Consensus (soft fork) Title: Dealing with malleability Author: Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0062 Status: Withdrawn Type: Standards Track Created: 2014-03-12 License: BSD-2-Clause </pre> ==Abstract== This document specifies proposed changes to the Bitcoin transaction validity rules in order to make malleability of transactions impossible (at least when the sender doesn't choose to avoid it). ==Copyright== This BIP is licensed under the 2-clause BSD license. ==Motivation== As of february 2014, Bitcoin transactions are malleable in multiple ways. This means a (valid) transaction can be modified in-flight, without invalidating it, but without access to the relevant private keys. This is a problem for multiple reas...

350 - Bech32m format for v1+ witness addresses

<pre> BIP: 350 Layer: Applications Title: Bech32m format for v1+ witness addresses Author: Pieter Wuille <pieter@wuille.net> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0350 Status: Draft Type: Standards Track Created: 2020-12-16 License: BSD-2-Clause Replaces: 173 Post-History: 2021-01-05: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018338.html [bitcoin-dev] Bech32m BIP: new checksum, and usage for segwit address </pre> ==Introduction== ===Abstract=== This document defines an improved variant of Bech32 called '''Bech32m''', and amends BIP173 to use Bech32m for native segregated witness outputs of version 1 and later. Bech32 remains in use for segregated witness outputs of version 0. ===Copyright=== This BIP is licensed under the 2-clause BSD license. ===Motivation=== [[bip-0173.mediawiki|BIP173]] defined a generic checksummed base 32 encoded format called Bech32. It is in use...

32 - Hierarchical Deterministic Wallets

RECENT CHANGES: * (16 Apr 2013) Added private derivation for i ≥ 0x80000000 (less risk of parent private key leakage) * (30 Apr 2013) Switched from multiplication by I<sub>L</sub> to addition of I<sub>L</sub> (faster, easier implementation) * (25 May 2013) Added test vectors * (15 Jan 2014) Rename keys with index ≥ 0x80000000 to hardened keys, and add explicit conversion functions. * (24 Feb 2017) Added test vectors for hardened derivation with leading zeros * (4 Nov 2020) Added new test vectors for hardened derivation with leading zeros <pre> BIP: 32 Layer: Applications Title: Hierarchical Deterministic Wallets Author: Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0032 Status: Final Type: Informational Created: 2012-02-11 License: BSD-2-Clause </pre> ==Abstract== This document describes hierarchical deterministic wallets (or "HD Wallets"): wallets which can be shared par...

385 - raw() and addr() Output Script Descriptors

<pre> BIP: 385 Layer: Applications Title: raw() and addr() Output Script Descriptors Author: Pieter Wuille <pieter@wuille.net> Andrew Chow <andrew@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0385 Status: Draft Type: Informational Created: 2021-06-27 License: BSD-2-Clause </pre> ==Abstract== This document specifies <tt>raw()</tt> and <tt>addr()</tt> output script descriptors. <tt>raw()</tt> encapsulates a raw script as a descriptor. <tt>addr()</tt> encapsulates an address as a descriptor. ==Copyright== This BIP is licensed under the BSD 2-clause license. ==Motivation== In order to make descriptors maximally compatible with scripts in use today, it is useful to be able to wrap any arbitrary output script or an address into a descriptor. ==Specification== Two new script expressions are defined: <tt>raw()</tt> and <tt>addr()</tt>. ===<tt>raw()</tt>=== The <tt>raw(HEX)</tt> expressio...

384 - combo() Output Script Descriptors

<pre> BIP: 384 Layer: Applications Title: combo() Output Script Descriptors Author: Pieter Wuille <pieter@wuille.net> Andrew Chow <andrew@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0384 Status: Draft Type: Informational Created: 2021-06-27 License: BSD-2-Clause </pre> ==Abstract== This document specifies <tt>combo()</tt> output script descriptors. These take a key and produce P2PK, P2PKH, P2WPKH, and P2SH-P2WPKH output scripts if applicable to the key. ==Copyright== This BIP is licensed under the BSD 2-clause license. ==Motivation== In order to make the transition from traditional key based wallets to descriptor based wallets easier, it is useful to be able to take a key and produce the scripts which have traditionally been produced by wallet software. ==Specification== A new top level script expression is defined: <tt>combo(KEY)</tt>. This expression can only be used as a top le...

382 - Segwit Output Script Descriptors

<pre> BIP: 382 Layer: Applications Title: Segwit Output Script Descriptors Author: Pieter Wuille <pieter@wuille.net> Andrew Chow <andrew@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0382 Status: Draft Type: Informational Created: 2021-06-27 License: BSD-2-Clause </pre> ==Abstract== This document specifies <tt>wpkh()</tt>, and <tt>wsh()</tt> output script descriptors. <tt>wpkh()</tt> descriptors take a key and produces a P2WPKH output script. <tt>wsh()</tt> descriptors take a script and produces a P2WSH output script. ==Copyright== This BIP is licensed under the BSD 2-clause license. ==Motivation== Segregated Witness added 2 additional standard output script formats: P2WPKH and P2WSH. These expressions allow specifying those formats as a descriptor. ==Specification== Two new script expressions are defined: <tt>wpkh()</tt>, and <tt>wsh()</tt>. ===<tt>wpkh()</tt>=== The <tt>wpkh(KEY...

381 - Non-Segwit Output Script Descriptors

<pre> BIP: 381 Layer: Applications Title: Non-Segwit Output Script Descriptors Author: Pieter Wuille <pieter@wuille.net> Andrew Chow <andrew@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0381 Status: Draft Type: Informational Created: 2021-06-27 License: BSD-2-Clause </pre> ==Abstract== This document specifies <tt>pk()</tt>, <tt>pkh()</tt>, and <tt>sh()</tt> output script descriptors. <tt>pk()</tt> descriptors take a key and produces a P2PK output script. <tt>pkh()</tt> descriptors take a key and produces a P2PKH output script. <tt>sh()</tt> descriptors take a script and produces a P2SH output script. ==Copyright== This BIP is licensed under the BSD 2-clause license. ==Motivation== Prior to the activation of Segregated Witness, there were 3 main standard output script formats: P2PK, P2PKH, and P2SH. These expressions allow specifying those formats as a descriptor. ==Specification== ...

383 - Multisig Output Script Descriptors

<pre> BIP: 383 Layer: Applications Title: Multisig Output Script Descriptors Author: Pieter Wuille <pieter@wuille.net> Andrew Chow <andrew@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0383 Status: Draft Type: Informational Created: 2021-06-27 License: BSD-2-Clause </pre> ==Abstract== This document specifies <tt>multi()</tt>, and <tt>sortedmulti()</tt> output script descriptors. Both functions take a threshold and one or more public keys and produce a multisig output script. <tt>multi()</tt> specifies the public keys in the output script in the order given in the descriptor while <tt>sortedmulti()</tt> sorts the public keys lexicographically when the output script is produced. ==Copyright== This BIP is licensed under the BSD 2-clause license. ==Motivation== The most common complex script used in Bitcoin is a threshold multisig. These expressions allow specifying multisig scripts as a ...

386 - tr() Output Script Descriptors

<pre> BIP: 386 Layer: Applications Title: tr() Output Script Descriptors Author: Pieter Wuille <pieter@wuille.net> Andrew Chow <andrew@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0386 Status: Draft Type: Informational Created: 2021-06-27 License: BSD-2-Clause </pre> ==Abstract== This document specifies <tt>tr()</tt> output script descriptors. <tt>tr()</tt> descriptors take a key and optionally a tree of scripts and produces a P2TR output script. ==Copyright== This BIP is licensed under the BSD 2-clause license. ==Motivation== Taproot added one additional standard output script format: P2TR. These expressions allow specifying those formats as a descriptor. ==Specification== A new script expression is defined: <tt>tr()</tt>. A new expression is defined: Tree Expressions ===Tree Expression=== A Tree Expression (denoted <tt>TREE</tt>) is an expression which represents a tree of scri...

144 - Segregated Witness (Peer Services)

<pre> BIP: 144 Layer: Peer Services Title: Segregated Witness (Peer Services) Author: Eric Lombrozo <elombrozo@gmail.com> Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0144 Status: Final Type: Standards Track Created: 2016-01-08 License: PD </pre> ==Abstract== This BIP defines new messages and serialization formats for propagation of transactions and blocks committing to segregated witness structures. ==Motivation== In addition to defining witness structures and requiring commitments in future blocks ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141] - Consensus segwit BIP), new mechanisms must be defined to allow peers to advertise support for segregated witness and to relay the witness structures and request them from other peers without breaking compatibility with older nodes. ==Specification== === Serialization === A new serialization ...

146 - Dealing with signature encoding malleability

<pre> BIP: 146 Layer: Consensus (soft fork) Title: Dealing with signature encoding malleability Author: Johnson Lau <jl2012@xbt.hk> Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0146 Status: Withdrawn Type: Standards Track Created: 2016-08-16 License: PD </pre> ==Abstract== This document specifies proposed changes to the Bitcoin transaction validity rules to fix signature malleability related to ECDSA signature encoding. ==Motivation== Signature malleability refers to the ability of any relay node on the network to transform the signature in transactions, with no access to the relevant private keys required. For non-segregated witness transactions, signature malleability will change the <code>txid</code> and invalidate any unconfirmed child transactions. Although the <code>txid</code> of segregated witness ([https://github.com/bitcoin/bips/blob/master/bip-0141...

380 - Output Script Descriptors General Operation

<pre> BIP: 380 Layer: Applications Title: Output Script Descriptors General Operation Author: Pieter Wuille <pieter@wuille.net> Andrew Chow <andrew@achow101.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0380 Status: Draft Type: Informational Created: 2021-06-27 License: BSD-2-Clause </pre> ==Abstract== Output Script Descriptors are a simple language which can be used to describe collections of output scripts. There can be many different descriptor fragments and functions. This document describes the general syntax for descriptors, descriptor checksums, and common expressions. ==Copyright== This BIP is licensed under the BSD 2-clause license. ==Motivation== Bitcoin wallets traditionally have stored a set of keys which are later serialized and mutated to produce the output scripts that the wallet watches and the addresses it provides to users. Typically backups have consisted of solely the priva...

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

330 - Transaction announcements reconciliation

<pre> BIP: 330 Layer: Peer Services Title: Transaction announcements reconciliation Author: Gleb Naumenko <naumenko.gs@gmail.com> Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0330 Status: Draft Type: Standards Track Created: 2019-09-25 License: CC0-1.0 License-Code: MIT </pre> ==Abstract== This document specifies a P2P protocol extension for reconciliation of transaction announcements <b>between 2 nodes</b>, which is a building block for efficient transaction relay protocols (e.g., [https://arxiv.org/pdf/1905.10518.pdf Erlay]). This is a step towards increasing the connectivity of the network for almost no bandwidth cost. ==Motivation== Currently in the Bitcoin network, every 32-byte transaction ID is announced in at least one direction between every pair of connected peers, via INV messages. This results in high cost of announcing transactions: ''O(nodes * ...

143 - Transaction Signature Verification for Version 0 Witness Program

<pre> BIP: 143 Layer: Consensus (soft fork) Title: Transaction Signature Verification for Version 0 Witness Program Author: Johnson Lau <jl2012@xbt.hk> Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0143 Status: Final Type: Standards Track Created: 2016-01-03 License: PD </pre> == Abstract == This proposal defines a new transaction digest algorithm for signature verification in version 0 witness program, in order to minimize redundant data hashing in verification, and to cover the input value by the signature. == Motivation == There are 4 ECDSA signature verification codes in the original Bitcoin script system: <code>CHECKSIG</code>, <code>CHECKSIGVERIFY</code>, <code>CHECKMULTISIG</code>, <code>CHECKMULTISIGVERIFY</code> (“sigops”). According to the sighash type (<code>ALL</code>, <code>NONE</code>, <code>SINGLE</code>, <code>ANYONECANPAY</code>), a transaction d...

342 - Validation of Taproot Scripts

<pre> BIP: 342 Layer: Consensus (soft fork) Title: Validation of Taproot Scripts Author: Pieter Wuille <pieter.wuille@gmail.com> Jonas Nick <jonasd.nick@gmail.com> Anthony Towns <aj@erisian.com.au> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0342 Status: Draft Type: Standards Track Created: 2020-01-19 License: BSD-3-Clause Requires: 340, 341 Post-History: 2019-05-06: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html [bitcoin-dev] Taproot proposal </pre> ==Introduction== ===Abstract=== This document specifies the semantics of the initial scripting system under [[bip-0341.mediawiki|BIP341]]. ===Copyright=== This document is licensed under the 3-clause BSD license. ===Motivation=== [[bip-0341.mediawiki|BIP341]] proposes improvements to just the script structure, but some of its goals are incompatible with the semantics of certain opcodes within the scripting...

141 - Segregated Witness (Consensus layer)

<pre> BIP: 141 Layer: Consensus (soft fork) Title: Segregated Witness (Consensus layer) Author: Eric Lombrozo <elombrozo@gmail.com> Johnson Lau <jl2012@xbt.hk> Pieter Wuille <pieter.wuille@gmail.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0141 Status: Final Type: Standards Track Created: 2015-12-21 License: PD </pre> ==Abstract== This BIP defines a new structure called a "witness" that is committed to blocks separately from the transaction merkle tree. This structure contains data required to check transaction validity but not required to determine transaction effects. In particular, scripts and signatures are moved into this new structure. The witness is committed in a tree that is nested into the block's existing merkle root via the coinbase transaction for the purpose of making this BIP soft fork compatible. A future hard fork can place this tree in its own branch. ==Motivation== ...

340 - Schnorr Signatures for secp256k1

<pre> BIP: 340 Title: Schnorr Signatures for secp256k1 Author: Pieter Wuille <pieter.wuille@gmail.com> Jonas Nick <jonasd.nick@gmail.com> Tim Ruffing <crypto@timruffing.de> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0340 Status: Draft Type: Standards Track License: BSD-2-Clause Created: 2020-01-19 Post-History: 2018-07-06: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html [bitcoin-dev] Schnorr signatures BIP </pre> == Introduction == === Abstract === This document proposes a standard for 64-byte Schnorr signatures over the elliptic curve ''secp256k1''. === Copyright === This document is licensed under the 2-clause BSD license. === Motivation === Bitcoin has traditionally used [https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm ECDSA] signatures over the [https://www.secg.org/sec2-v2.pdf secp256k1 curve] with [https://en.wikipedia.org/w...

341 - Taproot

<pre> BIP: 341 Layer: Consensus (soft fork) Title: Taproot: SegWit version 1 spending rules Author: Pieter Wuille <pieter.wuille@gmail.com> Jonas Nick <jonasd.nick@gmail.com> Anthony Towns <aj@erisian.com.au> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0341 Status: Draft Type: Standards Track Created: 2020-01-19 License: BSD-3-Clause Requires: 340 Post-History: 2019-05-06: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html [bitcoin-dev] Taproot proposal 2019-10-09: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017378.html [bitcoin-dev] Taproot updates </pre> ==Introduction== ===Abstract=== This document proposes a new SegWit version 1 output type, with spending rules based on Taproot, Schnorr signatures, and Merkle branches. ===Copyright=== This document is licensed under the 3-clause BSD license. ===Motivation=== Thi...

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

147 - Dealing with dummy stack element malleability

<pre> BIP: 147 Layer: Consensus (soft fork) Title: Dealing with dummy stack element malleability Author: Johnson Lau <jl2012@xbt.hk> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0147 Status: Final Type: Standards Track Created: 2016-09-02 License: PD </pre> ==Abstract== This document specifies proposed changes to the Bitcoin transaction validity rules to fix a malleability vector in the extra stack element consumed by <code>OP_CHECKMULTISIG</code> and <code>OP_CHECKMULTISIGVERIFY</code>. ==Motivation== Signature malleability refers to the ability of any relay node on the network to transform the signature in transactions, with no access to the relevant private keys required. For non-segregated witness transactions, signature malleability will change the <code>txid</code> and invalidate any unconfirmed child transactions. Although the <code>txid</code> of segregated witness ([https://github.com/bitcoin/bips/b...

106 - Dynamically Controlled Bitcoin Block Size Max Cap

<pre> BIP: 106 Layer: Consensus (hard fork) Title: Dynamically Controlled Bitcoin Block Size Max Cap Author: Upal Chakraborty <bitcoin@upalc.com> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0106 Status: Rejected Type: Standards Track Created: 2015-08-24 </pre> ==Abstract== This BIP proposes replacing the fixed one megabyte maximum block size with a dynamically controlled maximum block size that may increase or decrease with difficulty change depending on various network factors. I have two proposals regarding this... i. Depending only on previous block size calculation. ii. Depending on previous block size calculation and previous Tx fee collected by miners. ==Motivation== With increased adoption, transaction volume on bitcoin network is bound to grow. If the one megabyte max cap is not changed to a flexible one which changes itself with changing network demand, then adoption will hamper and bitcoin's growth...

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

151 - Peer-to-Peer Communication Encryption

<pre> BIP: 151 Layer: Peer Services Title: Peer-to-Peer Communication Encryption Author: Jonas Schnelli <dev@jonasschnelli.ch> Comments-Summary: Controversial; some recommendation, and some discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0151 Status: Withdrawn Type: Standards Track Created: 2016-03-23 License: PD </pre> == Abstract == This BIP describes an alternative way that a peer can encrypt their communication between a selective subset of remote peers. == Motivation == The Bitcoin network does not encrypt communication between peers today. This opens up security issues (eg: traffic manipulation by others) and allows for mass surveillance / analysis of bitcoin users. Mostly this is negligible because of the nature of Bitcoin's trust model, however, for SPV nodes this can have significant privacy impacts [1] and could reduce the censorship-resistance of a peer. Encrypting peer traffic will make analysis and specific user targ...

322 - Generic Signed Message Format

<pre> BIP: 322 Layer: Applications Title: Generic Signed Message Format Author: Karl-Johan Alm <karljohan-alm@garage.co.jp> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0322 Status: Draft Type: Standards Track Created: 2018-09-10 License: CC0-1.0 </pre> == Abstract == A standard for interoperable signed messages based on the Bitcoin Script format, either for proving fund availability, or committing to a message as the intended recipient of funds sent to the invoice address. == Motivation == The current message signing standard only works for P2PKH (1...) invoice addresses. We propose to extend and generalize the standard by using a Bitcoin Script based approach. This ensures that any coins, no matter what script they are controlled by, can in-principle be signed for. For easy interoperability with existing signing hardware, we also define a signature message format which resembles a Bitcoin transaction (excep...

116 - MERKLEBRANCHVERIFY

<pre> BIP: 116 Layer: Consensus (soft fork) Title: MERKLEBRANCHVERIFY Author: Mark Friedenbach <mark@friedenbach.org> Kalle Alm <kalle.alm@gmail.com> BtcDrak <btcdrak@gmail.com> 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 </pre> ==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, restrict...