30 - Duplicate transactions
BIP: 30 Layer: Consensus (soft fork) Title: Duplicate transactions Author: Pieter Wuille 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 ==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 transactions was described and demonstrated. It allow...
42 - A finite monetary supply for Bitcoin
BIP: 42 Layer: Consensus (soft fork) Title: A finite monetary supply for Bitcoin Author: Pieter Wuille 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 ==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: making Bitcoin's monetary supply finite. ==Deta...
103 - Block size following technological growth
BIP: 103 Layer: Consensus (hard fork) Title: Block size following technological growth Author: Pieter Wuille 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 ==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 availability on the market, there is no reason why Bitcoin...
66 - Strict DER signatures
BIP: 66 Layer: Consensus (soft fork) Title: Strict DER signatures Author: Pieter Wuille 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 ==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 recently, OpenSSL's releases would accept various devia...
62 - Dealing with malleability
'''NOTICE: This document is a work in progress and is not complete, implemented, or otherwise suitable for deployment.''' BIP: 62 Layer: Consensus (soft fork) Title: Dealing with malleability Author: Pieter Wuille 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 ==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 reasons: * The sender may not recognize his own transact...
350 - Bech32m format for v1+ witness addresses
BIP: 350 Layer: Applications Title: Bech32m format for v1+ witness addresses Author: Pieter Wuille 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 ==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 for segregated witness outputs of version 0...
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 IL to addition of IL (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 BIP: 32 Layer: Applications Title: Hierarchical Deterministic Wallets Author: Pieter Wuille 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 ==Abstract== This document describes hierarchical deterministic wallets (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without ...
385 - raw() and addr() Output Script Descriptors
BIP: 385 Layer: Applications Title: raw() and addr() Output Script Descriptors Author: Pieter Wuille Andrew Chow 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 ==Abstract== This document specifies raw() and addr() output script descriptors. raw() encapsulates a raw script as a descriptor. addr() 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: raw() and addr(). ===raw()=== The raw(HEX) expression can only be used as a top level descriptor. As the argument, it takes a hex string representing a Bitcoin script. The output script produced ...
384 - combo() Output Script Descriptors
BIP: 384 Layer: Applications Title: combo() Output Script Descriptors Author: Pieter Wuille Andrew Chow 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 ==Abstract== This document specifies combo() 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: combo(KEY). This expression can only be used as a top level expression. It takes a single key expression as an argument and produces either 2...
382 - Segwit Output Script Descriptors
BIP: 382 Layer: Applications Title: Segwit Output Script Descriptors Author: Pieter Wuille Andrew Chow 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 ==Abstract== This document specifies wpkh(), and wsh() output script descriptors. wpkh() descriptors take a key and produces a P2WPKH output script. wsh() 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: wpkh(), and wsh(). ===wpkh()=== The wpkh(KEY) expression can be used as a top level expression, or inside of a sh() descriptor. It takes a single key expression as an argument and pr...
381 - Non-Segwit Output Script Descriptors
BIP: 381 Layer: Applications Title: Non-Segwit Output Script Descriptors Author: Pieter Wuille Andrew Chow 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 ==Abstract== This document specifies pk(), pkh(), and sh() output script descriptors. pk() descriptors take a key and produces a P2PK output script. pkh() descriptors take a key and produces a P2PKH output script. sh() 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== Three new script expressions are defined: pk(), pkh(), and sh(). ===pk()=== The pk(KEY) expression can be used in any conte...
383 - Multisig Output Script Descriptors
BIP: 383 Layer: Applications Title: Multisig Output Script Descriptors Author: Pieter Wuille Andrew Chow 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 ==Abstract== This document specifies multi(), and sortedmulti() output script descriptors. Both functions take a threshold and one or more public keys and produce a multisig output script. multi() specifies the public keys in the output script in the order given in the descriptor while sortedmulti() 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 descriptor. ==Specification== Two new script expressions are defined: multi(), and sortedmulti(). Bot...
386 - tr() Output Script Descriptors
BIP: 386 Layer: Applications Title: tr() Output Script Descriptors Author: Pieter Wuille Andrew Chow 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 ==Abstract== This document specifies tr() output script descriptors. tr() 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: tr(). A new expression is defined: Tree Expressions ===Tree Expression=== A Tree Expression (denoted TREE) is an expression which represents a tree of scripts. The way the tree is represented in an output script is dependent on the higher level expressions. A Tre...
144 - Segregated Witness (Peer Services)
BIP: 144 Layer: Peer Services Title: Segregated Witness (Peer Services) Author: Eric Lombrozo Pieter Wuille 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 ==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 format for tx messages is added to the peer-to-peer protocol. The ...
146 - Dealing with signature encoding malleability
BIP: 146 Layer: Consensus (soft fork) Title: Dealing with signature encoding malleability Author: Johnson Lau Pieter Wuille 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 ==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 txid and invalidate any unconfirmed child transactions. Although the txid of segregated witness ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) transactions is not third party malleable, this malleability vect...
380 - Output Script Descriptors General Operation
BIP: 380 Layer: Applications Title: Output Script Descriptors General Operation Author: Pieter Wuille Andrew Chow 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 ==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 private keys, nowadays primarily in the form of BIP 39 mnemonics. Ho...
173 - Base32 address format for native v0-16 witness outputs
BIP: 173 Layer: Applications Title: Base32 address format for native v0-16 witness outputs Author: Pieter Wuille Greg Maxwell 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 ==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.mediawiki P2SH]). However, both the character set and the checksum algori...
143 - Transaction Signature Verification for Version 0 Witness Program
BIP: 143 Layer: Consensus (soft fork) Title: Transaction Signature Verification for Version 0 Witness Program Author: Johnson Lau Pieter Wuille 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 == 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: CHECKSIG, CHECKSIGVERIFY, CHECKMULTISIG, CHECKMULTISIGVERIFY (“sigops”). According to the sighash type (ALL, NONE, SINGLE, ANYONECANPAY), a transaction digest is generated with a double SHA256 of a serialized subset of the transaction, and the signature is verified against this digest with a given public key. T...
330 - Transaction announcements reconciliation
BIP: 330 Layer: Peer Services Title: Transaction announcements reconciliation Author: Gleb Naumenko Pieter Wuille 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 ==Abstract== This document specifies a P2P protocol extension for reconciliation of transaction announcements between 2 nodes, 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 * connections_per_node)''. A reconciliation-based protocol which uses the tec...
342 - Validation of Taproot Scripts
BIP: 342 Layer: Consensus (soft fork) Title: Validation of Taproot Scripts Author: Pieter Wuille Jonas Nick Anthony Towns Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0342 Status: Final 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 ==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 language itself. While it is possible to deal with these in separate optional improvements,...
141 - Segregated Witness (Consensus layer)
BIP: 141 Layer: Consensus (soft fork) Title: Segregated Witness (Consensus layer) Author: Eric Lombrozo Johnson Lau Pieter Wuille 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 ==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== The entirety of the transaction's effects are determined by output consumption (s...
340 - Schnorr Signatures for secp256k1
BIP: 340 Title: Schnorr Signatures for secp256k1 Author: Pieter Wuille Jonas Nick Tim Ruffing Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0340 Status: Final 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 == 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/wiki/SHA-2 SHA256] hashes for authenticating transactions. These are [https://www.secg.org/sec1-...
341 - Taproot
BIP: 341 Layer: Consensus (soft fork) Title: Taproot: SegWit version 1 spending rules Author: Pieter Wuille Jonas Nick Anthony Towns Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0341 Status: Final 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 ==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=== This proposal aims to improve privacy, efficiency, and flexibility of Bitcoin's scripting capab...
9 - Version bits with timeout and delay
BIP: 9 Title: Version bits with timeout and delay Author: Pieter Wuille Peter Todd Greg Maxwell Rusty Russell 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 ==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 mechanism for doing soft-forking changes without a predefined flag timestamp (or flag block height), inste...
324 - Version 2 P2P Encrypted Transport Protocol
BIP: 324 Layer: Peer Services Title: Version 2 P2P Encrypted Transport Protocol Author: Dhruv Mehta Tim Ruffing Jonas Schnelli Pieter Wuille Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0324 Status: Draft Type: Standards Track Created: 2019-03-08 License: BSD-3-Clause Replaces: 151 == Introduction == === Abstract === This document proposes a new Bitcoin P2P transport protocol, which features opportunistic encryption, a mild bandwidth reduction, and the ability to negotiate upgrades before exchanging application messages. === Copyright === This document is licensed under the 3-clause BSD license. === Motivation === Bitcoin is a permissionless network whose purpose is to reach consensus over public data. Since all data relayed in the Bitcoin P2P network is inherently public, and the protocol lacks a notion of cryptographic identities, peers talk to each other over unencrypted and unauthenticated connections. Neverthel...
147 - Dealing with dummy stack element malleability
BIP: 147 Layer: Consensus (soft fork) Title: Dealing with dummy stack element malleability Author: Johnson Lau 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 ==Abstract== This document specifies proposed changes to the Bitcoin transaction validity rules to fix a malleability vector in the extra stack element consumed by OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY. ==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 txid and invalidate any unconfirmed child transactions. Although the txid of segregated witness ([https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki BIP141]) transactions is not third party malleable, this...
106 - Dynamically Controlled Bitcoin Block Size Max Cap
BIP: 106 Layer: Consensus (hard fork) Title: Dynamically Controlled Bitcoin Block Size Max Cap Author: Upal Chakraborty 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 ==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 may choke up. Following graph shows the c...
123 - BIP Classification
BIP: 123 Title: BIP Classification Author: Eric Lombrozo 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 ==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. In order to have a BIP process which more closely ...
151 - Peer-to-Peer Communication Encryption
BIP: 151 Layer: Peer Services Title: Peer-to-Peer Communication Encryption Author: Jonas Schnelli 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 Superseded-By: 324 == 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 targeting much more diffic...
322 - Generic Signed Message Format
BIP: 322 Layer: Applications Title: Generic Signed Message Format Author: Karl-Johan Alm 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 == 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 (except that it contains an invalid input, so it cann...
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...