BIP 3: <BIP title (≤ 50 characters)>

  BIP: 3
  Title: Updated BIP Process
  Authors: Murch <murch@murch.one>
  Status: Deployed
  Type: Process
  Assigned: 2025-01-09
  License: BSD-2-Clause
  Discussion: https://github.com/murchandamus/bips/pull/2
              https://gnusha.org/pi/bitcoindev/59fa94cea6f70e02b1ce0da07ae230670730171c.camel@timruffing.de/#t
  Version: 1.4.0
  Requires: 123
  Replaces: 2

Abstract

This Bitcoin Improvement Proposal (BIP) provides information about the preparation of BIPs and policies relating to the publication of BIPs. It replaces BIP 2 with a streamlined process, and may be amended to address the evolving needs of the BIP process.

Motivation

BIP 2 was written in 2016. This BIP revisits aspects of the BIP 2 process that did not achieve broad adoption, reduces the judgment calls assigned to the BIP Editor role, delineates the BIP types more clearly, and generalizes the BIP process to fit the community’s use of the repository.

Fundamentals

What is a BIP?

BIPs are improvement proposals for Bitcoin. The main topic is information and technologies that support and expand the utility of the Bitcoin currency. Most BIPs provide a concise, self-contained, technical description of one new concept, feature, or standard. Some BIPs describe processes, implementation guidelines, best practices, incident reports (e.g., BIP 50), or other information relevant to the Bitcoin community. However, any topics related to the Bitcoin protocol, peer-to-peer network, and client software may be acceptable.

BIPs are intended to be a means for proposing new protocol features, coordinating client standards, and documenting design decisions that have gone into implementations. BIPs may be submitted by anyone, provided the content is of high quality, e.g., does not waste the community’s time.

The scope of the BIPs repository is limited to BIPs that do not oppose the fundamental principle that Bitcoin constitutes a peer-to-peer electronic cash system for the Bitcoin currency.

BIP Ownership

Each BIP is primarily owned by its authors and represents the authors’ opinion or recommendation. The authors are expected to foster discussion, address feedback and dissenting opinions, and, if applicable, advance the adoption of their proposal within the Bitcoin community. As a BIP progresses through the workflow, it becomes increasingly co-owned by the Bitcoin community.

Authors and Deputies

Authors may want additional help with the BIP process after writing an initial draft. In that case, they may assign one or more Deputies to their BIP. Deputies are stand-in owners of a BIP who were not involved in writing the document. They support the authors in advancing the proposal, or act as a point of contact for the BIP in the absence of the authors. Deputies may perform the role of Authors for any aspect of the BIP process unless overruled by an Author. Deputies share ownership of the BIP at the discretion of the Authors.

What is the Significance of BIPs?

BIPs do not define what Bitcoin is: individual BIPs do not represent Bitcoin community consensus or a general recommendation for implementation. A BIP represents a personal recommendation by the BIP authors to the Bitcoin community. Some BIPs may never be adopted. Some BIPs may be adopted by one or more Bitcoin clients or other related software. Some may even end up changing the consensus rules that the Bitcoin ecosystem jointly enforces.

What is the Purpose of the BIPs Repository?

The BIPs repository serves as a publication medium and archive for mature proposals. Through its high visibility, it facilitates the community-wide consideration of BIPs and provides a well-established source to retrieve the latest version of any BIP. The repository transparently records all changes to each BIP and allows any community member to retain a complete copy of the archive easily.

The BIPs repository neither tracks community sentiment[^acceptance] nor ecosystem adoption[^adoption] of BIPs beyond the brief overview provided via the BIP status (see Workflow below). Proposals are published in this repository if they are on-topic and fulfill the editorial criteria. No formal or informal decision body governs Bitcoin development or decides adoption of BIPs.

BIP Format and Structure

Specification

Authors may choose to submit BIPs in MediaWiki or Markdown[^markdown] format.

