You asked two sharp things: are the rules in the software the servers download? and is there software besides Bitcoin Core? The answer to both is yes — and the why is the whole design.
This time we don't just read it. You'll break a rule, mine a block, tamper with a chain, walk the halving schedule to 21 million, and split the network in two — each idea as something you do.
There is no central server holding "the official rules of Bitcoin." The protocol is defined by what the running software accepts and rejects. Every full node has its own copy of the validation logic and checks every block and transaction against it independently.
The rules aren't written on a tablet somewhere. They're whatever the software you're running will accept.
When your node receives a block, it runs it past a checklist. Fail any item and the block is dropped. The load-bearing ones:
These live in Bitcoin Core's C++ validation code, and in every other implementation that wants to stay on the same network.
Four full nodes, each running different software but the same consensus rules. Feed them a block. Valid → all accept. Tamper with it → they reject it without consulting each other.
No node asks the others' permission. Each independently runs the rule and reaches the same verdict. That redundancy is the security model.
A hash is a fixed-length fingerprint of data. Change one character and the output changes completely and unpredictably — and you can't run it backwards. Type below and watch it scramble on a single keystroke.
This is a tiny instant stand-in, not real SHA-256 — but the property (small change → total scramble, one-way) is exactly the same.
Every block stores the hash of the previous block. Edit the data in Block 1 and watch its fingerprint change — which breaks Block 2's reference to it, which breaks Block 3. One edit, everything downstream goes red.
This is why rewriting history is hopeless: to change one old block you'd have to redo the proof-of-work for it and every block after it, faster than the rest of the network adds new ones.
A valid block's hash must be below a target. Miners change a counter (the nonce) and re-hash, over and over, until they get lucky. The lower the target, the more attempts it takes — that's difficulty.
Set the difficulty (required leading zeros) and mine. Watch the attempt counter climb.
Real Bitcoin needs ~19 leading zeros (in hex), tuned so the whole planet's mining power finds one block every ~10 minutes. Each extra zero multiplies the work — feel how fast it explodes between 4 and 5 here.
No code says "stop at 21 million." Instead the block reward halves every 210,000 blocks. Add up every reward forever and the sum converges to just under 21M. Drag through the halving eras and watch supply approach the ceiling.
By around 2140 the reward rounds to zero and no new coins are created. The cap is an emergent consequence of the halving rule, enforced by every node rejecting any block that pays itself more than the schedule allows.
Bitcoin Core runs on most nodes, but several implementations exist. The crucial split isn't the programming language — it's whether they enforce the same consensus rules.
Go — not derived from Core's C++. A genuinely separate codebase targeting the same rules.JavaScript) and Libbitcoin (a C++ library/toolkit). Different code, same network — when they agree on the rules.Same rules, different code. Core, Knots, and btcd interoperate on one network — they accept and reject identical blocks, just in different languages.
Agreement is the point. A subtle bug making one client validate differently would fork its nodes off — which is why most operators run the most battle-tested implementation.
Different software enforcing identical rules is still the same Bitcoin. The diversity is healthy: if one client has a bug, others catch the divergence.
Alternative software is fine only if it enforces the same consensus rules. The moment a client intentionally changes a rule and enough people adopt it, you don't have "alternative Bitcoin software" — you have a separate blockchain and a separate currency.
The famous splits weren't just "different software" — they were deliberate hard forks: Bitcoin Cash (2017) and later Bitcoin SV (2018), each raising the block-size limit and creating its own chain and coin.
Six nodes share one chain. Push the "32 MB blocks" rule change to some of them, then broadcast a big block. Nodes that accept the new rule follow one chain; nodes that don't reject the block and stay on the original. That divergence is a fork.
If everyone adopts the change, there's no split — it's just an upgrade. The split happens only when the network disagrees. That's the real meaning of "consensus."
Your two questions are really one, seen from two sides. The rules live in the software — and there are many pieces of software. What keeps it all "Bitcoin" is not a central authority blessing one program, but thousands of independent nodes agreeing, block by block, on the same validation logic. Swap the language, keep the rules: same network. Keep the language, change a rule: new network.
Consensus isn't a vote you win. It's the set of blocks everyone's software already agrees to accept.
Answer all four to complete the teardown
The rules live in the code every node runs. Many programs run that code. It stays one Bitcoin as long as they enforce the same rules — and becomes a new coin the moment they don't.