BIPs — Merged

BIP: 1 Title: BIP Purpose and Guidelines Authors: Amir Taaki <genjix@riseup.net>

BIP: 2 Title: BIP process, revised Authors: Luke Dashjr <luke+bip@dashjr.org>

This _Bitcoin Improvement Proposal (BIP)_ provides information about the preparation of BIPs and policies relating to the publication of BIPs. It replaces [BIP 2](bip-0002.mediawiki) with a streamlined process, and may be amended to address the evolving needs of the BIP process.

BIP: 8 Title: Version bits with lock-in by height Authors: Shaolin Fry <shaolinfry@protonmail.ch>

BIP: 9 Title: Version bits with timeout and delay Authors: Pieter Wuille <pieter.wuille@gmail.com>

BIP: 10 Layer: Applications Title: Multi-Sig Transaction Distribution

BIP: 11 Layer: Applications Title: M-of-N Standard Transactions

BIP: 12 Layer: Consensus (soft fork) Title: OP_EVAL

BIP: 13 Layer: Applications Title: Address Format for pay-to-script-hash

BIP: 14 Layer: Peer Services Title: Protocol Version and User Agent

BIP: 15 Layer: Applications Title: Aliases

BIP: 16 Layer: Consensus (soft fork) Title: Pay to Script Hash

BIP: 17 Layer: Consensus (soft fork) Title: OP_CHECKHASHVERIFY (CHV)

BIP: 18 Layer: Consensus (soft fork) Title: hashScriptCheck

BIP: 19 Layer: Applications Title: M-of-N Standard Transactions (Low SigOp)

BIP: 20 Layer: Applications Title: URI Scheme

BIP: 21 Layer: Applications Title: URI Scheme

BIP: 22 Layer: API/RPC Title: getblocktemplate - Fundamentals

BIP: 23 Layer: API/RPC Title: getblocktemplate - Pooled Mining

BIP: 30 Layer: Consensus (soft fork) Title: Duplicate transactions

BIP: 31 Layer: Peer Services Title: Pong message

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_L to addition of I_L (faster, easier implementation)

BIP: 33 Layer: Peer Services Title: Stratized Nodes

BIP: 34 Layer: Consensus (soft fork) Title: Block v2, Height in Coinbase

BIP: 35 Layer: Peer Services Title: mempool message

BIP: 36 Layer: Peer Services Title: Custom Services

BIP: 37 Layer: Peer Services Title: Connection Bloom filtering

BIP: 38 Layer: Applications Title: Passphrase-protected private key

BIP: 39 Layer: Applications Title: Mnemonic code for generating deterministic keys

BIP: 42 Layer: Consensus (soft fork) Title: A finite monetary supply for Bitcoin

BIP: 43 Layer: Applications Title: Purpose Field for Deterministic Wallets

BIP: 44 Layer: Applications Title: Multi-Account Hierarchy for Deterministic Wallets

BIP: 45 Layer: Applications Title: Structure for Deterministic P2SH Multisignature Wallets

BIP: 46 Layer: Applications Title: Address Scheme for Timelocked Fidelity Bonds

RECENT CHANGES: * (15 Feb 2021) Finalize specification * (28 Sep 2017) Adjust text to match test vectors

BIP: 48 Layer: Applications Title: Multi-Script Hierarchy for Multi-Sig Wallets

BIP: 49 Layer: Applications Title: Derivation scheme for P2WPKH-nested-in-P2SH based accounts

BIP: 50 Title: March 2013 Chain Fork Post-Mortem Authors: Gavin Andresen <gavinandresen@gmail.com>

BIP: 52 Layer: Consensus (hard fork) Title: Durable, Low Energy Bitcoin PoW

BIP: 53 Layer: Consensus (soft fork) Title: Disallow 64-byte transactions

This document proposes new consensus rules in order to fix the timewarp attack, reduce the worst case block validation time, prevent Merkle tree weaknesses, and avoid duplicate transactions without [bip-0030][BIP30] validation.

BIP: 60 Layer: Peer Services Title: Fixed Length "version" Message (Relay-Transactions Field)

BIP: 61 Layer: Peer Services Title: Reject P2P message

'''NOTICE: This document is a work in progress and is not complete, implemented, or otherwise suitable for deployment.''' BIP: 62 Layer: Consensus (soft fork)

BIP: 64 Layer: Peer Services Title: getutxo message

BIP: 65 Layer: Consensus (soft fork) Title: OP_CHECKLOCKTIMEVERIFY

BIP: 66 Layer: Consensus (soft fork) Title: Strict DER signatures

BIP: 67 Layer: Applications Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting

BIP: 68 Layer: Consensus (soft fork) Title: Relative lock-time using consensus-enforced sequence numbers

BIP: 69 Layer: Applications Title: Lexicographical Indexing of Transaction Inputs and Outputs

BIP: 70 Layer: Applications Title: Payment Protocol

BIP: 71 Layer: Applications Title: Payment Protocol MIME types

BIP: 72 Layer: Applications Title: bitcoin: uri extensions for Payment Protocol

BIP: 73 Layer: Applications Title: Use "Accept" header for response type negotiation with Payment Request URLs

BIP: 74 Layer: Applications Title: Allow zero value OP_RETURN in Payment Protocol

BIP: 75 Layer: Applications Title: Out of Band Address Exchange using Payment Protocol Encryption

Payjoin lets Bitcoin senders and receivers interact to make batched transactions. This document proposes a second, backwards-compatible, asynchronous version of the Payjoin protocol ("Version 2") relative to and described in [BIP 78](bip-0078.mediawiki) ("Version 1"). An untrusted third-party "directory server" replaces the requirement for a receiver to host a secure public endpoint for interactions. HTTP clients access the directory server using an asynchronous protocol and authenticated, encr

This document proposes a protocol for two parties to negotiate a coinjoin transaction during a payment between them.

BIP: 79 Layer: Applications Title: Bustapay :: a practical coinjoin protocol

BIP: 80 Title: Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets Authors: Justus Ranvier <justus@opentransactions.org>

BIP: 81 Title: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets Authors: Justus Ranvier <justus@opentransactions.org>

BIP: 83 Layer: Applications Title: Dynamic Hierarchical Deterministic Key Trees

BIP: 84 Layer: Applications Title: Derivation scheme for P2WPKH based accounts

BIP: 85 Layer: Applications Title: Deterministic Entropy From BIP32 Keychains

BIP: 86 Layer: Applications Title: Key Derivation for Single Key P2TR Outputs

BIP: 87 Layer: Applications Title: Hierarchy for Deterministic Multisig Wallets

BIP: 88 Layer: Applications Title: Hierarchical Deterministic Path Templates

BIP: 89 Layer: Applications Title: Chain Code Delegation

BIP: 90 Title: Buried Deployments Authors: Suhas Daftuar <sdaftuar@chaincode.com>

BIP: 91 Layer: Consensus (soft fork) Title: Reduced threshold Segwit MASF

This document proposes a checksummed base32 format, "codex32", and a standard for backing up and restoring the master seed of a [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP-0032] hierarchical deterministic wallet using it. It includes an encoding format, a BCH error-correcting checksum, and optional Shamir's secret sharing algorithms for share generation and secret recovery. Secret data can be encoded directly, or split into up to 31 shares. A minimum threshold of shares,

BIP: 94 Layer: Applications Title: Testnet 4

BIP: 98 Layer: Consensus (soft fork) Title: Fast Merkle Trees

BIP: 99 Title: Motivation and deployment of consensus rule changes ([soft/hard]forks) Authors: Jorge Timón <jtimon@jtimon.cc>

BIP: 100 Layer: Consensus (hard fork) Title: Dynamic maximum block size by miner vote

BIP: 101 Layer: Consensus (hard fork) Title: Increase maximum block size

BIP: 102 Layer: Consensus (hard fork) Title: Block size increase to 2MB

BIP: 103 Layer: Consensus (hard fork) Title: Block size following technological growth

BIP: 104 Layer: Consensus (hard fork) Title: 'Block75' - Max block size like difficulty

BIP: 105 Layer: Consensus (hard fork) Title: Consensus based block size retargeting algorithm

BIP: 106 Layer: Consensus (hard fork) Title: Dynamically Controlled Bitcoin Block Size Max Cap

BIP: 107 Layer: Consensus (hard fork) Title: Dynamic limit on the block size

BIP: 109 Layer: Consensus (hard fork) Title: Two million byte size limit with sigop and sighash limits

BIP: 110 Layer: Consensus (soft fork) Title: Reduced Data Temporary Softfork

BIP: 111 Layer: Peer Services Title: NODE_BLOOM service bit

BIP: 112 Layer: Consensus (soft fork) Title: CHECKSEQUENCEVERIFY

BIP: 113 Layer: Consensus (soft fork) Title: Median time-past as endpoint for lock-time calculations

BIP: 114 Layer: Consensus (soft fork) Title: Merkelized Abstract Syntax Tree

