DOCSEARCHbyAlgolia
Submit Docs

Bitcoin Improvement Proposals (BIPs)

repository·master·Indexed 27 days ago

https://github.com/bitcoin/bips

The official repository for Bitcoin Improvement Proposals, containing the BIP process and formatting standards (BIP 0003), as well as reference implementations and test vectors for various proposals. This includes validation suites for BIP-375, test vectors for BIP-54 (difficulty adjustment, transaction size, and coinbase restrictions), and OP_TEMPLATEHASH sanity checks for BIP-0446. It also contains secp256k1lab, an insecure Python implementation of the secp256k1 elliptic curve intended for prototyping and education.

Tokens
28.4K
Snippets
20
Records
149
Agent score
95%

What's inside bitcoin-bips

  1. Overview of secp256k1lab

    master

    secp256k1lab is a Python implementation of the secp256k1 elliptic curve and related cryptographic schemes. It is designed specifically for prototyping, experimentation, and education.

    Key Features:

    • Low-level secp256k1 field and group arithmetic.
    • Schnorr signing/verification and key generation following the BIP-340 standard.
    • ECDH (Elliptic Curve Diffie-Hellman) key exchange.

    ⚠️ CRITICAL SECURITY WARNING: This library is INSECURE. It is slow and trivially vulnerable to side-channel attacks. Do NOT use this implementation for production cryptographic operations or any real-world security applications.

  2. Overview of Miniscript

    master

    Miniscript is a structured language for writing a subset of Bitcoin Scripts. It is designed to enable advanced operations that are difficult with standard Bitcoin Script, such as:

    • Analysis: Statically analyzing scripts for spending conditions, correctness, security properties, and malleability.
    • Composition: Constructing new scripts by combining existing ones (e.g., nesting multisig conditions).
    • Generic Signing: Constructing satisfying witnesses for a script given a sufficient set of private keys.
    • Cost Prediction: Predicting the transaction cost and resource usage (like OP_MAX_OP_CODES) required to spend an output.
    • Compiler Targeting: Serving as a target for spending policy compilers.
    • Conversion: Converting compatible Bitcoin Scripts into Miniscript form to support signing devices without requiring external metadata.

  3. Overview of Taproot-native (Re)bindable Transactions (BIP 448)

    master
    BIP 448 proposes three new Tapscript operations designed to enable rebindable transaction signatures. This capability supports advanced second-layer protocols like LN-Symmetry ("Eltoo"), simplifies 2-party channels (e.g., Daric), and improves statechains and Point Time Locked Contracts (PTLCs). The proposal focuses on modularity and minimal implementation complexity by extending existing Tapscript operations.

  4. Overview of Async Payjoin (BIP 77)

    master

    Async Payjoin (BIP 77) is an asynchronous, backwards-compatible version of the Payjoin protocol (Version 2). It allows Bitcoin senders and receivers to coordinate batched transactions using an untrusted third-party "directory server" instead of requiring the receiver to host a secure public endpoint.

    Key features include:

    • Asynchronous Communication: Uses a store-and-forward directory server, allowing parties to be offline and resume via polling.
    • Privacy: Uses Oblivious HTTP (OHTTP) to prevent the directory server and other clients from linking requests to client IP addresses.
    • Security: Employs end-to-end encrypted payloads using cryptographic primitives available in Bitcoin Core.
    • Compatibility: Preserves all Version 1 (BIP 78) functionality, including payment output substitution.

  5. BIP-375 Validation Reference Core Components

    master

    The reference implementation consists of the following core files:

    • validator/bip352_crypto.py: Handles silent payment output script derivation.
    • validator/inputs.py: Contains PSBT input utility functions.
    • validator/psbt_bip375.py: Implements BIP-375 specific PSBT/PSBTMap extensions.
    • validator/validate_psbt.py: Contains the main BIP-375 validation functions.
    • test_runner.py: The executable test infrastructure.

  6. Understand BIP Statuses and Transitions

    master

    BIPs progress through several defined statuses:

    • Draft: The initial phase where the proposal is being fleshed out and formatted.
    • Complete: The authors recommend the BIP for adoption. Specification BIPs must include a working reference implementation and comprehensive test vectors to reach this status.
    • Deployed: The BIP is in active use (e.g., implemented in mainnet software). For Process BIPs, this requires 'rough consensus' on the Bitcoin Development Mailing List (open discussion for at least one month with no unaddressed substantiated objections).
    • Closed: The BIP is of historical interest only and is no longer being actively worked on or used.

    Key Transitions:

    • Draft $\mapsto$ Closed: Authors decide to stop, or a stalled BIP is closed after a year of no progress.
    • Complete $\mapsto$ Closed: Authors announce it is no longer being promoted, unless someone volunteers to adopt it.
    • Deployed $\mapsto$ Closed: Announced via the mailing list; moves to Closed if no objections are raised for four weeks.
    • Closed $\mapsto$ Draft: If authors attempt to revive a closed idea, they may return it to Draft status (though a new number is usually assigned).

  7. Implement the Dust UTXO Disposal Protocol (BIP 451)

    master
    BIP 451 defines a standardized protocol for disposing of dust UTXOs by spending them to a single OP_RETURN output where the entire input value is consumed as transaction fees. This prevents dust attacks from linking addresses via the common-input-ownership heuristic and avoids UTXO set bloat.

  8. Consensus rules and BIP 54 activation on Testnet 5

    master

    Testnet 5 enforces the following consensus rules from block 1:

    1. BIP 54 (Consensus Cleanup): All rules specified in BIP 54 (version 1.0.0) are active. This includes mitigations for timewarp attacks, block validation time reduction, and Merkle tree weakness mitigations.
    2. Mainnet Rules: All consensus rules active on Bitcoin mainnet as of May 2026 (including the Taproot softfork) are enforced.
    3. No Difficulty Exception: Unlike Testnet 3 and 4, Testnet 5 does not permit mining at minimum difficulty if more than 20 minutes have passed since the previous block. All blocks must meet the proof-of-work limit.

  9. Understand BIP Statuses and Lifecycle

    master

    Bitcoin Improvement Proposals (BIPs) move through various statuses. Understanding these helps you evaluate the maturity and impact of a proposal:

    • Draft: An initial proposal undergoing development.
    • Complete: The authors have finished planned work and are ready to recommend the BIP for adoption.
    • Deployed: Evidence exists that one or more implementations have deployed the BIP. Changes to a Deployed BIP can negatively impact existing users.
    • Closed: Indicates the BIP is of historical significance. This status replaces older categories like Deferred, Obsolete, Rejected, Replaced, or Withdrawn.

    Note: There is no formal 'acceptance' body; acceptance is an emergent property of community interest and stakeholder participation.

  10. Propose a new BIP via the Ideation and Draft process

    master

    To propose a new Bitcoin Improvement Proposal (BIP), follow these steps:

    1. Ideation: Research if the idea has been considered before. Test the novelty and viability by posting a dedicated thread to the Bitcoin Development Mailing List.
    2. Drafting: Once initial feedback is collected, prepare a high-quality, properly formatted document.
    3. Submission: Open a pull request against the BIPs repository.
      • Use a filename with a working title: bip-title.[md|mediawiki].
      • Do not use a BIP number yet; only BIP Editors can assign numbers.
    4. Number Assignment: A BIP Editor will assign a number once the proposal is on-topic, adheres to formatting, and has generated substantial public discussion.

    Note: It is recommended to work on a fork of the BIPs repository for public drafting rather than opening a pull request to the main repository immediately.

  11. Implement BIP 434 Peer Feature Negotiation

    master

    BIP 434 defines a P2P message for advertising and negotiating new features between Bitcoin nodes. This allows features to be negotiated after the version message but before the verack message, avoiding the need to bump the protocol version for every new feature.

    Implementation Requirements

    • Protocol Version: Implementing nodes MUST advertise a protocol version >= 70017.
    • Message Timing:
      • MUST accept feature messages received after version and before verack.
      • MUST NOT send feature messages to peers with protocol version < 70017.
      • MUST NOT send feature messages after sending the verack message.
    • Compatibility:
      • Nodes SHOULD ignore unknown messages received between version and verack.
      • Nodes MAY ignore or disconnect peers that send feature messages after verack.
    • Feature Constraints: Any feature introduced by a new BIP MUST NOT send its specific messages to a peer until that peer has indicated support via a feature message.

  12. Implement Japanese BIP-0039 phrase generation and verification

    master

    When implementing BIP-0039 phrase generation or checksum verification for Japanese, you must handle ideographic spaces (full-width spaces) as word separators.

    Technical Specifications:

    • UTF-8 bytes: 0xE38080
    • C/C++/Java: "\u3000"
    • Python: u"\u3000"

    Implementation Notes:

    • Normalization: The BIP-0039 specification requires normalization, which automatically converts ideographic spaces into standard ASCII spaces (0x20).
    • Input Handling: If your application only accepts phrases but does not generate or verify them, standard ASCII space handling is sufficient. However, if you generate or verify, you must accommodate ideographic spaces in user input.
    • UI/UX: Word-wrapping should ideally only occur at ideographic spaces to prevent long words from being split, which could lead to user error.