What a node checks

A full node checks each transaction and each block against the rules it is running. It does not ask a company if the payment is real. If two nodes run the same rules, they can disagree about what is in the mempool and still agree about what is in the chain once a block is valid.

The money page says every node checks the same rules. This page is those rules, and how they get a new version.

How a rule changes

A soft fork tightens the rules. Old nodes still see the new blocks as valid, if the new rules are a subset. A hard fork is a split: nodes that do not upgrade no longer follow the same chain. Bitcoin’s shipped upgrades on this page are soft forks, plus wallet formats that do not change consensus at all.

Nobody assigns you the upgrade. You choose the software. The economic majority is the users who keep accepting coins under one set of rules.

A BIP is a filing

Bitcoin Improvement Proposals live in the bitcoin/bips repository. An editor assigns the number. Publication means the text met the filing rules. It does not mean the idea is good, that people agree, or that it will ship. That sentence is the repository’s own standard, paraphrased. The process text is BIP 3.

Drafts are not the roadmap. A draft is a text under discussion. This page lists only proposals the repository marks Deployed, and only the chain that changed what a holder can do. It does not summarize the rest.

One filing led to the next

Titles and status are from the repository README. The plain line under each title is ours.

1. BIP 16Pay to Script Hash

   You can pay a script, not only a key. The script stays hidden until it is spent. Consensus, soft fork. Deployed.

2. BIP 32Hierarchical Deterministic Wallets

   One backup can grow a tree of keys. Wallet format. Not a consensus change. Deployed.

3. BIP 39Mnemonic code for generating deterministic keys

   That backup can be words. Wallet format. Deployed.

4. BIP 125Opt-in Full Replace-by-Fee Signaling

   A sender can mark a transaction as replaceable before it confirms. Applications. Deployed.

5. BIP 141Segregated Witness

   Signature data sits outside the old transaction id, so a third party cannot change that id without changing the payment. That left room for the later rules. Consensus, soft fork. Deployed. BIP 143 and BIP 144 are the signature and peer-service halves. BIP 173 is the bc1 address for those outputs.

6. BIP 341Taproot

   A spend can look like a single key unless a script is used. BIP 340 is the Schnorr signature. BIP 342 is the script validation. Consensus, soft fork. Deployed together. BIP 350 is the address checksum for those newer outputs.

Not on this list

Lightning is a separate set of specifications, not a BIP on this chain. A company roadmap is not this list. A plain-English index of every filing is useful for reading, and it is not the spec. BIP Explorer is one such index. Read the linked text before you treat a summary as the rule.