Bitcoin Improvement Proposals

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

Surfaced by 9 reviews.

This is a bip for encrypted backup, an encryption scheme for bitcoin wallet related metadata. Mailing list post: https://groups.google.com/g/bitcoindev/c/5NgJbpVDgEc

Surfaced by 2 reviews.

This BIP proposal follows from the discussion for BIP392 (#2047) in which it emerged that due to the resource-intensive scanning requirements of the protocol some metadata (for example the birthday block height) may be practically required for efficient recovery of wallet funds. However, this metadata is not technically required to determine the output scripts, and therefore deemed unsuitable for direct inclusion in an output descriptor. This may lead to a situation in future where a wallet back

Surfaced by 1 reviews.

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

No reviews yet.

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

No reviews yet.

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.

No reviews yet.

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

No reviews yet.

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

No reviews yet.

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

No reviews yet.

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

No reviews yet.

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

No reviews yet.

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

No reviews yet.

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

No reviews yet.

BIP: 15 Layer: Applications Title: Aliases

No reviews yet.

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

No reviews yet.

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

No reviews yet.

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

No reviews yet.

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

No reviews yet.

This BIP proposes a deterministic scheme for assigning serial numbers to satoshis and tracking their movement across transactions. The goal is to provide a consistent and reproducible method that independent implementations can use to identify and track individual sats. The proposal does not require any changes to Bitcoin consensus rules, transaction formats or network behavior. Implementations of this scheme have been in use on mainnet, signet, and testnet, including wallets with sat-level co

No reviews yet.

**Abstract** This document proposes an additional per input field for BIP 370 PSBTv2 that allows BIP 352 silent payment tweaks to be included in a PSBT of version 2. This field will be relevant to silent payment outputs spending. _Mailing list discussion_: https://groups.google.com/g/bitcoindev/c/Kap7NMwzl2k _Delving bitcoin discussion_: https://delvingbitcoin.org/t/bip352-psbt-support/877/32

No reviews yet.

This is a bip for encrypted backup, an encryption scheme for bitcoin wallet related metadata. Mailing list post: https://groups.google.com/g/bitcoindev/c/ylPeOnEIhO8

No reviews yet.

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.

No reviews yet.

The full revision history is available in a separate branch (https://github.com/rustyrussell/bips/tree/guilt/varops): this is a clean one to submit for merge.

No reviews yet.

# BIP-85: the Nostr path Adds a dedicated BIP-85 application for deriving Nostr private keys a.k.a. `nsec`, with a structured `/{identity}'/{account}'` path supporting multiple unlinkable identities. ## Motivation Today there is no standardized BIP-85 path for Nostr key derivation: | Method | Path | Problem | |--------|------|---------| | BIP-85 HEX | `m/83696968'/128169'/32'/index'` | Not Nostr-specific, no identity structure | | BIP-85 mnemonic + NIP-06 | BIP-85 → 12 words → `m/44'/1237'/0

No reviews yet.

A BIP 174 PSBT may contain an extended key for deriving input and output addresses. This document proposes an additional field for PSBTs to represent arbitrary BIP 380 output script descriptors. To support transfer of output descriptors outside signing flows, the proposal makes the unsigned transaction optional.

No reviews yet.

Mnemonic *sentences* instead of words proposed as forwards- and backwards-compatible expansion to BIP39, itself as Bitcoin Improvement Proposal.

No reviews yet.

This PR provides `bip-0375/bip375_test_vectors.json` and a reference `bip-0375/validator/validate_psbt.py` for validating Sending Silent Payments with PSBTs. PSBTs are validated against v2 requirements with BIP-375 rules (building on BIP-352 silent payment derivation and BIP-374 DLEQ proofs). Changes since last force-push: - Add vendored dependencies in `bip-0375/deps`: - `secp256k1lab` (ECC operations) - `bitcoin_test` (PSBT parsing adapted from Bitcoin Core test framework) - Implement 4-st

No reviews yet.

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

No reviews yet.

Opening this PR for feedback & discussion on the specification for OP_TWEAKADD. Mailing list post: https://groups.google.com/g/bitcoindev/c/-_geIB25zrg

No reviews yet.

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

No reviews yet.

This addresses the feedback received on the test vectors following the merge of #2015, the review of the Bitcoin Inquisition implementation (https://github.com/bitcoin-inquisition/bitcoin/pull/99), and Chris Stewart's implementation for Bitcoin-s (https://github.com/bitcoin-s/bitcoin-s/pull/6170). There are 4 categories of changes here: - Rewording and clarifications in the BIP text. - Some typo fixes and field reordering in the test vectors. - A change in the structure of the timestamps test v

No reviews yet.

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

No reviews yet.

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

No reviews yet.

## Summary ## Problem In a tree structured as [leaf0, [leaf1, leaf2]], the control block for spending a leaf must contain the sibling hashes along the Merkle path, not the leaf's own hash. The current test vectors have the control blocks for leaf1 and leaf2 swapped, causing them to include the spending leaf's own hash as the first path element instead of its sibling's hash. ### Example:es 1 and 2 in the three-lea Intermediate leaf hashes (correct in the test vector): ``` leafHash[0] = 2645

No reviews yet.

## Summary Fix the first byte of `scriptPathControlBlocks[1]` in the `p2mr_different_version_leaves` test vector. The control block incorrectly uses `0xC1` (leafVersion 192) instead of `0xFB` (leafVersion 250) for a leaf explicitly declared with `"leafVersion": 250`. ## Problem The P2MR control block's first byte encodes both the leaf version and parity bit: ``` controlBlock[0] = (leafVersion & 0xfe) | parityBit ``` For P2MR, the parity bit is always 1. So: - leafVersion 192 (0xC0) → `0xC1`

No reviews yet.

The checksum calculation should be consistent in all implementations.

No reviews yet.

This PR adds a missing `Requires` header to BIP-0086: - `Requires: 32, 341` Rationale: - BIP-0086 explicitly defines derivation from a BIP-32 master private key. - BIP-0086 also defines Taproot single-key output derivation and references BIP-341 semantics for output/script behavior. Scope: - Metadata-only change (no spec semantics changed).

No reviews yet.

https://github.com/bitcoin/bitcoin/pull/34826

No reviews yet.

codex32 string length limited to always cover HRP characters, master seed bit lengths limited to multiples of 32-bits, updated master seed encoding/decoding processes. PR helper for #2040: prepares text for general HRP lengths by defining limits based on string length not data part length and deprecating master seed lengths that violate a general codex32 string length > checksum type rule. **Why** Restricting seeds to 32-bit multiples makes valid secret seed **lengths** differ by at least 6-7

No reviews yet.

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.

No reviews yet.

**Description** While reviewing test vectors for BIP 375, and by looking closer at the spec, I noticed the following: - The updater role mentions the addition of PSBT_IN_BIP32_DERIVATION data for p2wpkh, p2sh-p2wpkh and p2pkh, all members of the [Inputs for Shared Secret Derivation from BIP 352](https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#user-content-Inputs_For_Shared_Secret_Derivation), but doesn't mention the addition of PSBT_IN_TAP_BIP32_DERIVATION data for p2tr inputs w

No reviews yet.

## Summary In the `execute_bip_119` pseudocode, the hash comparison references `stack[-1]` instead of `self.stack[-1]`, inconsistent with all other stack references in the function: ```python # Correct: if len(self.stack) < 1: if len(self.stack[-1]) == 32: # Incorrect — missing self.: if stack[-1] != self.context.tx.get_default_check_template_hash(...) ``` In Python, `stack[-1]` would reference an undefined local variable, while `self.stack[-1]` correctly accesses the interpreter's stack. Th

No reviews yet.