bitcoin/bips: the editorial process behind Bitcoin's written standards

What publication in this repository does not mean

The README opens with a paragraph that is worth reading twice, because it is the corrective for almost every misstatement about how Bitcoin development works. A BIP published in this repository indicates the proposal is in scope and has met formal criteria. It does not indicate that it is a good idea, that it has community consensus, or that it is about to be adopted.

The README goes on to describe the editors' posture: they are expected to be liberal with publishing, and to try not to be too involved in decision-making on behalf of the community. Evaluation of proposals is left to the audience of the repository. And when a proposal is controversial and it cannot be agreed upon whether it should be published, the conservative option always wins, which in practice means the proposal gets closed.

The last sentence shifts the frame again: those proposing and opposing changes should consider that acceptance and adoption ultimately rests with Bitcoin users, with a link to the economic majority page on the Bitcoin wiki. So the repository is a filter for formal quality, not a decision-making body. That is a narrower role than most readers assume when they hear that something is a BIP.

The final framing line is a filter on hype: the repository serves as a publication medium and archive.

The path from mailing list to assigned number

The submission process is spelled out in the opening paragraph and it is stricter than a typical open-source contribution. Someone wishing to submit a BIP should first describe their idea to the bitcoindev mailing list to gather feedback on viability and community interest before working on a formal description. Only when substantial progress on the draft has been made, preferably when the draft is nearing completion, should a pull request be opened here.

One rule is stated with unusual clarity: authors do not assign a number to their own proposal. After a proposal meets the editorial criteria, a BIP Editor assigns the number and publishes the proposal by merging the pull request. The README points to BIP 3, Updated BIP Process, for the full process.

The sequencing matters more than it might look. Writing the specification before anyone has said whether the idea is viable is the wrong order, and the process asks you not to do it. The reason is not gatekeeping but redundancy: Bitcoin has thousands of people writing protocol changes, and several that turn out to be the same change would otherwise accumulate as separate drafts competing for numbers.

BIPs 1 and 2 are both listed as Process documents by their original authors, Amir Taaki and Luke Dashjr respectively, and both are marked Closed. BIP 3, owned by Murch and marked Deployed, replaced them. The repository's own table is evidence that the process is revisable.

Reading the table: layer, type and status

The README holds a single sortable wiki table with columns for Number, Layer, Title, Owner, Type and Status, and the row colour encodes status: green for deployed and complete, yellow for complete or number-allocated, red for closed. Learning to read the columns is most of what you need in order to use this repository.

The Layer column divides proposals into Consensus (soft fork), Applications, Peer Services, API/RPC and Process. This is the column that determines who a proposal actually affects, and it is the one most worth sorting on. A consensus change reaches every node on the network and cannot be walked back once deployed, which is why that category carries the strictest editorial bar in practice even though the README does not say so in those words.

The Type column distinguishes Process, Informational, Standard and Specification. An Informational BIP such as version bits with lock-in by height, number 8, changes nothing about consensus and asks only that readers agree on a description of how the system works. A Standard such as the Stratum wire protocol at number 40 has a number allocated but no published document yet.

Status is the column that gets misread most. Deployed means the change is live. Complete means the specification is finished. Closed means withdrawn, rejected or superseded, and reading the table gives you real examples: OP_EVAL at number 12 is Closed, while pay to script hash at 16 is Deployed.

The proposals everyone ends up reading

Certain numbers have become reference points well outside the protocol work, and the table makes clear why. Number 42, A finite monetary supply for Bitcoin by Pieter Wuille, is a Deployed consensus proposal, and the 21 million cap that follows from it is one of the most widely cited numbers in the ecosystem.

Numbers 32, 39, 43 and 44 are the deterministic wallet lineage. Number 32 is Hierarchical Deterministic Wallets by Pieter Wuille, marked Informational and Deployed. Number 39 is the Mnemonic code for generating deterministic keys by Marek Palatinus, Pavol Rusnak, Aaron Voisine and Sean Bowe, a Specification marked Deployed. Number 43 adds a Purpose field, and number 44 adds a multi-account hierarchy, both by Palatinus and Rusnak and both Deployed. Read together they explain the derivation paths and the word lists that appear in every wallet seed phrase interface.

Number 11, M-of-N Standard Transactions by Gavin Andresen, is the original multisig standard and is Deployed. Number 23 covers pooled mining through getblocktemplate and is also Deployed, while number 40 and 41 cover the Stratum wire protocol and mining protocol with numbers allocated only.

The authorship column is worth scanning on its own. Gavin Andresen, Pieter Wuille, Luke Dashjr, Murch, Amir Taaki and the multisig pair at number 39 recur throughout, which tells you where the durable engineering has come from without needing any history write-up.

What the repository looks like as a working tree

The tree is flat and self-describing, which is appropriate for an archive. Each proposal is a file named for its number, and the extension varies: most early ones are `.mediawiki`, while newer entries such as `bip-0003.md` and `bip-0054.md` are Markdown. That migration is visible in the tree and is worth knowing before you file something, since it tells you what the editors currently prefer.

Proposals that need media carry a sibling directory, so `bip-0001/` and `bip-0002/` sit next to their files, as do `bip-0016/`, `bip-0032/`, `bip-0039/`, `bip-0042/`, `bip-0047/`, `bip-0052/` and `bip-0053/`. Assets live with the document rather than in a shared folder, which is the right call for a repository that will be mirrored and read for decades.

Alongside the documents sit `README.mediawiki` for the index, `CONTRIBUTING.md`, and `SECURITY.md`. There is also a `.typos.toml`, which is a small sign of how seriously the archive is treated: a typo checker running over fifty historical proposals is the kind of maintenance that only happens in a repository with real custodianship.

There are no releases and no license file in the tree, and the default branch is `master`. For an archive whose contents are cited in software licences and specifications worldwide, the absence of a stated licence is the one structural thing that stands out.

Scale, activity and what the fork count suggests

The repository has 10,949 stars and, more tellingly, 6,024 forks. A fork count above half the star count is unusual for a codebase and completely ordinary here, because the intended use of a fork is to propose a BIP. Anyone with a draft needs somewhere to put it before a number exists, and this repository is where the convention says drafts live.

There are 60 open issues, which is a reasonable queue for a process that expects debate to happen on the mailing list rather than in issue threads. The last push was on 2026-09-21, so the archive and the process around it are both being maintained rather than left to rot.

Language is listed as Wikitext, which follows from the README and the older proposal files, though the newer Markdown entries suggest that label lags the practice. There are no repository topics listed at all, which for a repository with eleven thousand stars is a small missed piece of metadata.

What the repository is not is documentation. Nothing here explains how to run a node, how to validate a transaction, or how consensus works. It is the place where changes to the rules are written down, and the fact that it is that, and only that, is the design.

Editorial conclusion

The bitcoin/bips repository is a publication process that happens to be stored in git, and the README is more interesting than the table of fifty-plus documents it holds. The process described there is deliberately slow: ideas go to the bitcoindev mailing list before they become a draft, a pull request comes only when substantial progress exists, and a BIP Editor assigns the number rather than the author. The other thing the README insists on, over several paragraphs, is that publication means a proposal met editorial criteria and nothing more, not that it is a good idea, has consensus, or is about to be adopted. That distinction is the one most secondary summaries of Bitcoin governance get wrong. For a reader working on the protocol, start with BIP 3, which the README names as the current process document, then read the status column for the proposals touching the layer you work on, because Deployed, Complete and Closed carry very different weight for an implementation.

Frequently asked questions

Official sources

1. bitcoin/bips on GitHub
2. Issues
3. README