BIPs — Open

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

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

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

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

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.

# 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

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.

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

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

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

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

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

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

## 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`

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

The BIP is quite difficult to parse in terms of understanding the functionality and safety of tweaking keys. In particular, while it is a terrible idea for more than one reason, constructing a MuSig2 aggregated key using related (bip32 unhardened) individual keys in the list is very specifically insecure, but that is not noted. It's admittedly debatable whether you ever have to specify that a certain kind of stupid behaviour is to be warned against, but my justification is: 1. The BIP is very

So I'm doing some work on extending BIP85 functionality on SeedSigner to include GPG key generation, file verification, encrypted messaging, etc, but the resource limitation on low power devices like the Raspberry Pi really makes RSA keys quite painful to use at any useful bit length. (RSA3072 takes 15-20 minutes for a primary key + 3 subs) Basically I'm suggesting an expansion of the current functionality to add support for some common ECC curves and provide a bit of a process for future curve

Initial draft of a proposal for how to incentivize migration to post quantum cryptography and safeguard the ecosystem from unnecessary inflation of the circulating supply and the economic turmoil likely to accompany such an event.

**Summary of Changes:** Describe codex32 format for arbitrary human-readable parts not just "ms", specify master seed encoding standard, add new test vectors and enhance readability. This makes the document more like BIP-0173: proposing an encoding "codex32", then defining a standard for something using it. See discussion on https://github.com/bitcoin/bips/pull/2023#issuecomment-3538570493. **Spec:** - fixed the threshold mistake in the abstract - replaced "master seed" with "secret", prior to

As per https://github.com/bitcoin/bips/pull/2111#issuecomment-3993872947: > The requirement was already stated by the "Versions Requiring Exclusion" and "Versions Requiring Inclusion" columns.

