bitcoin/bips

★ 10,763WikitextAudience · developerComplexity · 2/5Setup · easy

Mindmap

mindmap
  root((Bitcoin BIPs))
    Layers
      Consensus changes
      Peer Services
      Applications
      API/RPC
    Statuses
      Draft pending
      Deployed live
      Complete finalized
      Closed rejected
    Key standards
      BIP32 HD wallets
      BIP39 mnemonic seeds
      BIP141 SegWit
      BIP340 341 Taproot
    Process
      Mailing list first
      BIP editor review
      Number assigned
      Merge and publish

mindmap root((Bitcoin BIPs)) Layers Consensus changes Peer Services Applications API/RPC Statuses Draft pending Deployed live Complete finalized Closed rejected Key standards BIP32 HD wallets BIP39 mnemonic seeds BIP141 SegWit BIP340 341 Taproot Process Mailing list first BIP editor review Number assigned Merge and publish

Click or tap to explore — scroll the page freely

Things people build with this

USE CASE 1

Look up the technical specification for a Bitcoin feature like Taproot, SegWit, or HD wallets before implementing support for it.

USE CASE 2

Research which Bitcoin standards are deployed, in draft, or were rejected, to understand the protocol's current state.

USE CASE 3

Implement a standard Bitcoin wallet feature such as BIP39 mnemonic seeds or BIP32 key derivation from the formal spec.

USE CASE 4

Submit a new Bitcoin protocol proposal by reading the BIP process guidelines and opening a pull request to this repository.

Tech stack

WikitextMarkdown

Getting it running

Difficulty · easy Time to first run · 5min

License not mentioned in the README.

In plain English

Bitcoin Improvement Proposals, known as BIPs, are formal written specifications for proposed changes to the Bitcoin protocol. This repository is the official archive where all BIPs are published, tracked, and stored. It serves as the community's central record of both accepted and rejected proposals going back to the early days of Bitcoin. Anyone wanting to propose a change to Bitcoin starts by discussing the idea on the bitcoindev mailing list to gather feedback. If the idea has enough substance, they write it up as a formal BIP document following a specific format. A BIP editor reviews it for completeness and assigns it a number, then publishes it here by merging the pull request. Being published in this repository signals that a proposal meets basic editorial standards, not that the community has agreed to adopt it. The main index in this repository lists every BIP by number, the layer of Bitcoin it affects (applications, consensus changes, peer services, or API/RPC), the title, the author or authors, the type (informational, specification, or process), and its current status. Statuses include Draft, Deployed, Closed, and Complete. Green in the index means the proposal has been deployed to the Bitcoin network, red means it was closed or rejected, yellow means it is complete but not yet broadly deployed. Some of the most significant BIPs cover topics like Hierarchical Deterministic Wallets (BIP 32), the 12-word mnemonic seed phrase standard (BIP 39), Segregated Witness (BIP 141), Schnorr signatures (BIP 340), Taproot (BIP 341), and the Partially Signed Bitcoin Transaction format (BIP 174). These are the technical standards that Bitcoin wallets, exchanges, and developers build on top of. The full README is longer than what was shown.

Copy-paste prompts

Prompt 1

I need to implement BIP39 mnemonic seed phrases in my Bitcoin wallet app. Summarize the key requirements from the BIP39 specification.

Prompt 2

Explain Taproot (BIP341) in plain English: what it changes, why it was added, and what wallets need to do to support it.

Prompt 3

I want to submit a Bitcoin Improvement Proposal. Based on the BIP process documented here, what are the steps from idea to getting a number?

Prompt 4

Explain the difference between BIP44, BIP49, BIP84, and BIP86 HD wallet derivation paths and when each should be used.

Open on GitHub → Explain another repo

← bitcoin on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.