Each BIP must have a Preamble, an Abstract, a Copyright, and a Motivation section. Authors should consider all issues in the following list and address each as appropriate.

• Preamble — Headers containing metadata about the BIP (see the section BIP Header Preamble below).
• Abstract — A short description of the issue being addressed.
• Motivation — Why is this BIP being written? Clearly explain how the existing situation presents a problem and why the proposed idea resolves the issue or improves upon the current situation.
• Specification — The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to enable any Bitcoin project to create an interoperable implementation.
• Rationale — The rationale fleshes out the specification by describing what inspired the design and why particular design decisions were made. It should describe related work and alternate designs that were considered. The rationale should record relevant objections or important concerns that were raised and addressed as this proposal was developed.
• Backward Compatibility — Any BIP that introduces incompatibilities must include a section describing these incompatibilities and their severity as well as provide instructions on how implementers and users should deal with these incompatibilities.
• Reference Implementation — Where applicable, a reference implementation, test vectors, and documentation must be finished before the BIP can be given the status "Complete". Test vectors must be provided in the BIP or as auxiliary files (see Auxiliary Files) under an acceptable license. The reference implementation can be provided in the BIP, as an auxiliary file, or per linking another code reference that is expected to remain available permanently such as a pull request, a dedicated branch, a new repository, or similar.
• Changelog — A section to track modifications to a BIP after reaching Complete status.
• Copyright — The BIP must be placed under an acceptable license (see BIP Licensing below).

BIP Header Preamble

Each BIP must begin with an RFC 822-style header preamble. The headers must appear in the following order. Headers marked with "*" are optional. All other headers are required.

Overview

  BIP: <BIP number, or "?" before assignment>
* Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications>
  Title: <BIP title (≤ 50 characters)>
  Authors: <Authors’ names and email addresses>
* Deputies: <Deputies’ names and email addresses>
  Status: <Draft | Complete | Deployed | Closed>
  Type: <Specification | Informational | Process>
  Assigned: <Date of number assignment (yyyy-mm-dd), or "?" before assignment>
  License: <SPDX License Expression>
* Discussion: <Noteworthy discussion threads in "yyyy-mm-dd: URL" format>
* Version: <MAJOR.MINOR.PATCH>
* Requires: <BIP number(s)>
* Replaces: <BIP number(s)>
* Proposed-Replacement: <BIP number(s)>

Header Descriptions

• BIP — The assigned number of the BIP (without leading zeros). Please use "?" before a number has been assigned by the BIP Editors.

• Layer — The layer of Bitcoin the BIP applies to using the BIP classification defined in BIP 123.

• Authors — The names (or pseudonyms) and email addresses of all authors of the BIP. The format of each authors header value must be

  Random J. User <address@dom.ain>
  

  Multiple authors are recorded on separate lines:

  Authors: Random J. User <address@dom.ain>
           Anata Sample <anata@domain.example>
  

• Deputies — Additional owners of the BIP that are not authors. The Deputies header uses the same format as the Authors header. See the BIP Ownership section above.

• Status — The stage of the workflow of the proposal. See the Workflow section below.

• Type — See the BIP Types section below for a description of the three BIP types.

• Assigned – The date a BIP was assigned its number. Please use "?" before a number has been assigned by the BIP Editors.

• License — The License header specifies SPDX License Expressions describing the terms under which the BIP and its auxiliary files are available. See the BIP Licensing section below.

• Discussion — The Discussion header points the audience to relevant discussions of the BIP, e.g., the mailing list thread in which the idea for the BIP was discussed, a thread where a new version of the BIP was presented, or relevant discussion threads on other platforms. Entries take the format "yyyy-mm-dd: URL", e.g., 2009-01-09: https://www.mail-archive.com/cryptography@metzdowd.com/msg10142.html, using the date and URL of the start of the conversation. Multiple discussions should be listed on separate lines.

• Version — The current version number of this BIP. See the Changelog section below.

• Requires — A list of existing BIPs the new proposal depends on. If multiple BIPs are required, they should be listed in one line separated by a comma and space (e.g., "1, 2").