BIP: 115 Layer: Consensus (soft fork) Title: Generic anti-replay protection using Script

BIP: 116 Layer: Consensus (soft fork) Title: MERKLEBRANCHVERIFY

BIP: 117 Layer: Consensus (soft fork) Title: Tail Call Execution Semantics

This BIP describes a new type of public key for tapscript ([[bip-0342.mediawiki|BIP 342]]) transactions. It allows signatures for these public keys to not commit to the exact UTXO being spent. This enables dynamic binding of transactions to different UTXOs, provided they have compatible scripts.

BIP: 119 Layer: Consensus (soft fork) Title: CHECKTEMPLATEVERIFY

BIP: 120 Layer: Applications Title: Proof of Payment

BIP: 121 Layer: Applications Title: Proof of Payment URI scheme

BIP: 122 Layer: Applications Title: URI scheme for Blockchain references / exploration

BIP: 123 Title: BIP Classification Authors: Eric Lombrozo <elombrozo@gmail.com>

BIP: 124 Layer: Applications Title: Hierarchical Deterministic Script Templates

BIP: 125 Layer: Applications Title: Opt-in Full Replace-by-Fee Signaling

BIP: 126 Title: Best Practices for Heterogeneous Input Script Transactions Authors: Kristov Atlas <kristov@openbitcoinprivacyproject.org>

BIP: 127 Layer: Applications Title: Simple Proof-of-Reserves Transactions

BIP: 128 Layer: Applications Title: Timelock-Recovery Storage Format

This document proposes a mechanism to set up multisig wallets securely.

BIP: 130 Layer: Peer Services Title: sendheaders message

BIP: 131 Layer: Consensus (hard fork) Title: "Coalescing Transaction" Specification (wildcard inputs)

BIP: 132 Title: Committee-based BIP Acceptance Process Authors: Andy Chase <theandychase@gmail.com>

BIP: 133 Layer: Peer Services Title: feefilter message

BIP: 134 Layer: Consensus (hard fork) Title: Flexible Transactions

BIP: 135 Title: Generalized version bits voting Authors: Sancho Panza <sanch0panza@protonmail.com>

This document proposes a convenient, human usable encoding to refer to a within the Bitcoin blockchain--known as . The primary purpose of this encoding is to allow users to refer to a confirmed transaction (and optionally, a particular outpoint index within the transaction) in a standard, reliable, and concise way. ''Please note: Unlike a transaction ID, , where there is a strong cryptographic link between the ID and the actual transaction, a only provides a weak link to a particular transact

BIP: 137 Layer: Applications Title: Signatures of Messages using Private Keys

BIP: 140 Layer: Consensus (soft fork) Title: Normalized TXID

BIP: 141 Layer: Consensus (soft fork) Title: Segregated Witness (Consensus layer)

BIP: 142 Layer: Applications Title: Address Format for Segregated Witness

BIP: 143 Layer: Consensus (soft fork) Title: Transaction Signature Verification for Version 0 Witness Program

BIP: 144 Layer: Peer Services Title: Segregated Witness (Peer Services)

BIP: 145 Layer: API/RPC Title: getblocktemplate Updates for Segregated Witness

BIP: 146 Layer: Consensus (soft fork) Title: Dealing with signature encoding malleability

BIP: 147 Layer: Consensus (soft fork) Title: Dealing with dummy stack element malleability

BIP: 148 Layer: Consensus (soft fork) Title: Mandatory activation of segwit deployment

BIP: 149 Layer: Consensus (soft fork) Title: Segregated Witness (second deployment)

BIP: 150 Layer: Peer Services Title: Peer Authentication

BIP: 151 Layer: Peer Services Title: Peer-to-Peer Communication Encryption

BIP: 152 Layer: Peer Services Title: Compact Block Relay

BIP: 154 Layer: Peer Services Title: Rate Limiting via peer specified challenges

This document proposes a new P2P message to gossip longer node addresses over the P2P network. This is required to support new-generation Onion addresses, I2P, and potentially other networks that have longer endpoint addresses than fit in the 128 bits of the current addr message.

BIP: 156 Layer: Peer Services Title: Dandelion - Privacy Enhancing Routing

BIP: 157 Layer: Peer Services Title: Client Side Block Filtering

BIP: 158 Layer: Peer Services Title: Compact Block Filters for Light Clients

BIP: 159 Layer: Peer Services Title: NODE_NETWORK_LIMITED service bit

BIP: 171 Layer: Applications Title: Currency/exchange rate information API

BIP: 172 Layer: Applications Title: Define Bitcoin Subunits as Satoshis

This document proposes a checksummed base32 format, "Bech32", and a standard for native segregated witness output addresses using it.

This document proposes a binary transaction format which contains the information necessary for a signer to produce signatures for the transaction and holds the signatures for an input while the input does not have a complete set of signatures. The signer can be offline as all necessary information will be provided in the transaction. The generic format is described here in addition to the specification for version 0 of this format.

BIP: 175 Layer: Applications Title: Pay to Contract Protocol

BIP: 176 Title: Bits Denomination Authors: Jimmy Song <jaejoon@gmail.com>

This BIP proposes redefining the commonly recognized "bitcoin" unit so that the base unit becomes the primary reference unit. Under this proposal, one bitcoin is defined as that indivisible base unit, eliminating the convention of synthetic decimal places. By making the base unit the standard measure, this BIP aims to simplify user comprehension, reduce confusion, and align on-chain values directly with their displayed representation.

BIP: 178 Layer: Applications Title: Version Extended WIF

BIP: 179 Title: Name for payment recipient identifiers Authors: Emil Engler <me@emilengler.com>

BIP: 180 Layer: Peer Services Title: Block size/weight fraud proof

BIP: 197 Layer: Applications Title: Hashed Time-Locked Collateral Contract

BIP: 199 Layer: Applications Title: Hashed Time-Locked Contract transactions

BIP: 300 Layer: Consensus (soft fork) Title: Hashrate Escrows (Consensus layer)

BIP: 301 Layer: Consensus (soft fork) Title: Blind Merged Mining (Consensus layer)

BIP: 310 Layer: Applications Title: Stratum protocol extensions

BIP: 320 Title: nVersion bits for general purpose use Authors: BtcDrak <btcdrak@gmail.com>

BIP: 321 Layer: Applications Title: URI Scheme

BIP: 322 Layer: Applications Title: Generic Signed Message Format

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.

BIP: 325 Layer: Applications Title: Signet

BIP: 326 Layer: Applications Title: Anti-fee-sniping in taproot transactions