[BIP54](https://github.com/bitcoin/bips/blob/master/bip-0054.md) proposes constraining the coinbase transaction `nLockTime` and `nSequence` fields. Bitcoin Core's internal mining code has been doing this since v30.0 (see https://github.com/bitcoin/bitcoin/pull/32155), but currently the fields are only communicated to IPC clients (i.e. Stratum v2, see e.g. https://github.com/bitcoin/bitcoin/pull/33819). This PR extends BIP54 with the following BIP22 fields (`getblocktemplate` RPC): - `lock_tim

This PR adds a BIP for the FROST (Flexible Round-Optimized Schnorr Threshold) signing protocol. The development repository is at https://github.com/siv2r/bip-frost-signing. There already exists [RFC 9591](https://www.rfc-editor.org/rfc/rfc9591.html), which standardizes the two-round FROST signing protocol, but it is incompatible with Bitcoin's BIP340 X-only public keys. This BIP bridges that gap by providing a BIP340-compatible variant of FROST. This BIP standardizes the FROST3 variant (Sectio

This allows wallets to derive codex32 secrets and codex32 shares from BIP-0032 master keys. **Summary of changes** - Add codex32 application - Add [BIP-0093](https://github.com/bitcoin/bips/blob/master/bip-0093.mediawiki) to references - Bump version number to 1.4.0 - Add 1.4.0 [reference implementation](https://github.com/benwestgate/bip85) **Rationale** - Mirrors the existing BIP-85 application for BIP-39. - Codex32 offers error correction, hand verification, identifiers, and secret sharing

This pull request proposes a new BIP for a standard, interoperable format for encrypted wallet backups and transfers. The core design choice is the separation of the data `payload` from the cryptographic `container`. This BIP specifies the `payload` format, while mandating that it must be encrypted by a container defined in companion proposals. Key features include: * **CBOR Serialisation:** Uses CBOR for a compact, efficient, and extensible binary format suitable for resource-constrained devi

This commit updates the ProofOfReserves message in the Protocol Buffers specification to use BIP44 coin type IDs from SLIP-0044 instead of network magic values. The changes include: - Renaming the field from 'network_magic' to 'coin_type' - Updating the comments to reference the SLIP-0044 registry - Adding examples for Bitcoin mainnet (0x80000000) and Testnet (0x80000001)

These are the 3 BIPs that describe Utreexo, a consensus-compatible (non-soft fork) way to send and verify transactions without storing the full UTXO set. The 3 BIPs are for: 1. The specification of the Utreexo accumulator. 2. The specification of Bitcoin block and tx validation using the Utreexo accumulator. 3. The peer to peer networking changes required to enable Utreexo nodes. Mailing list post: https://groups.google.com/g/bitcoindev/c/W1lxBraKG_E

Adds a BIP for SENDTEMPLATE, GETTEMPLATE, TEMPLATE p2p messages. Discussion links: https://delvingbitcoin.org/t/sharing-block-templates/1906 https://gnusha.org/pi/bitcoindev/aJvZwR_bPeT4LaH6@erisian.com.au/T/#u

In this PR, we add a new draft BIP proposing the addition of fundamental Elliptic Curve op codes. Amongst other things, this series of op codes permits the computation of the top level Taproot output public key in Bitcoin Script. This enables a new flavor of on-chain state machines, in addition to many other use cases.

Update bip-0158/gentestvectors.go to use os.ReadFile instead of the deprecated io/ioutil package. The ioutil package has been deprecated since Go 1.16, with its functionality moved to the io and os packages.

Update the recipients parameter in create_outputs from List[str] to List[Dict[str, str]]. This aligns the type annotation with actual usage in the code (recipient["address"], recipient["scan_pub_key"], recipient["spend_pub_key"]) and matches the structure provided by the test vectors. The previous annotation was misleading and could cause static type checkers and IDEs to surface incorrect diagnostics.

<img width="1020" height="665" alt="emojiseed" src="https://github.com/user-attachments/assets/13c39c50-6a2a-4762-b450-a157db784f6f" /> ## Emoji Seed Word List Pull Request ## **Purpose** The purpose of this PR is to define and discuss the proper standardized definitions an official emoji seedlist. **Research** All research and discussions on the finalized standard are included in the **README** on **https://emojiseed.com**. **Community** The EmojiSeed community is just starting if you

Based on a discussion I started on [Delving Bitcoin](https://delvingbitcoin.org/t/bip352-private-key-formats/2080) Also related: [BTC Transcripts](https://btctranscripts.com/bitcoin-core-dev-tech/2024-04/silent-payment-descriptors) BIP authors: @josibake @RubenSomsen --- These two new encodings are a way for Silent Payment users to: 1. Delegate scanning and wallet UTXO management to self hosted services like BTCPayServer 2. Encode secret information including birthday and labels used, so t

The comment for ORDER_HALF incorrectly stated it represents "Number of valid distinct x coordinates on the curve". This is wrong - ORDER_HALF is simply half the group order, commonly used for ECDSA low-S signature normalization. The number of valid x coordinates on secp256k1 is approximately (p-1)/2 where p is the field size, which is a completely different value. Also clarified the ORDER comment from "plus 1 for infinity" to "including infinity" for better accuracy.

This BIP describes a new tapscript opcode (`OP_AMOUNT`) which pushes the amount of the selected input or output to the stack.

The BIP asserts that `fA(fB(psbt)) == fB(fA(psbt))`, however the explanatory text before this doesn't actually say this and even hints that the ordering does matter: "processing [..] A and then B *in a sequence*". It seems that the BIP text only supports the `Combine(fA(psbt), fB(psbt)) == fB(fA(psbt))` part, and that `fA(fB(psbt))` slipped in by accident? In practice, Bitcoin Core's `combinepsbt` isn't commutative and gives precedence to latter PSBTs in the array. Here's a quick example demons

At some point[ github changed how anchor links](https://github.com/gjtorikian/commonmarker/issues/229#issuecomment-1418272363) work. Currently anchor links using the double square bracket format require that the anchor be prepended with `user-content-`. This means that the following link used to work, but doesn't today ``` [[bip-0341.mediawiki#design|BIP341]] ``` The link that works today would be ``` [[bip-0341.mediawiki#user-content-design|BIP341]] ``` The link still resolves to the pa

## Overview These BIPs describe the Taproot Asset Protocol, a Taproot-native asset overlay built on top of the base Bitcoin blockchain. Taproot Assets enable the representation of arbitrary (normal and collectibles) assets on top of Bitcoin without bloating the base chain. The protocol is designed such that transactions interacting with Taproot Assets are indistinguishable from regular transactions from the PoV of the Bitcoin blockchain. Taproot Assets extend the base Taproot script tree with a

The Stratum wire protocol has a long history since @slush0 introduced it. However, the protocol never got standardized in a formal way, so many implementations have been based on incomplete documents or on other implementations. With this document I finally want to give Stratum its place between the other BIPs, so that developers can just read this document and don't have to search through years of code or dead pages that need to be revived with Wayback Machine.

BIP 18: remove the outdated reference link to Gavin Andresen's pay_to_script_hash branch in the Bitcoin repository https://github.com/gavinandresen/bitcoin-git/tree/pay_to_script_hash BIP 52: remove https://www.powx.org/opow - no alternative link found in google

Implements wallet behaviour for the Guardian Address proposal. The source code for the wallet implementation is available at https://github.com/bitcoinguardian/electrum. This serves as a model for self-custodial wallets, while custodial services may adapt the protocol to their infrastructure. Guardian Signal tooling is available at https://github.com/bitcoinguardian/GASPv1-draft A demo with testnet transactions and Guardian integration is available at https://github.com/bitcoinguardian/electr

Implements the protocol for the Guardian Address proposal. The source code for the wallet implementation is available at https://github.com/bitcoinguardian/electrum. This serves as a model for self-custodial wallets, while custodial services may adapt the protocol to their infrastructure. Guardian Signal tooling is available at https://github.com/bitcoinguardian/GASPv1-draft A demo with testnet transactions and Guardian integration is available at https://github.com/bitcoinguardian/electrum/t

Complete the unfinished sentence about libbitcoinconsensus separation.

The pseudocode in bip-0119 used stack[-1] while the rest of execute_bip_119 consistently accessed the interpreter stack via self.stack.

Previously `parse_inout_selection` only rejected indices strictly greater than `nb_items`, allowing `idx == nb_items` to pass through and later cause a panic when indexing transaction inputs/outputs. Tightened the bounds check in `parse_inout_selection` to treat `idx >= nb_items` as out of bounds, enforcing the intended `0..nb_items-1` index range for `TxFieldSelector` individual mode.