• Replaces[^proposes-to-replace] — BIP authors may put the numbers of one or more prior BIPs in the Replaces header to recommend that their BIP succeeds, supersedes, or renders obsolete those prior BIPs.

• Proposed-Replacement[^superseded-by-proposed-replacement] — When a later BIP indicates that it intends to supersede an existing BIP, the later BIP’s number is added to the Proposed-Replacement header of the existing BIP to indicate the potential successor BIP.

Auxiliary Files

BIPs may include auxiliary files such as diagrams and source code. Auxiliary files must be included in a subdirectory for that BIP named bip-XXXX, where "XXXX" is the BIP number zero-padded to four digits. File names in the subdirectory do not need to adhere to a specific convention.

BIP Types

• A Specification BIP defines a set of technical rules describing a new feature or affecting the interoperability of implementations. The distinguishing characteristic of a Specification BIP is that it can be implemented, and implementations can be compliant with it. Specification BIPs must have a Specification section, must have a Backward Compatibility section (if incompatibilities are introduced), and can only be advanced to Complete after they contain or refer to a reference implementation and test vectors.
• An Informational BIP describes a Bitcoin design issue, or provides general guidelines or other information to the Bitcoin community.
• A Process BIP describes a process surrounding Bitcoin, or proposes a change to (or an event in) a process. Process BIPs are like Specification BIPs, but apply to topics other than the Bitcoin protocol and Bitcoin implementations. They often require community consensus and are typically binding for the corresponding process. Examples include procedures, guidelines, and changes to decision-making processes such as the BIP process.

Workflow

The BIP process starts with a new idea for Bitcoin. Each potential BIP must have authors—people who write the BIP, gather feedback, shepherd the discussion in the appropriate forums, and finally recommend a mature proposal to the community.

Ideation

After having an idea, the authors should evaluate whether it meets the criteria to become a BIP, as described in this BIP. The idea must be of interest to the broader community or relevant to multiple software projects. Minor improvements and matters concerning only a single project usually do not require standardization and should instead be brought up directly to the relevant project.

The authors should first research whether their idea has been considered before. Ideas in Bitcoin are often rediscovered, and prior related discussions may inform the authors of the issues that may arise in its progression. After some investigation, the novelty and viability of the idea should be tested by posting a new, dedicated thread about the idea to the Bitcoin Development Mailing List. Prior correspondence can be found in the mailing list archive.

It is recommended that authors establish before or at the start of working on a draft whether their idea may be of interest to the Bitcoin community. Authors should avoid opening a pull request with a BIP draft out of the blue. Vetting an idea publicly before investing time and effort to formally describe the idea is meant to save time for both the authors and the community. Not only may someone point out relevant discussion topics that were missed in the authors’ research, or that an idea is guaranteed to be rejected based on prior discussions, but describing an idea publicly also tests whether it is of interest to more people beside the authors.

As a first sketch of the proposal is taking shape, the authors should present it to the Bitcoin Development Mailing List. This gives the authors a chance to collect initial feedback and address fundamental concerns. If the authors wish to work in public on the proposal at this stage, it is recommended that they open a pull request against one of their forks of the BIPs repository instead of the main BIPs repository.

It is recommended that complicated proposals be split into separate BIPs that each focus on a specific component of the overall proposal.

Progression through BIP Statuses

The following sections refer to BIP Status field values. The BIP Status field is defined in the Header Preamble specification above.

Draft

After fleshing out the proposal further and ensuring that it is of high quality and properly formatted, the authors should open a pull request to the BIPs repository. The document must adhere to the formatting requirements specified above and should be provided as a file named with a working title of the form "bip-title.[md|mediawiki]". Only BIP Editors may assign BIP numbers. Until one has done so, authors should refer to their BIP by name only.

BIPs that (1) adhere to the formatting requirements, (2) are on-topic, and (3) have materially progressed

[Content truncated — view full spec at source]