This document proposes a standard for the [https://eprint.iacr.org/2020/1261.pdf MuSig2] multi-signature scheme. The standard is compatible with [https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki BIP340] public keys and signatures. It supports ''tweaking'', which allows deriving [https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki BIP32] child keys from aggregate public keys and creating [https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki BIP341] Taproot outpu

BIP: 328 Layer: Applications Title: Derivation Scheme for MuSig2 Aggregate Keys

BIP: 329 Layer: Applications Title: Wallet Labels Export Format

BIP: 330 Layer: Peer Services Title: Transaction announcements reconciliation

BIP: 331 Layer: Peer Services Title: Ancestor Package Relay

This document proposes a serialization scheme for compressing Bitcoin transactions. The compressed Bitcoin transactions can reach a serialized size of less than 50% of the original serialized transaction. One method for compressing involves reducing the transaction outpoints in a potentially lossy way. Therefore, it is an optional path for compression. Compressing the outpoints is necessary for compressed transactions to reach less than 70% of the original size.

BIP: 338 Layer: Peer Services Title: Disable transaction relay message

BIP: 339 Layer: Peer Services Title: WTXID-based transaction relay

This document proposes a standard for 64-byte Schnorr signatures over the elliptic curve ''secp256k1''.

This document proposes a new SegWit version 1 output type, with spending rules based on Taproot, Schnorr signatures, and Merkle branches.

This document specifies the semantics of the initial scripting system under [[bip-0341.mediawiki|BIP341]].

BIP: 343 Layer: Consensus (soft fork) Title: Mandatory activation of taproot deployment

BIP: 345 Layer: Consensus (soft fork) Title: OP_VAULT

``` BIP: 346 Layer: Consensus (soft fork)

BIP: 347 Layer: Consensus (soft fork) Title: OP_CAT in Tapscript

This BIP describes a new opcode for the purpose of checking cryptographic signatures in bitcoin scripts against data from the stack.

This BIP describes a new tapscript opcode (`OP_INTERNALKEY`) which pushes the _taproot internal key_ to the stack.

This document defines an improved variant of Bech32 called , 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.

BIP: 351 Layer: Applications Title: Private Payments

This document specifies a protocol for static payment addresses in Bitcoin without on-chain linkability of payments or a need for on-chain notifications.

BIP: 353 Layer: Applications Title: DNS Payment Instructions

This document proposes a new output type: Pay-to-Merkle-Root (P2MR), via a soft fork. P2MR outputs operate with nearly the same functionality as P2TR (Pay-to-Taproot) outputs, but with the key path spend removed. Through this modification, P2MR outputs allow developers to use script trees and tapscript in a manner that is: # resistant to long exposure attacks by Cryptographically Relevant Quantum Computers (CRQCs), and # resistant to future cryptanalytic approaches that may compromise the elli

This document proposes a second version of the Partially Signed Bitcoin Transaction format described in BIP 174 which allows for inputs and outputs to be added to the PSBT after creation.

This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2 that allow for BIP 340/341/342 Taproot data to be included in a PSBT of any version. These will be fields for signatures and scripts that are relevant to the creation of Taproot inputs.

This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2 that allow for pay-to-contract (P2C) key tweaking data to be included in a PSBT of any version. These will represent extra-transaction information required for the signer to produce valid signatures spending previous outputs.

This document proposes additional fields for [[bip-0174.mediawiki|BIP 174]] PSBTv0 and [[bip-0370.mediawiki|BIP 370]] PSBTv2 that allow for [[bip-0327.mediawiki|BIP 327]] MuSig2 Multi-Signature data to be included in a PSBT of any version. These will be fields for the participants' keys, the public nonces, and the partial signatures produced with MuSig2.

This document proposes a standard for 64-byte zero-knowledge ''discrete logarithm equality proofs'' (DLEQ proofs) over an elliptic curve. For given elliptic curve points ''A'', ''B'', ''C'', ''G'', and a scalar ''a'' known only to the prover where ''A = a⋅G'' and ''C = a⋅B'', the prover proves knowledge of ''a'' without revealing anything about ''a''. This can, for instance, be useful in ECDH: if ''A'' and ''B'' are ECDH public keys, and ''C'' is their ECDH shared secret computed as ''C = a⋅B'',

This document proposes additional fields and updated role responsibilities for BIP370 PSBTv2 which adds support for sending to silent payments as described in BIP352.

This document specifies Miniscript, a language for writing (a subset of) Bitcoin Scripts in a structured way, enabling analysis, composition, generic signing and more.

BIP: 380 Layer: Applications Title: Output Script Descriptors General Operation

BIP: 381 Layer: Applications Title: Non-Segwit Output Script Descriptors

BIP: 382 Layer: Applications Title: Segwit Output Script Descriptors

BIP: 383 Layer: Applications Title: Multisig Output Script Descriptors

BIP: 384 Layer: Applications Title: combo() Output Script Descriptors

BIP: 385 Layer: Applications Title: raw() and addr() Output Script Descriptors

BIP: 386 Layer: Applications Title: tr() Output Script Descriptors

BIP: 387 Layer: Applications Title: Tapscript Multisig Output Script Descriptors

BIP: 388 Layer: Applications Title: Wallet Policies for Descriptor Wallets

BIP: 389 Layer: Applications Title: Multipath Descriptor Key Expressions

BIP: 390 Layer: Applications Title: musig() Descriptor Key Expression

BIP: 392 Layer: Applications Title: Silent Payment Output Script Descriptors

BIP: 431 Layer: Applications Title: Topology Restrictions for Pinning

BIP: 433 Layer: Applications Title: Pay to Anchor (P2A)

This BIP defines a peer-to-peer (P2P) message that can be used for announcements and negotiation related to support of new peer-to-peer features.

This BIP proposes a new tapscript opcode, `OP_PAIRCOMMIT`, which enables efficient and secure commitment to pairs of stack elements using a tagged hash construction. This opcode provides limited vector commitment functionality, facilitating more expressive contracts and improved data availability in Bitcoin scripts.

BIP: 443 Layer: Consensus (soft fork) Title: OP_CHECKCONTRACTVERIFY

This document proposes a new operation for [Tapscript][tapscript-bip]: `OP_TEMPLATEHASH`. It introduces the ability to push on the stack a hash of the transaction spending an output.

This document proposes deploying three new operations for [Tapscript][tapscript-bip]: [BIP 446 `OP_TEMPLATEHASH`][templatehash-bip], [BIP 348 `OP_CHECKSIGFROMSTACK`][csfs-bip], and [BIP 349 `OP_INTERNALKEY`][internalkey-bip]. These minimal operations introduce modular functionalities which improve existing second layer protocols and make new ones possible through plausible interactivity requirements.

This spent several months gathering feedback from the mailing list and from other advisors. This is hopefully polished enough to submit upstream. Let me know if you have any questions or feedback, and of course feel free to submit suggestions. Thank you for your time.

BIP-446 got merged, redirecting to bitcoin/bips repo.

This PR adds version 2 to the "Versions Requiring Inclusion" column (currently empty) for the `PSBT_GLOBAL_VERSION` field. See [BIP-370](https://github.com/theStack/bips/blob/master/bip-0370.mediawiki): https://github.com/bitcoin/bips/blob/2778442c21cef2290ae3e0c843d9f3179aa1cdd0/bip-0370.mediawiki?plain=1#L41

Mailing list thread at https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8 --- Editor note: please post conceptual feedback and meta-commentary on the mailing list [thread](https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8), and focus here on: - expert technical review of the specification - specific, concrete, helpful proposals for the other sections Please refrain from personal or heated commentary, trolling, pedantry, and repeating yourself. As this PR now has many comments, please on

Opening this here for wider discussion and feedback. edit: Probably need to add implementation section: https://github.com/instagibbs/bitcoin/tree/2025-07-op_templatehash

We propose a new BIP for Chain Code Delegation, a collaborative custody technique that involves privileged participants (delegatee) withholding BIP32 chain codes at key setup time from a delegator, and sharing only enough information for non‑privileged participants to provide their signature. For non-blinded signing, the delegatee derives a per‑spend scalar tweak t from the (withheld) chain code, the delegator computes the child key (x+t, P+tG), and produces a standard signature over the transa

The checksum calculation should be consistent in all implementations.

This introduces test vectors for BIP54. There is one set of vectors per each of the 4 mitigations. The vectors were generated using the BIP54 implementation against Bitcoin Inquisition available [here](https://github.com/bitcoin-inquisition/bitcoin/pull/99), as well as a custom miner as a Bitcoin Core unit test available [here](https://github.com/darosior/bitcoin/commits/bip54_miner/). Documentation is provided with more details about each set of test vectors and describing how to use them.

`OP_PAIRCOMMIT` is the newest member of the LNhance family of opcodes. It provides limited vector commitment functionality in tapscript. When evaluated, the `OP_PAIRCOMMIT` instruction: * pops the top two values off the stack, * takes the "PairCommit" tagged SHA256 hash of the stack elements, * pushes the resulting commitment on the top of the stack. Discussion: https://delvingbitcoin.org/t/op-paircommit-as-a-candidate-for-addition-to-lnhance/1216/12 Mail list proposal: https://groups.google.

### Summary This PR adds a `Requires: 32, 43` header to BIP-0044. ### Motivation BIP-0044 explicitly states in its abstract and specification that it is based on the HD wallet structure defined in BIP-0032 and applies the purpose scheme defined in BIP-0043. This dependency is currently described in the text but could be extended to the preamble. This change would make BIP-0044 more consistent to the BIP process and would make its interoperability with other BIPs clearer.

See the discussion in the corresponding secp256k1 PR (https://github.com/bitcoin-core/secp256k1/pull/1519#issuecomment-2142599641, https://github.com/bitcoin-core/secp256k1/pull/1519#issuecomment-2143167510, https://github.com/bitcoin-core/secp256k1/pull/1519#issuecomment-2144837459), where it was recommended to include this corner-case in the BIP by real-or-random: > Indeed, this should be in the BIP, ideally even in the pseudocode. If our code starts to reject "payments", then better be autho

This PR adds [secp256k1lab](https://github.com/secp256k1lab/secp256k1lab) version 1.0.0 as subtree within the `bip-0352` folder [1] and takes use of it in the reference implementation. In particular, the file `secp256k1.py` is removed and the `GE` and `Scalar` classes are used from the secp256k1lab.secp256k1, replacing `ECPubKey` and `ECKey`, respectively. See the [main commit message](https://github.com/bitcoin/bips/commit/e2b50af0a657d17a0fc6437538e8879d5818af45) for a detailed table of replac

* Add two use cases to motivation * Add BIP 003 versioning * Test vectors

Picks up @ddustin's work in https://github.com/bitcoin/bips/pull/785, updated with the latest reviewers' feedback.

In bip-0069_examples.py: - Fix print_outputs() to use sorted output tuples instead of unsorted - Add Python 3 compatibility using functools.cmp_to_key() - Convert string hashes to byte arrays in second example - Make file executable with shebang for python3 - Add clearer output formatting with transaction hashes and section headers

This builds on and provides an alternative to #2026, which references an [earlier discussion](https://btctranscripts.com/bitcoin-core-dev-tech/2024-04/silent-payment-descriptors). Instead of modifying BIP352, a new output descriptor format is proposed in the style of BIPs 381-387. Similar to #2026 key expressions starting with `spscan` and `spspend` are specified, but contain only version and key material information. The wallet birthday and additional labels are specified as optional addition

Updates to match the reference implementation and address community feedback: - **Rule 2**: Several people were confused about which witness stack elements are limited by rule 2, so I have added a definition for "script argument witness items" (@murchandamus' preferred nomenclature) with a FAQ entry explaining exactly which elements are excluded and why. See [this thread](https://github.com/bitcoin/bips/pull/2017#discussion_r2854672336) on the original PR for more context. - **Deployment**: The

musig() was previously specified as only usable under tr(), but the BIP-390 test vectors already include valid rawtr(musig(...)) descriptors and Bitcoin Core’s descriptor implementation accepts musig() as a generic KEY under both tr() and rawtr(). This change updates the wording to explicitly allow musig() inside rawtr(), aligning the specification with the existing test vectors and Core semantics without changing any behavior.

As previously announced in the [libsecp256k1 `silentpayments` module discussion](https://github.com/bitcoin-core/secp256k1/issues/1799#issuecomment-3842046237) and on the [mailing list](https://groups.google.com/g/bitcoindev/c/tgcAQVqvzVg) ~2 weeks ago, this PR introduces a `K_max` limit to BIP-352 to mitigate worst-case scanning time for adversarial transactions. So far [no objections have been raised](https://github.com/bitcoin-core/secp256k1/issues/1799#issuecomment-3891774608) against that p

The version-rolling.min-bit-count field was previously documented as a TMask return value, even though the examples and real-world usage treat it as a request parameter with an integer bit count. This change moves version-rolling.min-bit-count to the extension parameters section and changes its type to Integer (>= 0), keeping the original explanatory text. This makes the specification consistent with the JSON examples and with existing implementations of the stratum protocol extension.

BIP 129 requires several prerequisite BIPs, so state them in a "Requires" header.

The changes are ported from PR 1705 so that the same public key terminology is reflected in BIP 174 as well. Please refer this other PR for more details.

to clarify the relationship between BIPs 20 and 21.

Removed an unmatched </tt> tag from the "Multiple Extended Keys" section heading. The extra closing tag had no corresponding opening <tt>, produced invalid markup, and was inconsistent with how other descriptive headings are formatted in BIPs.

Added the missing reference entry for BIP8 in the References section of BIP-0117 so that the in-text citation “BIP8 (Version bits with lock-in by height)[9]” points to a valid BIP URL.

This simple BIP explains what Timelock-Recovery plans are, and how they to store them In a standard JSON format, that services could parse and then monitor/execute.

@RubenSomsen [announced](https://github.com/bitcoin-core/secp256k1/issues/1799#issuecomment-3773155788) that @theStack was added as an Author in January. This PR adds him to the document to reflect this change.

18 English mnemonic should be 192 bits here

This is a first draft of applying the changes prescribed by BIP 3 in the section [Updates to Existing BIPs should this BIP be Activated](https://github.com/bitcoin/bips/blob/master/bip-0003.md#updates-to-existing-bips-should-this-bip-be-activated). It also updates the CI-scripts to align with the new formatting. ---- Resolved: - [x] @real-or-random’s proposal to update the Licensing scheme - [x] Enforce order of headers in Preamble and fix order in BIPs that don’t conform Planned for follow

Before: <img width="487" height="508" alt="Screenshot 2026-02-04 at 11 44 37 AM" src="https://github.com/user-attachments/assets/8d34ed86-3479-4c2f-84b1-ef737dd3f79b" /> After: <img width="487" height="507" alt="Screenshot 2026-02-04 at 11 43 49 AM" src="https://github.com/user-attachments/assets/c9e15e83-0492-4557-b392-4a7f9466f4fb" /> https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables#formatting-content-within-your-tab

Make the header match the text.

Correct two test-case headings that incorrectly used PSBT_KEY_PATH_SIG. The canonical Taproot key-spend field name is PSBT_IN_TAP_KEY_SIG (0x13) per BIP-371/BIP-174, so using PSBT_KEY_PATH_SIG was inconsistent and potentially confusing.

The feature message is intended to be used repeatedly prior to verack, so it should have a short id to save a little bandwidth, and the identifier has to be hardcoded, because it's used before negotiation is completed.

Assuming a by one increment in the keytype of the silent payments output fields, the following numeral to 0x09 in the hexadecimal system is 0x0a, not 0x10.

BIP 324 introduced single-byte short identifiers for messages used multiple times in a connection, relating them to existing v1 messages, however it left it ambiguous as to what should happen if a 13-byte message_type was received. Clarify that the single byte message types are simply aliases for the longer equivalents, and that nodes should behave identically whether a message uses a one byte message_type or the equivalent 13-byte message type. Also lowercases the message types (matching the o

Following up on the recent decision that [secp256k1lab](https://github.com/secp256k1lab/secp256k1lab) should be vendored per-BIP if needed/useful (see https://github.com/bitcoin/bips/pull/2004#issuecomment-3713521737 ff. and https://github.com/bitcoin/bips/pull/1855#issuecomment-3723682682 ff.), this PR exercises this for BIP-374. The changes add secp256k1lab version 1.0.0 as subtree [1] within the `bip-0374` folder and take use of it in the reference implementation. In particular, `secp256k1.py

Abstract: This BIP defines a peer-to-peer message that can be used for announcements and negotiation related to support of new peer-to-peer features. Mailing list post: https://gnusha.org/pi/bitcoindev/aUUXLgEUCgGb122o@erisian.com.au/T/#u Mailing list discussion: https://groups.google.com/g/bitcoindev/c/DFXtbUdCNZE

## Semantic changes I thought it might be valuable to keep track of actual semantic changes being made since the initial out-of-draft version. * 2023-12-19: Added relative indices for individual mode. ## Implementations * A proposed implementation for Bitcoin Core is available here: https://github.com/bitcoin/bitcoin/pull/29050 * A proposed implementation for rust-bitcoin is available here: https://github.com/rust-bitcoin/rust-bitcoin/pull/2275

BIP14’s Discussion header only had the date, so I’m backfilling the header with links to the discussions. Thanks to @ajtowns for [digging these up](https://github.com/bitcoin/bips/pull/1820#issuecomment-3757836846).

Looks like i typed this one by hand incorrectly, thanks to Chris Stewart for noticing.

While reviewing https://github.com/bitcoin/bitcoin/pull/31247 a while ago I noticed that the mentioned public keys in the PSBT fields of this BIP are quite confusing. This is mostly due to a non-consistent mention of types (plain vs. x-only) and a purpose that is sometimes missing. This PR aims to improve this in the following ways: - be specific about the purpose of pubkey types in PSBT fields ("plain pubkey" alone doesn't say a lot, especially if it's used repeatedly within a field; explicitly

This change updates descriptions for the `PSBT_IN_PREVIOUS_TXID` field to specify serialization order. It was not straightforward the order with which to store the txid in a psbt. It's not clearly specified in the spec, and there are not many resources or parsers to aid in debugging PSBTv2. I found the BIP370 test vector "Case: PSBTv0 but with PSBT_IN_PREVIOUS_TXID." seems to imply that the order of this txid value in `PSBT_IN_PREVIOUS_TXID` should match network serialization order. I'm torn o

Updated sequence diagrams to use text format instead of mermaid syntax responding to @achow101's [comment](https://github.com/bitcoin/bips/pull/1483#discussion_r2430441734) I cargo cult'd the RFC Rules: > “How are images handled for the plain text version of an RFC?” > The RFC Editor will accept both ASCII art and SVG. If only ASCII art is provided, it will be included in all publication formats. If ASCII art and SVG are both provided, ASCII art will be included in the plain text, and SVG in a

For interoperability with other schemes, it behooves me to write a BIP for this output type. It's already standard to spend in well over half the network. h/t roasbeef for bothering me about this repeatedly

Removes redundant duplicate condition check that was evaluating the same block height twice in the test vector generation loop.

This document proposes an asynchronous, backwards-compatible second version of the payjoin protocol described in [BIP 78](bip-0078.mediawiki), enabling complete payjoin receiver functionality including payment output substitution with only an HTTP client rather than server. The former requirement for receivers to run HTTP servers is replaced with an untrusted third-party "payjoin directory" store-and-forward server accessed by polling clients which communicate using an asynchronous protocol and

The Signing section previously stated that signers may add additional outputs to to_sign for proving control of funds. This contradicts the Full (Proof of Funds) subsection, which specifies that the claimed UTXOs must be included as additional inputs of to_sign and validated against the current UTXO set, and also conflicts with the requirement that to_sign has exactly one output (an OP_RETURN).

Corrected the Input Data → Outpoint description to refer to the uncompressed outpoint instead of an uncompressed signature. The previous wording was misleading and inconsistent with the linked Uncompressed Outpoint section. This change clarifies the intended reference without modifying any encoding details or test vectors.

This PR addresses feedback from the mailing list and a recent pull request to BIP 3. The following functional changes are made: - Revert the recently added AI guidance - Broaden the formats per which reference implementations may be provided - Move Type header responsibility to the author(s) A Changelog section is added and backfilled, and a few editorial improvements are made. The Version header is omitted at this time, since it is not permitted under BIP 2.

This was implicit in the genesis block's nbits value, but better to be clearer.

Various terminology fixes, typo fixes and phrase fixups from #2040 and #2023. @apoelstra said: >In the interest of moving forward I would kinda like Ben to make a new PR with the non-HRP changes, which it seems like everyone agrees with and would reduce the size of the diff of this one. https://github.com/bitcoin/bips/pull/2040#issuecomment-3617849434 This is that PR.

Silent payments is a static address protocol for Bitcoin, originally proposed on the mailing list here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020180.html Since then, the proposal has received several rounds of review and has a WIP implementation here: https://github.com/bitcoin/bitcoin/pull/27827 . The proposal has also been sent to the mailing list for review here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021750.html Proposing this as an

Replaced incorrect PSBT key name PSBT_IN_GLOBAL_XPUB with the canonical PSBT_GLOBAL_XPUB (per BIP 174). This corrects scope naming (GLOBAL vs per-input) and aligns with existing PSBT specifications. Removed duplicated/garbled sentence and punctuation in the reference note explaining why compressed pubkeys are used instead of x-only. The note now clearly states the evenness-byte requirement and fingerprint rationale without repetition.

* 1st commit: The existing wording on master could be taken to mean that 64-byte transactions reduce implementation complexity for SPV wallets. * 2nd commit: Uses distinct notation for txids and tx-bytes.

A PSBT should be considered invalid if the size of `<valuedata>` doesn't match the specified size in `<valuesize>`. However we don't have any test case for it (and might be not well specified?). During differential fuzzing I noticed this is currently verified in Bitcoin Core (see below) but not checked in other implementations (e.g. btcd), causing a mismatch between them. ```cpp // Takes a stream and multiple arguments and unserializes them first as a vector then each object individually in the

The BIP 54 sigops limit was made a standardness rule in Bitcoin Core 30.0 with the merge of https://github.com/bitcoin/bitcoin/pull/32521.

Supersedes #1024 Link to rendered version for your convenience: https://github.com/dhruv/bips/blob/bip324/bip-0324.mediawiki Open questions: - The BIP text currently includes a [table for 1-byte message type IDs](https://github.com/dhruv/bips/blob/bip324/bip-0324.mediawiki#v2_Bitcoin_P2P_message_structure). The process for updating this table atomically to assign new IDs when new message types are being proposed is likely going to be an annoyance. What are better ways to handle ongoing allocat

and soundness, and ensure it was proposed to the ML by one of the BIP authors. Follows up on the discussion starting from https://github.com/bitcoin/bips/pull/2005#issuecomment-3408065869.

collision: BIP-8 was marked as [9] but [9] referenced [https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP68: Relative lock-time using consensus-enforced sequence numbers] also added a link for consistency with the rest of the bip

The main issue is the text seemed ambiguous on whether the limit applied per input, or over the total transaction summing over all inputs. I added some language directly ripped from bip16, and made it clearer, I hope, that each field is evaluated separately.

Clarify that the BIP author(s) post a new, dedicated thread on the mail list to present the idea. Address situations like https://github.com/bitcoin/bips/pull/2017#issuecomment-3448601772.

There's been confusion about this, so add the following clarification: "A number may be considered assigned only after it has been publicly announced in the pull request by a BIP Editor." The following, for instance, should not constitute assignment of a BIP number: - an announcement on social media - a provisional entry to the internal editor notes, pending feedback from the other editors (the entry can be subsequently removed) As well, BIP 2 already stipulates that assignment take place in

Ensure consistency by passing m=message when verifying a tampered proof Strengthens the test to match the proof generation context No behavior change expected; tests pass locally

Supersedes https://github.com/bitcoin/bips/pull/1969. On top of https://github.com/bitcoin/bips/pull/1969. I'm one of the authors of BIP324 but let's wait for an ACK from @sipa, please.

https://cyber.stanford.edu/sites/g/files/sbiybj9936/f/jeremyrubin.pdf - this link doesn't work https://rubin.io/public/pdfs/multi-txn-contracts.pdf - this link works

TorV2 is deprecated, implementations are removing any support for it and we could specify this deprecation here. Especially because implementations are no longer serializing/deserializing and relaying Tor v2 addresses, they're ignoring incoming Tor v2 addresses, etc.

Problem: In GenerateProof step 85 the self-check calls VerifyProof(A, B, C, proof) without G and m, but VerifyProof is defined as VerifyProof(A, B, C, proof, G, m). This omission breaks self-check when a non-empty message m is used or when a non-default generator G is passed. Evidence: Spec definition requires G and m: The algorithm ''VerifyProof(A, B, C, proof, G, m)'' is defined as: * Fail if any of ''is_infinite(A)'', ''is_infinite(B)'', ''is_infinite(C)'', ''is_infinite(G)'' *

Fix test harness to correctly fail when public key generation does not match the expected vector. Previously, the “Failed key generation” branch only printed diagnostics without updating all_passed, leading to a false-positive overall test result. This is a bug because a keygen mismatch indicates an implementation error that must cause the test run to fail, consistent with how other failures in the harness set all_passed = False.

Genesis block time is correct in Unix time, but human readable version is off by 10 minutes. (Single digit typo) Basically this changes the fingerprint, so should be consistent so as to ensure compatibility between BIP85-GPG implementations. (I am comparing my SeedSigner to Krux GPGap in this instance, the latter of which has gone with the human-readable time from the BIP whereas I went with Unix time and couldn't work out why the same input produced different results...)

- Add Reference Implementation section, using the BIP author's suggested implementation in https://github.com/bitcoin/bips/pull/1911#issuecomment-3324867313 - Mention replacement in addition to modification with respect to BIP21, for consistency with the "Replaces: 21" header

Clarifies existing intent without changing the on‑wire format. • Publishers: one TXT RR whose RDATA may contain multiple <character-string>s (≤255 bytes each, RFC 1035 §3.3.14). • Clients: concatenate the RR’s strings in RDATA order (no separators) before parsing; do not concatenate across multiple TXT RRs; if multiple bitcoin: TXT RRs exist at the same name, treat as invalid.

Renames the “Created” header to “Assigned” to better reflect the meaning of the date held in this header field.

@ajtowns pointed out in his [BIP 3 review]( https://github.com/bitcoin/bips/pull/1712#discussion_r1946113305) that the author email addresses in the preamble of BIPs in markdown format were not being rendered.

Not sure what the right timeline for this is, but at some point this should happen.

A BIP status of Active is only for Process BIPs. - BIP 327 should be Final, not Active. - BIP 353 has an open PR with test vector additions, should be Proposed.

I think this can be advanced to Active as several projects have implemented support. BIP 353 has been implemented by Phoenix, Cake Wallet, Sparrow, and CLN. Additionally, some LDK-based and breez-sdk-based projects are working on support. cc: @TheBlueMatt

Update status of BIPs 157 and 158 from Draft to Final. As described in https://github.com/bitcoin/bitcoin/blob/8ee8a951c205c5365f7557253b8fffc12e6e670c/doc/bips.md, BIPs 157 and 158 have been deployed since 2020: *Compact Block Filters for Light Clients can be indexed as of **v0.19.0** ([PR #14121](https://github.com/bitcoin/bitcoin/pull/14121)) and served to peers on the P2P network as of **v0.21.0** ([PR #16442](https://github.com/bitcoin/bitcoin/pull/16442)).* Also add `Requires` headers in

The `NODE_BLOOM` service bit has been deployed in Bitcoin Core since https://github.com/bitcoin/bitcoin/pull/6579.

This PR adds intermediate computation vectors to the BIP-352 reference implementation to improve development experience and code clarity. Changes - Updated reference.py to validate intermediate values during silent payment computations - Added comprehensive intermediate vector material to send_and_receive_test_vectors.json - Applied labels suggestion by @fifalodm to scanning Benefits - secp256k1 library no longer needs to handle silent payments specific code, intermediate values

Replace unintended reference to local variable name `desc` with the correct method parameter `descriptor` in `from_descriptor`. The previous code raised a NameError when scanning operators because desc is not defined in that scope. This change aligns with the rest of the method, which consistently uses descriptor, and allows the example in main to run without error.

Fix two chained assignments.

BIP155 was deployed in Bitcoin Core version v0.21.0, and has been in use for almost 5 years. New networks may be added to the reserved network IDs table, when they're needed, either in this BIP (seems fine) or in a new one. If BIP3 is activated, I think BIP155 would become Deployed.

- Update MIT license name per https://opensource.org/license/MIT and https://spdx.org/licenses/MIT - Fix up license URLs with 301 redirects

Picks up #1931 and adds a commit to update the MIT license name. Changes: - Fix up license URLs with 301 redirects - Add MIT-0 License - Update MIT license name per https://opensource.org/license/MIT and https://spdx.org/licenses/MIT

Replace `Base64` by `Base85` encoder in the Pwd Base85 section, and use consistent capitalization.

- Updated MES16 paper link to crypto.news mirror - Fixed outdated bitcoin-inquisition repo link

Remove from itertools import permutations which is not used anywhere Re-checked the codebase: no calls to permutations(...)

broken: https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki correct: https://github.com/instagibbs/bips/blob/527b007dbf5b9a89895017030183370e05468ae6/bip-ephemeralanchors.mediawiki

Replaced outdated link to “Create Payment Request generator” in bip-0070.mediawiki: https://bitcoincore.org/~gavin/createpaymentrequest.php → https://developer.bitcoin.org/examples/payment_processing.html

Remove leftover debug print statement that was printing private keys(seckey_a_hex) to console during test execution. Improves test output readability and consistency.

Addresses follow-up from https://github.com/bitcoin/bips/pull/1892#issuecomment-3157328596

This has been discussed in https://github.com/bitcoin/bips/pull/1819#pullrequestreview-2770098094/ See individual commit messages for further rationale. I can squash the commits if this will be cleaner. This doesn't touch all the "License" and "License-Code" headers yet. Let's first agree on the changes, and then we can implement them.

The recovery scriptPubKey needs to be prefixed with its CompactSize-encoded length when computing the sPK hash. I verified this by: - Checking the [functional tests](https://github.com/jamesob/bitcoin/commit/5e59c074703f0913db7ee004b99d086857d10ad6#diff-65a47d52759ba7800338bacb3005836bdc0f3962de356621e5c50887c85c4af8R1407-R1409), where `recovery_spk_tagged_hash()` is implemented using [`ser_string()`](https://github.com/bitcoin/bitcoin/blob/af3dee0b8d456a8aa9ade9c6e7f4283a90590eae/test/function

Itinitializes -> It initializes

While implied by the specification, add an explicit warning that generated outputs MUST not be omitted from the final transaction.

Location: In the ["Specification" section.](https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki#specification) Original: This is a specific naming convention to make sure it is not confused with **_the actual the transaction_** ID that it will have after it is broadcast... Correction: This is a specific naming convention to make sure it is not confused with **_the actual transaction_** ID that it will have after it is broadcast... Reason: The word "the" is repeated.

## Changes - **File:** `bip-0070.mediawiki` - **Line 265:** Updated Mozilla root store URL - **From:** `http://www.mozilla.org/projects/security/certs/included/index.html` - **To:** `https://www.mozilla.org/about/governance/policies/security-group/certs/policy/`

Update broken fc16.ifca.ai link to working Internet Archive URL in bip-0347.mediawiki - Replace http://fc16.ifca.ai/bitcoin/papers/MES16.pdf with https://web.archive.org/web/20220203124718/https://fc16.ifca.ai/bitcoin/papers/MES16.pdf - Fixes reference to Bitcoin Covenants paper by M. Moser, I. Eyal, and E. G. Sirer - Ensures the vaults use case documentation remains accessible The original fc16.ifca.ai domain is no longer accessible, but the paper is preserved through the Internet Archive.

based on @real-or-random's https://github.com/bitcoin/bips/pull/1892#issuecomment-3051961323. Also a couple of minor BIP3 touch-ups.

Typo fixup: Align the first field in the serialization table with the rest, which use plural “bytes” (e.g., “4 bytes: child number”) for consistency.

While this is statistically improbable, e.g., we don't yet know of a hash preimage that results in an output = 0 or greater than the curve order, we still want to be explicit on how to handle this (same as we do for the tweaks themselves).

Corrected a typo in the output_cmp function where the non-existent function bytearray_cmp was called. Changed it to the correct function name bytearr_cmp to ensure proper output comparison and prevent runtime errors. This fix improves code reliability and consistency.

This PR addresses the concerns raised in #1885 with regards using `+` as a delimiter, by switching to `-`. Some URI libraries implement RFC 1866's (HTML 2.0) "keyword" delimitation in query parameters by decoding `+` as ` ` unconditionally, which necessitates kludgy workarounds. Additionally fragment parameters must now ordered lexicographically (instead of reverse), the motivation for a canonical ordering was to reduce implementation fingerprinting concerns, but the reverse lexicographical ord

add hyperlinks to BIPs 327

fix: descriptor in "Taproot wallet policy with sortedmulti_a and a miniscript leaf" test vector which incorrectly uses `@0` from keys info without key origin derivation

BIP3 got a bit more review from @RubenSomsen, @darosior, and @jonatack. Thanks! This PR addresses the review. Most of it related to minor phrasing improvements, typos, and added emphasis. I also added mention of the Version header and Changelog to the Backward Compatibility section which I had overlooked, and explain why I consider the headers "Superseded-by" and "Replaces" asymmetric, and only propose a new name for "Superseded-by" but retain "Replaces". **This PR includes a deletion and rea

Me and my students noticed a discrepancy in the test vectors and specification regarding the allowed characters denoting hardened nodes. The [BIP380](https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki) specs allows all three `h`, `'` and `H`, in particular the specs read: > In the above specification, the hardened indicator `h` may be replaced with alternative hardened indicators of `H` or `'`. However, the following is then an **invalid** test vectors: > [deadbeef/0H/0H/0H]0260b

Removing duplicate address example that's exactly the same as above. @TheBlueMatt

This BIP makes 64 byte bitcoin transactions serialized without the witness consensus invalid Mailing list post: https://groups.google.com/g/bitcoindev/c/rf3QOlzg230/m/eOOC8pkOAgAJ Delving discussion: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710 Side note, wasn't sure how to best handle the 2-Bitcoin-Merkle.pdf as it isn't hosted anywhere easily accessible AFAICT? For now I just added it into the git repo. Lmk if you have other suggestions

Clarify to readers that the addresses used in the examples are intentionally invalid to prevent accidental transactions.

This BIP specifies a standard way to generate and verify DLEQ proofs. This is motivated by sending to silent payments in PSBTs. However, there are also other uses where DLEQs could be useful, so it would be good to have this BIP for others to reference. This is inspired by https://github.com/discreetlogcontracts/dlcspecs/blob/master/ECDSA-adaptor.md#proof-of-discrete-logarithm-equality, but is a little more specific. There is an implementation of that already at https://github.com/BlockstreamRe

Collects various fixups from #1859, #1862, and #1863 with credit to the original commit authors.

Hi all, This is a draft for the formal specifications of the `OP_CHECKCONTRACTVERIFY` (`CCV`) opcode. `CCV` enables to build Script-based state machines that span across multiple transactions, by providing an ergonomic tool to commit to - and introspect - the Script and possibly some _data_ that is committed inside inputs or outputs. Related to this PR: - [Implementation in bitcoin-core](https://github.com/bitcoin/bitcoin/pull/32080) - [Post on delving bitcoin](https://delvingbitcoin.org/t/op

This PR is a proposal for a new BIP to define a standard on m/48' derivation paths used in modern day hierarchical deterministic multi-sig wallets.

This PR updates the link to the experimental hardfork-timewarp-0.11 branch, which was a PoC for a TimeWarp hardfork fix.

Fixes an out-of-date link: before https://github.com/btcsuite/btcutil/blob/master/txsort/txsort.go after https://github.com/btcsuite/btcd/blob/master/btcutil/txsort/txsort.go

As discussed on https://github.com/bitcoin/bips/pull/1835#pullrequestreview-2837827946, the addition to P2TR was incompletely specified, and BIP48 should no longer be changed. Therefore, I propose to revert the changes, and to move BIP48 to final instead.

The social media account linked to in BIP341 was deleted some time ago: https://twitter.com/pwuille/status/1108097835365339136 This pull proposes to replace the link with: https://web.archive.org/web/20220531184542/https://twitter.com/pwuille/status/1108085284862713856 Alex Waltz and I didn't find a web archive of the original tweet (see thread up to https://x.com/raw_avocado/status/1924610087034757158 yesterday) but this one looks like a good replacement -- h/t to Hunter Beast who found it

Since the version is denoted as uint64, the size should be 8 bytes.

This BIP proposes redefining the bitcoin unit of account to represent the protocol’s smallest indivisible unit as “1 bitcoin,” eliminating the need for decimal-based UI conventions. - Type: Informational - No changes to consensus rules or supply - Matches Bitcoin’s native integer representation - Includes multi-phase rollout recommendations Authored by: John Carvalho (@BitcoinErrorLog) Mailing list: https://groups.google.com/g/bitcoindev/c/YwF-djZi1Bo/m/nIkyuClEAgAJ

Fixed incorrect preposition in key tweaking explanation: - `multiplied on` → `multiplied by` - Clarified BIP-340 key serialization: - `appending '02'` → `appending '0x02'` - Removed unnecessary trailing comma in the list of output types - Removed erroneous semicolon after URL

The BIPs were over two years old. Also I noticed they were wordy and unclear. I shortened them and added better tables and figures to make them easier to read.

BIP48 currently defines script types only for p2wsh and p2sh-p2wsh, but not for the newer p2tr. This PR proposes defining the the script_type for p2tr as `3`, to provide a clear standard for the derivation to use in p2tr scripts.

This proposal has basically been replaced by #1793. See https://delvingbitcoin.org/t/withdrawing-op-vault-bip-345/1670 for rationale.

Follow-up to https://github.com/bitcoin/bips/pull/1835.

Formally define the smallest subunit of a bitcoin as a "Satoshi"

This BIP defines OP_CAT a new tapscript opcode which allows the concatenation of two values on the stack. This opcode would be activated via a soft fork by redefining the opcode OP_SUCCESS126. See our implementation PR in bitcoin-inquisition: https://github.com/bitcoin-inquisition/bitcoin/pull/39

This is a BIP draft for a Consensus Cleanup soft fork. This proposal builds upon Matt Corallo's 2019 [proposal](https://github.com/TheBlueMatt/bips/blob/7f9670b643b7c943a0cc6d2197d3eabe661050c2/bip-XXXX.mediawiki), which i set to revive at the end of 2023. I eventually shared my research in a [Delving Bitcoin post](https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710) in early 2024 (along with a [semi-private companion post](https://delvingbitcoin.org/t/worst-block-validation-time-i

old has 404-error

As Bitcoin has grown, the introduction of new address formats describing new forms of payment instructions has become increasingly fraught with compatibility issues. Not only does there exist traditional on-chain addresses, but some recipients wish to receive Lightning (when the sender supports it) or newer formats such as Silent Payments. This has led to increasing use of the BIP 21 query parameters to encode further optional payment instructions. Looking forward, as new payment instructions

I just noticed inconsistency between BIPs dealing with the account structures: - BIP-00{43,49,84} were Informational, while BIP-00{44,86} are Standards Track => this PR changes the former to the Standards Track too - BIP-0044 was not marked as Final where BIP-00{43,49,84,86} are => let's mark BIP-0044 as Final too

I would like to add my HD (paper) wallet implementation to BIP{32,39,85}. It is written as a follow up to reading @jimmysong great book - Programming Bitcoin. I had some issues trying to figure out what is going on just by looking on some other python implementations so I decided to write my own as a part of learning process. It should be easy to read and has a heavy load of unit tests. I hope it will help some novice bitcoiners to make their learning curve less steep.

- **Corrected a logic bug in `gen_test_vectors.py`** Previously, the message tampering logic mistakenly used the proof damage index (`proof_damage_pos`) instead of the correct message index (`msg_damage_pos`). This could result in ineffective or misleading bit-flip tests. Now fixed to use the correct index for tampering the message. - **Modernized usage of `csv.reader` in `run_test_vectors.py`** Replaced the outdated `reader.__next__()` with the idiomatic and Python 3–safe `next(rea

This commit implements the subtraction operator (__sub__) for the GE (Group Element) class in the secp256k1.py file as requested in the TODO comment in reference.py. The implementation is straightforward, leveraging the existing __neg__ method to define subtraction as addition with the negated element: self + (-a). After implementing the operator, the code in reference.py was simplified by replacing expressions like: s * G + (-e * A) with s * G - e * A This makes the code more readable and di

User behavior has clearly indicated a strong demand for the resolution of human-readable names into payment instructions. This BIP defines a protocol to do so using only the DNS, providing for the ability to query such resolutions privately, while utilizing DNSSEC to provide compact and simple to verify proofs of mappings. I'd like to hereby request a BIP number assignment. What is the current approach to do so - since the mailing list has died, is a post on delving bitcoin the appropriate plac

This pull request corrects several grammatical errors and typos in BIP-0329.mediawiki and BIP-0078.mediawiki files. # Changes in BIP-0329.mediawiki: Fixed incorrect word "independant" to "independent" in line 164: - * <tt>keypath</tt>: The data needed to build full descriptor down to the specific address. This extends <tt>origin</tt> with the final two components that are unhardened (in the typical case, assuming BIP-84). Provide string <tt>/1/123</tt> for <tt>wpkh([d34db33f/84'/0'/0'/1/123

This _Bitcoin Improvement Proposal (BIP)_ proposes new guidelines for the preparation of BIPs and policies relating to the publication of BIPs. If adopted, it would replace [BIP 2](bip-0002.mediawiki). ---- From the BIP: ### Changes from BIP 2 #### Workflow - Status field values are reduced from nine to four: - Deferred, Obsolete, Rejected, Replaced, and Withdrawn are gathered up into Closed. - Final and Active are collapsed into Deployed. - Proposed is renamed to Complete. - The rem

This PR fixes a typo.

This PR makes the following changes: 1. BIP-0015: Fixes typo in the word "that" and improves readability of the address example explanation 2. BIP-0020: Improves message text clarity by adding "is" in the QR code scanning message These are minor text improvements that don't change the technical content of the BIPs but make them more readable and grammatically correct.

s/compution/computation/

`decypt` to `decrypt`

Follow-up to #1807.

See https://github.com/bitcoin/bips/commits/master/bip-0340 for a list of contributors. I have obtained permission to do this change from all contributors in private. Nevertheless, it would be good to get an ACK from every contributor in order to have publicly available evidence. - [x] @sipa - [x] @jonasnick - [x] @theStack - [x] @ysangkok I haven't contacted @Sajjon and @satsie, whose contributions constitute of fixing not more than two typos and are thus below the threshold of originalit

2 doc-only fixups.

Adding a few minor changes after having read the specs a couple of times.

Hi! I fixed broken links in `bip-0003.md`. The issue was caused by incorrect letter casing in file references (`BIP-0002.mediawiki` → `bip-0002.mediawiki` and `BIP-0123.mediawiki` → `bip-0123.mediawiki`). The links have been updated to match the correct filenames, ensuring proper navigation.

A couple of tiny changes as i was reading the BIP from top to bottom. See commit messages for details.

I was [finished with my planned work](https://gnusha.org/pi/bitcoindev/25449597-c5ed-42c5-8ac1-054feec8ad88@murch.one/) on 2025-02-03, and after a few more rounds of review, BIP3 got merged on 2025-02-20. I have not received any additional review comments or change suggestions in over three weeks, so it seems to me that this proposal may be complete and ready for adoption, although amendments are of course still possible if anyone has further review, concerns, or suggestions. Please feel free t

Typo fixup in `bip-0069/bip-0069_examples.py`: `disinct` -> `distinct`

The original master file has been changed, and the line numbers referenced by the original URL are no longer accurate. Therefore, a fixed permanent link is used to replace it. The purpose of adopting a permanent link is to prevent the line numbers originally pointed to by the URL from becoming inaccurate again when further changes are made to the master branch.

Replace `SIZE <20> EQUALVERIFY` with `SIZE 32 EQUALVERIFY` for `sha256(h)`, `hash256(h)`, `ripemd160(h)`, and `hash160(h)`. `sha256`/`hash256` produce 32 bytes, not 20, so the original size check is incorrect.

*Replaces https://github.com/bitcoin/bips/pull/727 with with cherry-picked 81644ddfa131bb0e387ead2cc309ca18e57542b1; note that BIP32 has status `Final`. The description below is copied from that PR.* Base58chk-encoded extended keys are always 111 characters long. Amend wording of BIP32 accordingly. **Diff:** -This results in a Base58-encoded string of up to 112 characters. +This results in a Base58-encoded string of exactly 111 characters. **Proof:** Version bytes: `0x0488b21e` (“xpub”), `0x

Fix up error message: - `"Couldn't get block hash"` → `"Couldn't get block data"` for better clarity Also minor grammar edit in code comment: - `"checks for filter size of DefaultP"` → `"checks the filter size of DefaultP"`

According to BIP-0002, any person can request this.

`the the ` - ` the `

In this commit, we restructure the specification section to make the consensus rules clearer and more scannable. The previous section interleaved commentary and historical tidbits with the motivation and new rules, making it difficult to quickly identify the exact rule changes. A high level over view the intended changes is as follows: - Numbers each rule for easier reference - Adds explicit "Rule Specification" sections - Uses structured lists with MUST statements following RFC/IETF convention

Unknown key types are defined as part of the Tapscript opcodes' semantics, in bip-0342. Not bip-0341.

The linter is raising with the following (e.g., in #1780 and #1783) that is resolved by this patch. ```bash ~/bitcoin/bips$ typos error: `TYP` should be `TYPO` --> ./bip-0119.mediawiki:594:73 | 594 | is set to CTVHASH_ALL. Other programs could be added similar to SIGHASH_TYPEs. ```

Addresses https://github.com/bitcoin/bips/pull/1781#discussion_r1985677753 ("Parameters"), writes "Testnet 4" in the same manner as the BIP author, and removes an extra EOL space.

A written specification for Testnet 4 has been requested [in the PR discussion](https://github.com/bitcoin/bitcoin/pull/29775) and a BIP seems to be the right place for this. Given the active discussion in the PR I think it's best if this is kept open until the PR is merged. I will keep it up-to-date and track the current status of the PR.

Include the message in the rand computation to avoid leaking `a` as described [here](https://github.com/bitcoin/bips/pull/1689#discussion_r1939790470).

A few clarifications following a discussion with BIP author Jonas Schnelli yesterday and then thanks to review feedback from both Jonas and Murch. These are compatible with the reference implementation in the BIP and with the current implementation in Bitcoin Core. It is worthwhile to read the discussion in reference implementation https://github.com/bitcoin/bitcoin/pull/10387 (particularly https://github.com/bitcoin/bitcoin/pull/10387#discussion_r156861038).

If the goal is solely to move labels between cooperating wallets, then previously defined values are the absolute minimum needed. However, wallet data exports can serve other purposes and many values associated with addresses, transactions and outputs are already on-hand for the wallet generating the export, and yet would be hard or impossible for importing tools to reconstruct. This PR proposes a bunch of optional fields that could be useful to users of this data. All are optional.

@jonatack Following up on #1750, this PR adds the minor edits you suggested previously which @doc-hex approved, along with another small edit to clarify the address heights specification to align with transaction height.

BIP 94 (Testnet 4) is deployed and used in Bitcoin Core and multiple other projects. The status can be updated to Final.

- Clarifies that a BIP has to be on-topic to be assigned a number - Accept phrasing, and punctuation touch-ups from @jonatack’s last review on #1712

These are required for legal use, and also per BIP-2, and they avoid user confusion as seen in https://github.com/bitcoin/bips/pull/1395#issuecomment-2393915807. Choice of MIT license per BIP author feedback in https://github.com/bitcoin/bips/pull/1395#issuecomment-2393930721. The license omission was likely an oversight. BIP-39 predates BIP-2 by 2-3 years. BIP-1 (in force at the time, since superseded by BIP-2) did require a copyright or public domain section.

Add successful test vectors for: - secp256k1's generator point - optional message

`return` was being used incorrectly to handle an exception. Instead of returning the exception, it should be raised using `raise`.

Summary of changes: * Clarify drng_reader.read is a first-class function (not an evaluation) * Clarify endianness * Clarify possibility for TPRV keys * Add new reference implementation in Python * Clarify that HD-Seed-WIF uses most significant bits * Add language code for Portuguese under BIP-32 application * Correct entropy for BASE64 test vector * Correct byte order and output for XPRV test vector * Add new champion Unit tests for all substantive changes can be found in the reference impleme

Reloading this PR with minimal, backward-compatible changes. * I believe there is consensus on the need to add a new champion [here](https://github.com/bitcoin/bips/pull/1600#issuecomment-2394691135). * The reason for adding a new reference implementation is to support Python 3.x with a thoroughly unit-tested implementation. I was unable to get the original Python 2.x reference implementation to run. * [ ] If desired I can email bitcoin dev for more thoughts on these changes

Moving this BIP to final stage as this is widely deployed

This BIP adds support for sending silent payments using PSBTs. If there are multiple entities handling the PSBT that do not have access to some input private keys, a DLEQ proof by the signer may be added for other entities to verify the corresponding ECDH shares used to derive the output scripts were generated correctly. This is specified in BIP374. For the common case of a single entity that has access to all private keys, the DLEQ proof generation is unnecessary. Spending support is trivial

`OP_SUCCESS188` is `0xbc`, not `0xbb`.

This picks up and supersedes https://github.com/bitcoin/bips/pull/1244/ that - separates concerns into individual commits - corrects fee verification for a proposal having mixed script inputs while ensuring additional fee indeed paid for input I know @kixunil is extremely busy to update these days, so I took the liberty to organize the changes we've discussed according to your wants here. @NicolasDorier I hope these changes satisfy your desire for them to be small and problem-focused while mai

Given that both BIPs are now final, calling them drafts, seem very stale.

According to the psbt Input Finalizer spec "All other data except the UTXO and unknown fields in the input key-value map should be cleared from the PSBT. The UTXO should be kept to allow Transaction Extractors to verify the final network serialized transaction." In Bip78, the receiver clears this data after it finalizes its inputs, even if the utxo belongs to the sender which will need that data. I ran into a problem where LND's FinalizePsbt gRPC fails when this utxo data is missing. I see no g

Following the announcement on the ML (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010348.html). TODO: - [x] BIP number assignment (113) - [ ] Link to discussions between @gmaxwell and @luke-jr where this change was first described

Merges and improves on the editorial spelling/grammar suggestions in https://github.com/bitcoin/bips/pull/1720. Closes https://github.com/bitcoin/bips/pull/1720.

Picks up #1330 that has been awaiting author update since April 2024, and addresses the BIP author suggestion in https://github.com/bitcoin/bips/pull/1330#issuecomment-2080132660.

https://github.com/btcsuite/btcutil/blob/master/gcs leads to a broken link. I'm assuming the correct replacement is at https://github.com/btcsuite/btcd/tree/master/btcutil/gcs since `btcutil` is a sub-package in `btcd`, as stated in https://github.com/btcsuite/btcutil/tree/master?tab=readme-ov-file

by adding to each a python shebang and changing their file permissions from 644 to 755, as mentioned in https://github.com/bitcoin/bips/pull/1734#issuecomment-2564476828. These files don't need to be executable in order to run `gen_test_vectors.py` and `run_test_vectors.py` but it is helpful to allow developers to invoke them directly. Before: ```bash $ ./reference.py zsh: permission denied: ./reference.py ``` After: ```bash $ ./reference.py ```

Even though the test vector generation script is available for BIP-374, I think it's generally a good practice to store the generated test vectors available in the BIP repository as well, so that everyone can verify that it yields deterministic results. In case refactoring / bugfix changes are needed in the test generation script in the future (e.g. https://github.com/bitcoin/bips/pull/1729 for a recent example), one can check that the results are still equal. Can be tested by: ``` $ cd ./bip-0

Both generating and verifying a proof allows for specifying a custom generator point G. But that custom generator point was not passed into the dleq_challenge function, resulting in the default (secp256k1) generator point to be used. This lead to the test vectors being incorrect. Noticed this while re-implementing DLEQ proof generation and verification in Golang.

The `lift_x` function in the BIP and the reference implementation expect an integer to be passed rather than a byte array. Can be tested with: ``` $ python3 test-vectors.py > expected.csv $ diff test-vectors.csv expected.csv ``` On master, the first call fails with ``` Traceback (most recent call last): File "/home/thestack/bips/bip-0340/test-vectors.py", line 267, in <module> vector0(), ^^^^^^^^^ File "/home/thestack/bips/bip-0340/test-vectors.py", line 30, in vector0 pubkey_po

Minor grammar and punctuation errors

Per discussion with @jonatack here: https://github.com/bitcoin/bips/pull/1705#discussion_r1879264639

Corrected terminology: "double vocals" → "double vowels" ### Explanation of Change: 1. The rule being described refers to spelling and letter patterns, specifically when two vowel letters appear together. 2. The term "vowels" is the proper linguistic term for such letters, while "vocals" is incorrect in this context. 3. The example "lineetta" demonstrates a double vowel pattern ('ee').

This BIP is based on the BCH OP_CHECKDATASIG work, as well as postings from the bitcoin dev mailing list in [this thread](https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg10211.html). Some differences appear due to the activation of bips 340, 341, and 342 (taproot) since those were developed. OP_CHECKSIGFROMSTACK is an OP_SUCCESS upgrade available only in BIP342 tapscript.

This pull request addresses several typographical errors found in the BIP documents: - Corrected "shemes" to "schemes" in BIP-0088. - Fixed "publicitly" to "publicly" in BIP-0088. - Replaced "unambigouos" with "unambiguous" in BIP-0088. - Corrected "message paddding" to "message padding" in BIP-0098. - Adjusted "inbetween" to "in between" in BIP-0087. These changes ensure the clarity and accuracy of the documentation.

funcationality - functionality composabe - composable

I found that test vectors in BIP-388 contain errors regarding multipath descriptor derivation. Also, fixed invalid newline in multipath descriptor derivation doc.

Give better clarity for Client Operation

* also widely deployed

Discussing #1692 with @luke-jr, realized that we may not have followed BIP2 process when updating BIP125 from Proposed to Obsolete. Per BIP2: "A Proposed BIP may progress to Final only when specific criteria reflecting real-world adoption has occurred." "When a Final BIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed." BIP125 saw real-world adoption, so it would make