![\"Status](\"https://raw.githubusercontent.com/bitcoin/bips/master/bip-0003/status-diagram.png\" "\\"Status")
This Bitcoin Improvement Proposal (BIP) provides information about the preparation of BIPs and policies relating to\nthe publication of BIPs. It replaces BIP 2 with a streamlined process, and may be amended to\naddress the evolving needs of the BIP process.
\nBIP 2 was written in 2016.\nThis BIP revisits aspects of the BIP 2 process\nthat did not achieve broad adoption, reduces the judgment calls assigned to the BIP Editor role, delineates the\nBIP types more clearly, and generalizes the BIP process to fit the community’s use of the repository.
\nBIPs are improvement proposals for Bitcoin. The main topic is information and technologies that support and expand the utility of the Bitcoin\ncurrency. Most BIPs provide a concise, self-contained, technical description of one new concept, feature, or standard.\nSome BIPs describe processes, implementation guidelines, best practices, incident reports (e.g.,\nBIP 50), or other information relevant to the Bitcoin community. However, any topics related to\nthe Bitcoin protocol, peer-to-peer network, and client software may be acceptable.
\nBIPs are intended to be a means for proposing new protocol features, coordinating client standards, and\ndocumenting design decisions that have gone into implementations. BIPs may be submitted by anyone, provided the\ncontent is of high quality, e.g., does not waste the community’s time.
\nThe scope of the BIPs\nrepository is limited to BIPs that do not oppose the fundamental principle that Bitcoin constitutes a peer-to-peer\nelectronic cash system for the Bitcoin currency.
\nEach BIP is primarily owned by its authors and represents the authors’ opinion or recommendation. The authors are\nexpected to foster discussion, address feedback and dissenting opinions, and, if applicable, advance the adoption of\ntheir proposal within the Bitcoin community. As a BIP progresses through the workflow, it becomes increasingly\nco-owned by the Bitcoin community.
\nAuthors may want additional help with the BIP process after writing an initial draft. In that case, they may assign\none or more Deputies to their BIP. Deputies are stand-in owners of a BIP who were not involved in writing the\ndocument. They support the authors in advancing the proposal, or act as a point of contact for the BIP in the absence of the\nauthors. Deputies may perform the role of Authors for any aspect of the BIP process unless overruled by an Author.\nDeputies share ownership of the BIP at the discretion of the Authors.
\nBIPs do not define what Bitcoin is: individual BIPs do not represent Bitcoin community consensus or a general\nrecommendation for implementation. A BIP represents a personal recommendation by the BIP authors to the Bitcoin\ncommunity. Some BIPs may never be adopted. Some BIPs may be adopted by one or more Bitcoin clients or other related\nsoftware. Some may even end up changing the consensus rules that the Bitcoin ecosystem jointly enforces.
\nThe BIPs repository serves as a publication medium and archive for mature proposals.\nThrough its high visibility, it facilitates the community-wide consideration of BIPs and provides a well-established\nsource to retrieve the latest version of any BIP. The repository transparently records all changes to each BIP and\nallows any community member to retain a complete copy of the archive easily.
\nThe BIPs repository neither tracks community sentiment[^acceptance] nor ecosystem adoption[^adoption] of BIPs beyond\nthe brief overview provided via the BIP status (see Workflow below).\nProposals are published in this repository if they are on-topic and fulfill the editorial criteria.\nNo formal or informal decision body governs Bitcoin development or decides adoption of BIPs.
\nAuthors may choose to submit BIPs in MediaWiki or Markdown[^markdown] format.
\nEach BIP must have a Preamble, an Abstract, a Copyright, and a Motivation section. Authors should consider all issues in the\nfollowing list and address each as appropriate.
\nEach BIP must begin with an RFC 822-style header preamble. The headers must\nappear in the following order. Headers marked with "*" are optional. All other headers are required.
\n BIP: <BIP number, or "?" before assignment>\n* Layer: <Consensus (soft fork) | Consensus (hard fork) | Peer Services | API/RPC | Applications>\n Title: <BIP title (≤ 50 characters)>\n Authors: <Authors’ names and email addresses>\n* Deputies: <Deputies’ names and email addresses>\n Status: <Draft | Complete | Deployed | Closed>\n Type: <Specification | Informational | Process>\n Assigned: <Date of number assignment (yyyy-mm-dd), or "?" before assignment>\n License: <SPDX License Expression>\n* Discussion: <Noteworthy discussion threads in "yyyy-mm-dd: URL" format>\n* Version: <MAJOR.MINOR.PATCH>\n* Requires: <BIP number(s)>\n* Replaces: <BIP number(s)>\n* Proposed-Replacement: <BIP number(s)>\nBIP — The assigned number of the BIP (without leading zeros). Please use "?" before a number has been assigned by the BIP Editors.
\nLayer — The layer of Bitcoin the BIP applies to using the BIP classification defined in BIP 123.
\nAuthors — The names (or pseudonyms) and email addresses of all authors of the BIP. The format of each authors header\nvalue must be
\nRandom J. User <address@dom.ain>\nMultiple authors are recorded on separate lines:
\nAuthors: Random J. User <address@dom.ain>\n Anata Sample <anata@domain.example>\nDeputies — Additional owners of the BIP that are not authors. The Deputies header uses the same format as the\nAuthors header. See the BIP Ownership section above.
\nStatus — The stage of the workflow of the proposal. See the Workflow section below.
\nType — See the BIP Types section below for a description of the three BIP types.
\nAssigned – The date a BIP was assigned its number. Please use "?" before a number has been assigned by the BIP Editors.
\nLicense — The License header specifies SPDX License Expressions describing the terms under which the\nBIP and its auxiliary files are available. See the BIP Licensing section below.
\nDiscussion — The Discussion header points the audience to relevant discussions of the BIP, e.g., the mailing list\nthread in which the idea for the BIP was discussed, a thread where a new version of the BIP was presented, or relevant\ndiscussion 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\nconversation. Multiple discussions should be listed on separate lines.
Version — The current version number of this BIP. See the Changelog section below.
\nRequires — A list of existing BIPs the new proposal depends on. If multiple BIPs\nare required, they should be listed in one line separated by a comma and space (e.g., "1, 2").
\nReplaces[^proposes-to-replace] — BIP authors may put the numbers of one or more prior BIPs in the Replaces header to recommend that their\nBIP succeeds, supersedes, or renders obsolete those prior BIPs.
\nProposed-Replacement[^superseded-by-proposed-replacement] — When a later BIP indicates that it intends to supersede an\nexisting BIP, the later BIP’s number is added to the Proposed-Replacement header of the existing BIP to indicate the\npotential successor BIP.
\nBIPs may include auxiliary files such as diagrams and source code. Auxiliary files must be included in a subdirectory\nfor that BIP named bip-XXXX, where "XXXX" is the BIP number zero-padded to four digits. File names in the subdirectory\ndo not need to adhere to a specific convention.
The BIP process starts with a new idea for Bitcoin. Each potential BIP must have authors—people who write the BIP,\ngather feedback, shepherd the discussion in the appropriate forums, and finally recommend a mature proposal to the\ncommunity.
\n
After having an idea, the authors should evaluate whether it meets the criteria to become a BIP, as described in this\nBIP. The idea must be of interest to the broader community or relevant to multiple software projects. Minor improvements\nand matters concerning only a single project usually do not require standardization and should instead be brought up directly to\nthe relevant project.
\nThe authors should first research whether their idea has been considered before. Ideas in Bitcoin are often rediscovered,\nand prior related discussions may inform the authors of the issues that may arise in its progression. After some investigation,\nthe novelty and viability of the idea should be tested by posting a new, dedicated thread about the idea to the Bitcoin Development Mailing\nList. Prior correspondence can be found in the mailing list\narchive.
\nIt is recommended that authors establish before or at the start of working on a draft whether their idea may be of\ninterest to the Bitcoin community.\nAuthors should avoid opening a pull request with a BIP draft out of the blue.\nVetting an idea publicly before investing time and effort to formally describe the idea is meant to save time for both the authors and\nthe community. Not only may someone point out relevant discussion topics that were missed in the authors’\nresearch, or that an idea is guaranteed to be rejected based on prior discussions, but describing an idea publicly also\ntests whether it is of interest to more people beside the authors.
\nAs a first sketch of the proposal is taking shape, the authors should present it to the Bitcoin Development Mailing\nList. This gives the authors a chance to collect initial feedback and address\nfundamental concerns. If the authors wish to work in public on the proposal at this stage, it is recommended that they\nopen a pull request against one of their forks of the BIPs repository instead of the main BIPs repository.
\nIt is recommended that complicated proposals be split into separate BIPs that each focus on a specific component of the\noverall proposal.
\nThe following sections refer to BIP Status field values. The BIP Status field is defined in the Header Preamble\nspecification above.
\nAfter fleshing out the proposal further and ensuring that it is of high quality and properly formatted, the authors\nshould open a pull request to the BIPs repository. The document must adhere to the\nformatting requirements specified above and should be provided as a file named with a working title of the form\n"bip-title.[md|mediawiki]". Only BIP Editors may assign BIP numbers. Until one has done so, authors should refer to their\nBIP by name only.
\nBIPs that (1) adhere to the formatting requirements, (2) are on-topic, and (3) have materially progressed beyond the\nideation phase, e.g., by generating substantial public discussion and commentary from diverse contributors, by\nindependent Bitcoin projects working on adopting the proposal, or by the authors working for an extended period toward\nimproving the proposal based on community feedback, will be assigned a number by a BIP Editor. A number may be\nconsidered assigned only after it has been publicly announced in the pull request by a BIP Editor. The BIP Editors should\nnot assign a number when they perceive a proposal being met with lack of interest: number assignment facilitates the\ndistributed discussion of ideas, but before a proposal garners some interest in the Bitcoin community, there is no need\nto refer to it by a number.
\nProposals are also not ready for number assignment if they duplicate efforts, disregard formatting rules, are too\nunfocused or too broad, fail to provide proper motivation, fail to address backward compatibility where necessary, or\nfail to specify the feature clearly and comprehensively. Reviewers and BIP Editors should provide guidance on how the\nproposal may be improved to progress toward readiness. Pull requests that are proposing off-topic ideas or\nhave stopped making progress may be closed.
\nWhen the proposal is ready and has been assigned a number, a BIP Editor will merge it into the BIPs repository. After the\nBIP has been merged to the repository, its main focus should no longer shift significantly, even while the authors may\ncontinue to update the proposal as necessary. Updates to merged documents by the authors should also be submitted as\npull requests.
\nWhen the authors have concluded all planned work on their proposal, are confident that their BIP represents a net\nimprovement, is clear, comprehensive, and is\nready for adoption by the Bitcoin community, they may update the BIP’s status to Complete to indicate that they\nrecommend adoption, implementation, or deployment of the BIP. Where applicable, the authors must ensure that any\nproposed specification is solid, not unduly complicated, and definitive. Specification BIPs must come with or refer to a working reference implementation and comprehensive test vectors before they can be moved to Complete. Subsequently, the BIP’s content should only be\nadjusted in minor details, e.g., to improve language, clarify ambiguities, backfill omissions in the specification, add\ntest vectors for edge cases, or address other issues discovered as the BIP is being adopted.
\nA Complete BIP can only move to Deployed or Closed. Any necessary changes to the specification should be minimal and\ninterfere as little as possible with ongoing adoption. If a Complete BIP is found to need substantial functional\nchanges, it may be preferable to move it to Closed[^new-BIP], and to start a new BIP with the changes instead.\nOtherwise, it could cause confusion as to what being compliant with the BIP means.
\nA BIP may remain in the Complete status indefinitely unless its authors or deputies decide to move it to Closed or it is advanced to\nDeployed.\nComplete is the final status for most successful Informational BIPs.
\nA Complete BIP should only be moved to Deployed once it is settled: after its approach has solidified, its\nSpecification has been put through its paces, feedback from early adopters has been processed, and amendments to the BIP have stopped.\nThen, a BIP may be advanced to Deployed upon request by any community member with evidence[^evidence] that\nthe BIP is in active use. Convincing evidence includes for example: an established project having deployed support\nfor the BIP in mainnet software releases, a soft fork proposal’s activation criteria having been met on the network, or\nrough consensus for the BIP having been demonstrated.
\nOnce Deployed, the BIP is considered final.\nAny modifications to the BIP beyond bug fixes, other minor amendments, additions to the test vectors, or editorial\nchanges should be avoided.\nAny breaking changes to the BIP’s Specification should be proposed as a new separate BIP.[^new-BIP]
\nA Process BIP may change status from Complete to Deployed when it achieves rough consensus on the Bitcoin Development Mailing List. A\nproposal is said to have rough consensus if its advancement has been open to discussion on the mailing list for at least\none month, the discussion achieved meaningful engagement, and no person maintains any unaddressed substantiated objections to it. Addressed or obstructive objections\nmay be ignored/overruled by general agreement that they have been sufficiently addressed, but clear reasoning must be\ngiven in such circumstances. Deployed Process BIPs may be modified indefinitely as long as a proposed modification has\nrough consensus per the same criteria.[^living-documents]
\nA BIP that is of historical interest only, and is not being actively worked on, promoted or in active use, should be\nmarked as Closed. The reason for moving the\nproposal to (or from) Closed should be recorded in the Changelog section in the same commit that updates the status.\nBIPs do not get deleted, they are retained even after being updated to Closed.\nTransitions involving the Closed state are:
\nBIP authors may decide on their own to change their BIP’s status from Draft to Closed. If a Draft BIP stops making\nprogress, sees accumulated feedback unaddressed, or otherwise appears stalled for a year, anyone may propose the BIP\nstatus be updated to Closed. The BIP is then updated to Closed unless the authors assert that they intend to continue work within four weeks of being contacted.
\nBIPs that had attained the Complete status, i.e., that had been recommended for adoption, may be moved to Closed per the\nauthors’ announcement to the Bitcoin Development Mailing List[^bip-announcements-to-list]. However, if someone volunteers to adopt the proposal\nwithin four weeks, they become the BIP's author or deputy (see Transferring BIP Ownership below), and the BIP will\nremain Complete instead.
\nA BIP may evolve from Deployed to Closed when it is no longer in active use. Any community member may initiate this\nStatus update by announcing it to the mailing list[^bip-announcements-to-list], and proceed if no objections have been raised for four weeks.
\nThe Closed status is generally intended to be a final status for BIPs,\nand if BIP authors decide to make another attempt at a previously Closed BIP, it is generally recommended to create a new\nproposal. (Obviously, the authors may borrow any amount of inspiration or actual text from any prior BIPs as licensing\npermits.) The authors should take special care to address the issues that caused the prior attempt’s abandonment. Even\nif the prior attempt had been assigned a number, the new BIP will generally be assigned a distinct number. However, if it is\nobvious that the new attempt directly continues work on the same idea, it may be reasonable to return the\nClosed BIP to Draft status.
\nTo help implementers understand updates to a BIP, any changes after it has reached Complete must be tracked with version,\ndate, and description in a Changelog section sorted by most recent version first. The version number is inspired by semantic versioning (MAJOR.MINOR.PATCH).\nThe MAJOR version is incremented if changes to the BIP’s Specification are introduced that are incompatible with prior\nversions (which should be rare after a BIP is Complete, and only happen in well-grounded exceptional cases to a BIP that\nis Deployed). The MINOR version is incremented whenever the specification of the BIP is changed or extended in a\nbackward-compatible way. The PATCH version is incremented for other changes to the BIP that are noteworthy (bug fixes,\ntest vectors, important clarifications, etc.). Version 1.0.0 is used to label the promotion to\nComplete. A Changelog section may be introduced during the Draft phase to record significant changes (using versions 0.x.y).
\nExample:
\n\n\nChangelog
\n\n
\n- 2.0.0 (2025-01-22):
\n\n
\n- Introduce a breaking change in the specification to fix a bug.
\n- 1.1.0 (2025-01-17):
\n\n
\n- Add a backward compatible extension to the BIP.
\n- 1.0.1 (2025-01-15):
\n\n
\n- Clarify an edge case and add corresponding test vectors.
\n- 1.0.0 (2025-01-14):
\n\n
\n- Complete planned work on the BIP.
\n
After a BIP receives a Changelog, the\nPreamble must indicate the latest version in the Version header. The Changelog highlights revisions to BIPs to human readers. A single\nBIP shall not recommend more than one variant of an idea at the same time. A different or\ncompeting variant of an existing BIP must be published as a separate BIP.
\nThe BIPs repository does not track the sentiment on proposals and does not track the adoption of BIPs beyond whether they\nare in active use or not. It is not intended for BIPs to list additional implementations beyond the reference\nimplementation: the BIPs repository is not a signpost where to find implementations.[^OtherImplementations] After a BIP\nis advanced to Complete, it is up to the Bitcoin community to evaluate, adopt, ignore, or reject a BIP. Individual\nBitcoin projects are encouraged to publish a list of BIPs they implement. A good example of this at the time of writing\nthis BIP can be observed in Bitcoin Core’s doc/bips.md\nfile.
\nIt occasionally becomes necessary to transfer ownership of BIPs to new owners. In general, it would be preferable to\nretain the original authors of the transferred BIP, but that is up to the original authors. A good reason to transfer\nownership is because the original authors no longer have the time or interest in updating it or following through with\nthe BIP process, or are unreachable or unresponsive. A bad reason\nto transfer ownership is because someone doesn't agree with the direction of the BIP. The community tries to build\nconsensus around a BIP, but if that's not possible, rather than fighting over control, the dissenters should supply a\ncompeting BIP.
\nIf someone is interested in assuming ownership of a BIP, they should send an email asking to take over, addressed to the\noriginal authors, the BIP Editors, and the Bitcoin Development Mailing List[^bip-announcements-to-list]. If the authors are unreachable or do not respond in a timely\nmanner (e.g., four weeks), the BIP Editors will make a unilateral decision whether to appoint the applicants as\nAuthors or Deputies (which may be amended should the original authors make a delayed reappearance).
\nThe Bitcoin project develops a global peer-to-peer digital cash system. Open standards are indispensable for continued\ninteroperability. Open standards reduce friction, and encourage anybody and everyone to contribute, compete, and\ninnovate on a level playing field. Only freely licensed contributions are accepted to the BIPs repository.
\nEach new BIP must specify in two ways under which license terms it is made available. First, it must specify an SPDX\nLicense Expression in the License field in the preamble. Second, it must include a matching\nCopyright section, possibly providing further details on licensing.
\nFor example, a preamble might include the following License header:
\nLicense: CC0-1.0 OR MIT\nIn this case, the BIP (including all auxiliary files) is made available under the terms of both CC0 1.0 Universal as well as the\nMIT License, and anyone may modify and redistribute it provided they comply with the terms of\neither license, at their option. In other words, the license list is an "OR choice", not an "AND also" requirement. See the SPDX\ndocumentation and the SPDX License List for further details.
\nWherever different from those specified in the License header, an auxiliary file or directory should specify the license terms under which it is made available as is common in\nsoftware (e.g., with a SPDX-License-Identifier: <SPDX License Expression> comment,\na license header, or a LICENSE/COPYING file). Such exceptions should also be mentioned in the Copyright section. It is recommended to make any test vectors available\nunder CC0-1.0 or FSFAP in addition to any other licenses to allow anyone to copy test vectors into their\nimplementations without introducing license hindrances.
A few BIP2-era BIPs (98, 116, 117, 330, 340) have a no longer used "License-Code" header indicating the license terms applicable to auxiliary source code files. For such cases, please refer to BIP2.
\nIt is recommended that source code included in a BIP (whether within the text or in auxiliary files) be licensed under the same license terms as the project it\nis proposed to modify, if any. For example, changes intended for Bitcoin Core would ideally be licensed (also) under the MIT\nLicense.
\nIn all cases, details of the licensing terms must be provided in the Copyright section of the BIP.
\nEach new BIP must be made available under at least one acceptable license as listed below. BIPs are not required to be\nexclusively licensed under approved terms, and may also be licensed under other licenses in addition to at least one\nacceptable license.
\nIn other words, a new BIP must specify an SPDX License Expression that is either "L" or equivalent to "L OR E" for some\nacceptable license L from the following list and another SPDX License Expression E.
\nAll licenses not explicitly included in the above lists are not acceptable terms for a Bitcoin Improvement Proposal.\nHowever, BIPs predating this proposal were accepted under other terms, and should use one of the following identifiers.
\nThe current BIP Editors are:
\nThe BIP Editors subscribe to the Bitcoin Development Mailing List and watch the BIPs\nrepository.
\nWhen either a new BIP idea or an early draft is submitted to the mailing list, BIP Editors or other community members should comment in regard\nto:
\nDiscussion in pull request comments can often be hard to follow as feedback gets marked as resolved when it is addressed\nby authors. Substantive discussion of ideas may be more accessible to a broader audience on the mailing list, where it\nis also more likely to be retained by the community memory.
\nIf the BIP needs more work, an editor should ensure that constructive, actionable feedback is provided to the authors\nfor revision. Once the BIP is ready it should be submitted as a "pull request" to the BIPs\nrepository where it may get further feedback.
\nFor each new BIP pull request that comes in, an editor checks the following:
\nEditors do NOT evaluate whether the proposal is likely to be adopted.
\nThen, a BIP Editor will:
\nThe BIP Editors are intended to fulfill administrative and editorial responsibilities. The BIP Editors monitor BIP\nchanges, and update BIP headers as appropriate.
\nBIP Editors may also, at their option, unilaterally make and merge strictly editorial changes to BIPs, such as\ncorrecting misspellings, mending grammar mistakes, fixing broken links, etc. as long as they do not change the meaning or conflict with the\noriginal intent of the authors. Such a change must be recorded in the Changelog if it’s noteworthy per the criteria\nmentioned in the Changelog section.
\nThis BIP replaces BIP 2 as the guideline for the BIP process.
\nStandards Track BIPs and eligible Informational BIPs are assigned the Specification type. The Standards Track type is\nconsidered obsolete. Specification BIPs use the Layer header rules specified in BIP 123.
\nThe Comments-URI and Comments-Summary headers should be removed from all BIPs whose comment page in the wiki is empty.\nFor existing BIPs whose comment page has content, BIP Authors may keep both headers or remove both headers at their\ndiscretion. It is recommended that existing wiki pages are not modified due to the activation of this BIP.
\nAfter the activation of this BIP, the Status fields of existing BIPs that do not fit the specification in this BIP are\nupdated to the corresponding values prescribed in this BIP. BIPs that have had Draft status for extended periods will be\nmoved to Complete or Deployed as applicable in collaboration with their authors. The authors of incomplete Draft BIPs\nwill be contacted to learn whether the BIPs are still in progress toward Complete, and will otherwise be updated to\nClosed as described in the Workflow section above.
\nThe Author header is replaced with the Authors header in all BIPs.
\nThe Post-History header is replaced with the Discussion header in all BIPs.
\nThe Superseded-By header is replaced with the Proposed-Replacement header in all BIPs.
\nExisting BIPs retain their license terms unchanged.\nThe License and License-Code headers of BIPs are updated to express those terms using SPDX License Expressions.
\nThis BIP is licensed under the BSD-2-Clause License. Some content was\nadapted from BIP 2 which was also licensed under the BSD-2-Clause.
\nWe thank AJ Towns, Jon Atack, Jonas Nick, Larry Ruane, Pieter Wuille, Tim Ruffing, and others for their review,\nfeedback, and helpful comments.
\n[^assigned]: Why was the Created header renamed to Assigned?
Both BIP 1 and BIP 2 described the Created header as "date created on" in the preamble template, but followed that\n up with "Created header records the date that the BIP was assigned a number" as the description of the field. This\n has frequently led to confusion, with authors using the date of opening the pull request, the date they started\n writing their proposal, the date of number assignment (as prescribed), or various other dates. Aligning the name of\n the header and the text in the preamble template with the descriptions will reduce the confusion.\n[^standard-track]: Why was the Specification type introduced?
The definitions of Informational and Standards Track BIPs caused some confusion in the past. Due to Informational\n BIPs being described as optional, Standards Track BIPs were sometimes misunderstood to be generally recommended.\n This has led to a number of BIPs that propose new features affecting interoperability of implementations being\n assigned the Informational type. The situation is remedied by introducing a new Specification BIP type that is\n inclusive of any BIPs that can be implemented and affect interoperability of Bitcoin applications. Since all BIPs\n are individual recommendations by the authors (even if some may eventually achieve endorsement by the majority of\n the community), the prior reminder that Informational BIPs are optional is dropped.\n[^comments]: Why were comments, Comments-URI, and Comments-Summary removed from the process?
The comments feature saw insignificant adoption. Few BIPs received any comments and barely any more than two with\n only a handful of contributors commenting at all. This led to many situations in which one or two comments ended up\n dominating the comment summary. While some of those comments may have been representative of broadly held opinions,\n it also overstated the importance of individual comments directly in the Preamble of BIPs. As collecting feedback in\n this accessible fashion failed, the new process puts the burden back on the audience to make their own evaluation.\n[^layer]: Why is the layer header now permitted for other BIP types?
The layer header had already been used by many Informational BIPs, so the rule that it is only available to\n Standards Track BIPs is dropped.\n[^OtherImplementations]: What is the issue with "Other Implementations" sections in BIPs?
In the past, some BIPs had "Other Implementations" sections that caused frequent change requests to existing BIPs.\n This put a burden on the BIP authors and BIP Editors, and frequently led to lingering pull requests due to the corresponding BIPs’\n authors no longer participating in the process. Many of these alternative implementations eventually became\n unmaintained or were low-quality to begin with. Therefore, "Other Implementations" sections are heavily discouraged.\n[^complete]: Why was the Proposed status renamed to Complete?
Some reviewers of this BIP raised that in a process which outlines the workflow of Bitcoin Improvement Proposals\n using "Proposed" as a status field value was overloading the term: clearly proposals are proposed at all stages of\n the process. "Complete" expresses that the authors have concluded planned work on all parts of the proposal and are\n ready to recommend their BIP for adoption. The term "ready" was also considered, but considered too subjective.\n[^rejection]: Why can proposals remain in Draft or Complete indefinitely?
The automatic 3-year timeout of BIPs has led to some disagreement in the past and seems unnecessary in cases where\n the authors remain active in the community and still consider their idea worth pursuing. On the other hand,\n Draft proposals that appear stale may be closed after only one year, which should achieve the main goal of\n the original rule by limiting the effort and attention spent on proposals that never reach Complete.\n[^closed]: Why was the Closed Status introduced?
The Closed Status provides value to the audience by indicating which documents are only of historical significance.\n Previously, the process had Deferred, Obsolete, Rejected, Replaced, and Withdrawn, which all meant some flavor of\n "work has stopped on this." The many statuses complicated the process, may have contributed to process fatigue, and\n may have resulted in BIPs’ statuses not being maintained well. The author of this BIP feels that all of the\n aforementioned can be represented by Closed without significantly impacting the information quality of the\n overview table. Where the many Status variants provided minuscule additional information, the simplification is more\n valuable and the Changelog section now collects specific details.\n[^acceptance]: When is a BIP "accepted"?
Many standards processes such as the PEPs or the IETF have a mechanism for a proposal to be formally accepted by\n some council or committee. The BIP Process does not have such a decision body. Bitcoin development and "acceptance"\n of BIPs emerges from the participation of stakeholders across the ecosystem, and refers to some vague notion of community\n interest and support for a proposal.
BIP 2 had made an attempt to gather community feedback into comment summaries in BIPs directly. Given the low\n participation and corresponding low information quality of the summaries that resulted from that feature, this BIP\n instead intends to leave the evaluation of BIPs to the reviewers and users.\n[^adoption]: Why does the BIPs repository no longer track adoption?
In the past, some BIPs maintained lists of projects that had implemented the BIP. These lists generated\n noise for subscribers of the repository, often listed implementations of questionable quality, and quickly\n grew outdated, therefore providing little value. The repository no longer tracks which projects have implemented\n BIPs. Instead, it is recommended that projects publish a list of the BIPs they implement.\n[^markdown]: Which flavor of Markdown is allowed?
The author of this proposal has no opinion on Markdown flavors, but recommends that proposals stick to the basic\n Markdown syntax features commonly shared across Markdown dialects.\n[^living-documents]: Why are Process BIPs living documents?
In the past years, the existing BIPs process has not always provided a clear approach to all situations. For\n example, the content of BIP 2 appears to have been penned especially with fork proposals in mind. It seems clear\n that Bitcoin development will evolve in many surprising ways in the future. Instead of mandating the effort of\n writing a new process document every time new situations arise, it seems preferable to allow the process to adapt to\n the concerns of the future in specific aspects. Therefore, Process BIPs are defined as living documents that remain\n open to amendment. If a Process BIP requires large modifications or even a complete overhaul, a new BIP should be\n preferred.\n[^new-BIP]: Why should the specification of an implemented BIP no longer be changed?
After a Complete or Deployed BIP has been deployed by one or more implementations, breaking changes to the\n specification could lead to a situation where multiple "compliant" implementations fail at being interoperable,\n because they implemented different versions of the same BIP. Therefore, even changes to the specification of\n Complete BIPs should be avoided, but Deployed BIPs should never be subject to breaking changes to their\n specification.\n[^bip-announcements-to-list]: Why are some BIP status changes announced to the mailing list?
The BIPs repository does not and cannot track who might be interested in or has deployed a BIP. While concerns were\n raised that making announcements to the Bitcoin Developer Mailing List would introduce unnecessary noise, our\n rationale is that 1) moving Complete and Deployed BIPs to the Closed status will be a rare occurrence, 2) status\n updates will usually not generate a lot of discussion, 3) while the mailing list should preferably only used for\n getting review for new BIPs, it is the only channel available to us that can be considered a public announcement to\n the audience of the BIPs repository: even if the authors, implementers, or other parties interested in a BIP do not\n see the announcement themselves, they may be made aware by someone that does see it.\n[^superseded-by-proposed-replacement]: Why is Superseded-By replaced with Proposed-Replacement?
Reviewers asked who should get to decide whether a BIP is superseded in case of a disagreement among the authors of\n the original BIP, the authors of the new BIP, the editors, or the community? This is addressed by making the\n "Replaces" header part of the recommendation of the authors of the new document, and replacing the "Superseded-By"\n header with the "Proposed-Replacement" header that lists any proposals that recommend replacing the original document.\n[^proposes-to-replace]: Why was "Replaces" retained instead of changing it to "Proposes-to-Replace"?
When one BIP proposes to supersede another, it is on the original BIP where things get complicated. The BIP is an\n author document, but depending on its progress through the workflow, it may meanwhile be co-owned by the community. Who may decide\n whether the original document should endorse a potential replacement BIP? Is it the original authors, the authors of the new\n proposal, the BIP Editors, some sort of community process, or a mix of all of the above?
On the new BIP these problems don’t exist in the same manner. As it is freshly written, it is wholly owned by its\n authors. The community is not yet invested and the original BIP’s authors do not have a privileged role\n in determining the content of the new BIP. The authors of the new BIP can unilaterally recommend that it be\n considered a replacement for a prior BIP. From there, the community can evaluate the proposal and adopt or\n reject it, thus establishing whether it is successful in superseding the original or not.\n[^evidence]: How is evidence for advancing to Deployed evaluated?
Whether evidence is deemed convincing to move a BIP to Deployed is up to the BIP Editors and Bitcoin community.\n Running a single instance of a personal fork of a software project might be rejected, while a small software project with\n dozens of users may be sufficient. The main point of the Deployed status is to indicate that changes to the BIP\n could negatively impact users of projects that have already implemented support.\n[^licenses]: Why were some licenses dropped?
Among the 141 BIPs with licenses in the repository, only nine licenses have ever been used to license BIPs\n (although, some BIPs were made available under more than one license) and only one license has been used to license\n code:
Licenses used:\n\n* BSD-2-Clause: 55\n* PD: 42\n* CC0-1.0: 23\n* BSD-3-Clause: 19\n* OPUBL-1.0: 5\n* CC-BY-SA-4.0: 4\n* FSFAP: 3\n* MIT: 2\n* CC-BY-4.0: 1\n\nLicense-Code used (previous BIP2 format):\n\n* BSD-2-Clause: 1\n* CC0-1.0: 1\n* MIT: 5\n\nThe following previously acceptable licenses were retained per request of reviewers, even though they have so far\nnever been used in the BIPs process:\n\n* Apache-2.0: [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0)\n* BSL-1.0: [Boost Software License 1.0](https://www.boost.org/LICENSE_1_0.txt)\n\nThe following previously acceptable licenses have never been used in the BIPs Process and have been dropped:\n\n* AGPL-3.0+: [GNU Affero General Public License (AGPL) 3](https://www.gnu.org/licenses/agpl-3.0.en.html)\n* FDL-1.3: [GNU Free Documentation License 1.3](https://www.gnu.org/licenses/fdl-1.3.en.html)\n* GPL-2.0+: [GNU General Public License (GPL) 2 or newer](https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html)\n* LGPL-2.1+: [GNU Lesser General Public License (LGPL) 2.1 or newer](https://www.gnu.org/licenses/old-licenses/lgpl-2.1.en.html)\n\nWhy are software licenses included?\n\n* Some BIPs, in particular those concerning the consensus layer, may include literal code in the BIP itself which\n may not be available under the license terms the authors wish to use for the BIP.\n* The author of this BIP has been provided with a learned opinion indicating that software licenses are perfectly\n acceptable for licensing "human code" i.e., text as well as Markdown or MediaWiki code.\n\nWhy is CC-BY-SA-4.0 no longer acceptable for new BIPs?\n\n* Specification BIPs are required to have a Reference Implementation and Test Vectors to be advanced to Complete. As\n the BIPs repository is aiming to make proposals easily adoptable, the intention is for the reference\n implementation and test vectors to be as accessible as possible. Copyleft licenses may introduce friction here,\n and therefore CC-BY-SA-4.0 (and the GPL-flavors) is no longer considered acceptable for new BIPs. As mentioned\n above, existing BIPs will retain their original licensing.\n\nWhy are Open Publication License and Public Domain no longer acceptable for new BIPs?\n\n* Public domain is not universally recognised as a legitimate action, thus it is inadvisable.\n* The Open Publication License is generally regarded as obsolete, and not a license suitable for new publications.\n