385 - raw() and addr() Output Script Descriptors
BIP: 385 source Layer: Applications Title: raw() and addr() Output Script Descriptors Authors: Pieter Wuille Ava Chow Status: Deployed Type: Informational Assigned: 2021-06-27 License: BSD-2-Clause Requires: 380 Table of ContentsAbstractCopyrightMotivationSpecificationraw()addr()Test VectorsBackwards CompatibilityReference Implementation 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 ...
384 - combo() Output Script Descriptors
BIP: 384 source Layer: Applications Title: combo() Output Script Descriptors Authors: Pieter Wuille Ava Chow Status: Deployed Type: Informational Assigned: 2021-06-27 License: BSD-2-Clause Requires: 380 Table of ContentsAbstractCopyrightMotivationSpecificationTest VectorsBackwards CompatibilityReference Implementation 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 arg...
382 - Segwit Output Script Descriptors
BIP: 382 source Layer: Applications Title: Segwit Output Script Descriptors Authors: Pieter Wuille Ava Chow Status: Deployed Type: Informational Assigned: 2021-06-27 License: BSD-2-Clause Requires: 380 Table of ContentsAbstractCopyrightMotivationSpecificationwpkh()wsh()Test VectorsBackwards CompatibilityReference Implementation 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 k...
381 - Non-Segwit Output Script Descriptors
BIP: 381 source Layer: Applications Title: Non-Segwit Output Script Descriptors Authors: Pieter Wuille Ava Chow Status: Deployed Type: Informational Assigned: 2021-06-27 License: BSD-2-Clause Requires: 380 Table of ContentsAbstractCopyrightMotivationSpecificationpk()pkh()sh()Test VectorsBackwards CompatibilityReference Implementation 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...
387 - Tapscript Multisig Output Script Descriptors
BIP: 387 source Layer: Applications Title: Tapscript Multisig Output Script Descriptors Authors: Pieter Wuille Ava Chow Status: Deployed Type: Informational Assigned: 2024-04-17 License: BSD-2-Clause Requires: 380 Table of ContentsAbstractCopyrightMotivationSpecificationsortedmulti_a()Multiple Extended KeysTest VectorsBackwards CompatibilityReference Implementation Abstract This document specifies multi_a() and sortedmulti_a() output script descriptors. Like BIP 383's multi() and sortedmulti(), both functions take a threshold and one or more public keys and produce a multisig script. The primary distinction is that multi_a() and sortedmulti_a() only produce tapscripts and are only allowed in a tapscript context. 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 e...
383 - Multisig Output Script Descriptors
BIP: 383 source Layer: Applications Title: Multisig Output Script Descriptors Authors: Pieter Wuille Ava Chow Status: Deployed Type: Informational Assigned: 2021-06-27 License: BSD-2-Clause Requires: 380 Table of ContentsAbstractCopyrightMotivationSpecificationsortedmulti()Multiple Extended KeysTest VectorsBackwards CompatibilityReference Implementation 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 s...
386 - tr() Output Script Descriptors
BIP: 386 source Layer: Applications Title: tr() Output Script Descriptors Authors: Pieter Wuille Ava Chow Status: Deployed Type: Informational Assigned: 2021-06-27 License: BSD-2-Clause Requires: 380 Table of ContentsAbstractCopyrightMotivationSpecificationTree Expressiontr()Modified Key ExpressionTest VectorsBackwards CompatibilityReference Implementation 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 a...
30 - Duplicate transactions
BIP: 30 source Layer: Consensus (soft fork) Title: Duplicate transactions Authors: Pieter Wuille Status: Deployed Type: Specification Assigned: 2012-02-22 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecificationRationaleBackward compatibilityImplementationAcknowledgements 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...
42 - A finite monetary supply for Bitcoin
BIP: 42 source Layer: Consensus (soft fork) Title: A finite monetary supply for Bitcoin Authors: Pieter Wuille Comments-Summary: Unanimously Recommended for implementation Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0042 Status: Deployed Type: Specification Assigned: 2014-04-01 License: PD Table of ContentsAbstractDetailsOther solutionsFloating-point approximationTruncationProposalImplementationCompatibilityAcknowledgementsCopyright 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 mibillennium (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 wal...
144 - Segregated Witness (Peer Services)
BIP: 144 source Layer: Peer Services Title: Segregated Witness (Peer Services) Authors: Eric Lombrozo Pieter Wuille Status: Deployed Type: Specification Assigned: 2016-01-08 License: PD Table of ContentsAbstractMotivationSpecificationSerializationHandshakeHashesRelayCreditsReference ImplementationCopyright 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 (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 serialization has the following structure: Field Size Name T...
103 - Block size following technological growth
BIP: 103 source Layer: Consensus (hard fork) Title: Block size following technological growth Authors: Pieter Wuille Status: Closed Type: Specification Assigned: 2015-07-21 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecificationRationaleCompatibilityAcknowledgements 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's fundamental ...
146 - Dealing with signature encoding malleability
BIP: 146 source Layer: Consensus (soft fork) Title: Dealing with signature encoding malleability Authors: Johnson Lau Pieter Wuille Status: Closed Type: Specification Assigned: 2016-08-16 License: PD Table of ContentsAbstractMotivationSpecificationLOW_SNULLFAILExamplesDeploymentCompatibilityImplementationFootnotesAcknowledgementsCopyright 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 (BIP141) transactions is not third party malleable, this malleability vector will change the wtxid and may ...
66 - Strict DER signatures
BIP: 66 source Layer: Consensus (soft fork) Title: Strict DER signatures Authors: Pieter Wuille Status: Deployed Type: Specification Assigned: 2015-01-10 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecificationDER encoding referenceExamplesDeploymentCompatibilityImplementationAcknowledgementsDisclosures 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...
147 - Dealing with dummy stack element malleability
BIP: 147 source Layer: Consensus (soft fork) Title: Dealing with dummy stack element malleability Authors: Johnson Lau Status: Deployed Type: Specification Assigned: 2016-09-02 License: PD Table of ContentsAbstractMotivationSpecificationDeploymentCompatibilityImplementationAcknowledgementsCopyright 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 (BIP141) transactions is not third party malleable, this malleability vector will change the wtxid and may reduce ...
380 - Output Script Descriptors General Operation
BIP: 380 source Layer: Applications Title: Output Script Descriptors General Operation Authors: Pieter Wuille Ava Chow Status: Deployed Type: Informational Assigned: 2021-06-27 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecificationScript ExpressionsKey ExpressionsNormalization of Key Expressions with Hardened DerivationCharacter SetChecksumTest VectorsBackwards CompatibilityReference ImplementationAppendix A: Index of ExpressionsAppendix B: Index of Script Expressions 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 ...
9 - Version bits with timeout and delay
BIP: 9 source Title: Version bits with timeout and delay Authors: Pieter Wuille Peter Todd Greg Maxwell Rusty Russell Status: Deployed Type: Informational Assigned: 2015-10-04 License: PD Table of ContentsAbstractMotivationSpecificationSelection guidelinesStatesBit flagsNew consensus rulesState transitionsWarning mechanismgetblocktemplate changesSupport for future changesRationaleDeploymentsCopyright 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 34 introduced a mechanism fo...
62 - Dealing with malleability
NOTICE: This document is a work in progress and is not complete, implemented, or otherwise suitable for deployment. BIP: 62 source Layer: Consensus (soft fork) Title: Dealing with malleability Authors: Pieter Wuille Status: Closed Type: Specification Assigned: 2014-03-12 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecificationNew rulesBlock validityReferencesLow S values in signaturesDER encodingPush operatorsNumbersCompatibility 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:...
433 - Pay to Anchor (P2A)
BIP: 433 source Layer: Applications Title: Pay to Anchor (P2A) Authors: Gregory Sanders Status: Draft Type: Informational Assigned: 2025-12-08 License: BSD-3-Clause Discussion: 2024-06-27: https://github.com/bitcoin/bitcoin/pull/30352 Github PR 2024-10-10: https://bitcoinops.org/en/bitcoin-core-28-wallet-integration-guide/ wallet integration guide Table of ContentsAbstractMotivationSpecificationImplementationRelated WorkBackward CompatibilityAcknowledgementsReferences and Rationale Abstract This document describes a new standard output script called Pay to Anchor (P2A) and prescribes making spending of this output type standard. This output is "keyless" meaning no signature or witness data at all are required to spend this output typea. Motivation The "anchor" output type is a commonly used pattern in Bitcoin layer 2 systems such as Lightning Network and beyond. This pattern allows transactions which are presigned far in advance to leave a "hook" for CPF...
328 - Derivation Scheme for MuSig2 Aggregate Keys
BIP: 328 source Layer: Applications Title: Derivation Scheme for MuSig2 Aggregate Keys Authors: Ava Chow Status: Complete Type: Informational Assigned: 2024-06-04 License: CC0-1.0 Table of ContentsAbstractCopyrightMotivationSpecificationTest VectorsBackwards CompatibilityRationaleReference ImplementationAcknowledgements Abstract This document specifies how BIP 32 extended public keys can be constructed from a BIP 327 MuSig2 aggregate public key and how such keys should be used for key derivation. Copyright This BIP is licensed under the Creative Commons CC0 1.0 Universal license. Motivation Multiple signers can create a single aggregate public key with MuSig2 that is indistinguishable from a random public key. The cosigners need a method for generating additional aggregate pubkeys to follow the best practice of using a new address for every payment. The obvious method is for the cosigners to generate multiple public keys and produce a new aggregate pubkey every time on...
173 - Base32 address format for native v0-16 witness outputs
BIP: 173 source Layer: Applications Title: Base32 address format for native v0-16 witness outputs Authors: Pieter Wuille Greg Maxwell Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0173 Status: Deployed Type: Informational Assigned: 2017-03-20 License: BSD-2-Clause Replaces: 142 Proposed-Replacement: 350 Table of ContentsIntroductionAbstractCopyrightMotivationExamplesSpecificationBech32Segwit address formatCompatibilityRationaleReference implementationsRegistered Human-readable PrefixesAppendicesTest vectorsChecksum designAcknowledgementsDisclosures (added 2024) 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...
350 - Bech32m format for v1+ witness addresses
BIP: 350 source Layer: Applications Title: Bech32m format for v1+ witness addresses Authors: Pieter Wuille Status: Deployed Type: Specification Assigned: 2020-12-16 License: BSD-2-Clause Discussion: 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 Replaces: 173 Table of ContentsIntroductionAbstractCopyrightMotivationSpecificationBech32mAddresses for segregated witness outputsCompatibilityReference implementationsTest vectorsTest vectors for Bech32mTest vectors for v0-v16 native segregated witness addressesAppendix: checksum design & propertiesError patterns & detection probabilityDetection properties of Bech32mSelection processFootnotesAcknowledgements 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 ...
342 - Validation of Taproot Scripts
BIP: 342 source Layer: Consensus (soft fork) Title: Validation of Taproot Scripts Authors: Pieter Wuille Jonas Nick Anthony Towns Status: Deployed Type: Specification Assigned: 2020-01-19 License: BSD-3-Clause Discussion: 2019-05-06: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html [bitcoin-dev] Taproot proposal Requires: 340, 341 Table of ContentsIntroductionAbstractCopyrightMotivationDesignSpecificationScript executionRules for signature opcodesCommon Signature Message ExtensionSignature validationResource limitsRationaleDeploymentExamplesAcknowledgements Introduction Abstract This document specifies the semantics of the initial scripting system under BIP341. Copyright This document is licensed under the 3-clause BSD license. Motivation 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. W...
143 - Transaction Signature Verification for Version 0 Witness Program
BIP: 143 source Layer: Consensus (soft fork) Title: Transaction Signature Verification for Version 0 Witness Program Authors: Johnson Lau Pieter Wuille Status: Deployed Type: Specification Assigned: 2016-01-03 License: PD Table of ContentsAbstractMotivationSpecificationRestrictions on public key typeExampleNative P2WPKHP2SH-P2WPKHNative P2WSHP2SH-P2WSHNo FindAndDeleteDeploymentBackward compatibilityReference ImplementationReferencesCopyright 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 s...
379 - Miniscript
BIP: 379 source Layer: Applications Title: Miniscript Authors: Pieter Wuille Andrew Poelstra Sanket Kanjalkar Antoine Poinsot Ava Chow Status: Draft Type: Informational Assigned: 2023-10-10 License: CC0-1.0 Requires: 380 Abstract This document specifies Miniscript, a language for writing (a subset of) Bitcoin Scripts in a structured way, enabling analysis, composition, generic signing and more. Copyright This document is licensed under the Creative Commons CC0 1.0 Universal license. Motivation Bitcoin Script is an unusual stack-based language with many edge cases, designed for implementing spending conditions consisting of various combinations of signatures, hash locks, and time locks. Yet, despite being limited in functionality, it is still highly nontrivial to: Given a combination of spending conditions, finding the most economical script to implement it. Given two scripts, construct a script that implements a composition...
330 - Transaction announcements reconciliation
BIP: 330 source Layer: Peer Services Title: Transaction announcements reconciliation Authors: Gleb Naumenko Pieter Wuille Status: Draft Type: Specification Assigned: 2019-09-25 License: CC0-1.0 License-Code: MIT Table of ContentsAbstractMotivationErlaySpecificationNew data structures32-bit short transaction IDsShort transaction ID sketchesIntended Protocol FlowSketch extensionNew messagessendtxrcnclreqreconsketchreqsketchextreconcildiffLocal stateReconciliation saltReconciliation setsReconciliation set snapshotSketch capacity estimation and q-coefficientBackward compatibilityRationaleWhy use PinSketch for set reconciliation?Why use 32-bit short transaction IDs?Why use sketch extensions instead of bisection?ImplementationAcknowledgmentsCopyright 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., Erlay). This is a...
106 - Dynamically Controlled Bitcoin Block Size Max Cap
BIP: 106 source Layer: Consensus (hard fork) Title: Dynamically Controlled Bitcoin Block Size Max Cap Authors: Upal Chakraborty Status: Closed Type: Specification Assigned: 2015-08-24 Table of ContentsAbstractMotivationSpecificationProposal 1 : Depending only on previous block size calculationProposal 2 : Depending on previous block size calculation and previous Tx fee collected by minersRationaleProposal 1 : Depending only on previous block size calculationProposal 2 : Depending on previous block size calculation and previous Tx fee collected by minersCompatibilityOther solutions consideredDeployment 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 fe...
123 - BIP Classification
BIP: 123 source Title: BIP Classification Authors: Eric Lombrozo Status: Deployed Type: Process Assigned: 2015-08-26 License: CC0-1.0 OR FSFAP Table of ContentsAbstractCopyrightMotivationSpecification1. Consensus LayerSoft ForksHard Forks2. Peer Services Layer3. API/RPC Layer4. Applications LayerClassification of existing BIPs 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 FSF 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 implementers a choice of whether to su...
141 - Segregated Witness (Consensus layer)
BIP: 141 source Layer: Consensus (soft fork) Title: Segregated Witness (Consensus layer) Authors: Eric Lombrozo Johnson Lau Pieter Wuille Status: Deployed Type: Specification Assigned: 2015-12-21 License: PD Table of ContentsAbstractMotivationSpecificationTransaction IDCommitment structureWitness programOther consensus critical limitsBlock sizeSigopsAdditional definitionsTransaction size calculationsNew script semanticsExamplesP2WPKHP2WPKH nested in BIP16 P2SHP2WSHP2WSH nested in BIP16 P2SHExtensible commitment structureTrust-free unconfirmed transaction dependency chainFuture extensionsCompact fraud proof for SPV nodesNew script systemPer-input lock-time and relative-lock-timeBackward compatibilityDeploymentCreditsFootnotesReference ImplementationReferencesCopyright 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 t...
340 - Schnorr Signatures for secp256k1
BIP: 340 source Title: Schnorr Signatures for secp256k1 Authors: Pieter Wuille Jonas Nick Tim Ruffing Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0340 Status: Deployed Type: Specification Assigned: 2020-01-19 License: BSD-2-Clause License-Code: BSD-2-Clause OR MIT OR CC0-1.0 Discussion: 2018-07-06: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-July/016203.html [bitcoin-dev] Schnorr signatures BIP Table of ContentsIntroductionAbstractCopyrightMotivationDescriptionDesignSpecificationPublic Key GenerationPublic Key ConversionDefault SigningAlternative SigningVerificationBatch VerificationUsage ConsiderationsMessages of Arbitrary SizeDomain SeparationApplicationsMultisignatures and Threshold SignaturesAdaptor SignaturesBlind SignaturesTest Vectors and Reference CodeChangelogFootnotesAcknowledgements Introduction Abstract This document proposes a standard for 64-byte Schnorr...
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 source Layer: Applications Title: Hierarchical Deterministic Wallets Authors: Pieter Wuille Status: Deployed Type: Informational Assigned: 2012-02-11 License: BSD-2-Clause Table of ContentsAbstractCopyrightMotivationSpecification: Key derivationConventionsExtended keysChild key derivation (CKD) functionsPrivate parent key → private child keyPublic parent key → public child keyPrivate parent key → public child keyPublic parent key → private child keyThe key tree...
341 - Taproot
BIP: 341 source Layer: Consensus (soft fork) Title: Taproot: SegWit version 1 spending rules Authors: Pieter Wuille Jonas Nick Anthony Towns Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0341 Status: Deployed Type: Specification Assigned: 2020-01-19 License: BSD-3-Clause Discussion: 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 Requires: 340 Table of ContentsIntroductionAbstractCopyrightMotivationDesignSpecificationScript validation rulesSignature validation rulesCommon signature messageTaproot key path spending signature validationConstructing and spending Taproot outputsSecurityTest vectorsRationaleDeploymentBackwards compatibilityAcknowledgements Introduction Abstract This d...
151 - Peer-to-Peer Communication Encryption
BIP: 151 source Layer: Peer Services Title: Peer-to-Peer Communication Encryption Authors: Jonas Schnelli Comments-Summary: Controversial; some recommendation, and some discouragement Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0151 Status: Closed Type: Specification Assigned: 2016-03-23 License: PD Proposed-Replacement: 324 Table of ContentsAbstractMotivationSpecificationSymmetric Encryption Cipher KeysSession IDThe encinit message typeChaCha20-Poly1305 Cipher SuiteThe encack message typeEncrypted Messages StructureRe-KeyingRisksCompatibilityReference implementationReferencesAcknowledgementsCopyright 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. ...
322 - Generic Signed Message Format
BIP: 322 source Layer: Applications Title: Generic Signed Message Format Authors: Karl-Johan Alm Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0322 Status: Draft Type: Specification Assigned: 2018-09-10 License: CC0-1.0 Table of ContentsAbstractMotivationTypes of SignaturesLegacySimpleFullFull (Proof of Funds)Detailed SpecificationVerificationVerification ProcessSigningCompatibilityReference implementationAcknowledgementsReferencesCopyrightTest vectorsMessage hashingMessage signingTransaction Hashes 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 tha...
324 - Version 2 P2P Encrypted Transport Protocol
BIP: 324 source Layer: Peer Services Title: Version 2 P2P Encrypted Transport Protocol Authors: Dhruv Mehta Tim Ruffing Jonas Schnelli Pieter Wuille Status: Deployed Type: Specification Assigned: 2019-03-08 License: BSD-3-Clause Version: 1.0.2 Replaces: 151 Table of ContentsIntroductionAbstractCopyrightMotivationGoalsSpecificationTransport layer specificationOverview and designHandshake: key exchange and version negotiationShared secret computationElligatorSwift encoding of curve X coordinatesKeys and session ID derivationOverall handshake pseudocodePacket encryptionExisting cryptographic primitivesRekeying wrappers: FSChaCha20Poly1305 and FSChaCha20Overall packet encryption and decryption pseudocodePerformanceApplication layer specificationv2 Bitcoin P2P message structureSignaling specificationSignaling v2 supportTest VectorsChangelogRationale and ReferencesAcknowledgements Introduction Abstract This document proposes a new Bitc...
116 - MERKLEBRANCHVERIFY
BIP: 116 source Layer: Consensus (soft fork) Title: MERKLEBRANCHVERIFY Authors: Mark Friedenbach Kalle Alm BtcDrak Status: Draft Type: Specification Assigned: 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 that cascades through a series of 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 ...