Down the rabbit hole, one level at a time.

Nodes follow the valid chain with the most cumulative proof of work, not the one with the most blocks. Validity is checked first; work only breaks ties between valid histories.

• A majority-hashrate attacker can reorder or censor recent transactions and double-spend their own coins.
• They cannot create coins beyond the schedule, spend coins without the keys, or change rules that nodes enforce. Invalid blocks are rejected however much work they carry.
• The chance an attacker with less than half the hashrate catches up from z blocks behind falls exponentially with z (section 11 of the white paper).
• Known strategies and attacks to study: selfish mining (Eyal & Sirer, 2013), fee sniping, and eclipse attacks at the network layer.

A block is valid only if its double-SHA-256 header hash, read as a 256-bit number, is at or below the target. The header stores the target compactly in nBits: one exponent byte and a three-byte mantissa. The genesis block's 0x1d00ffff defines difficulty 1; difficulty = max target ÷ current target.

• Every 2,016 blocks: new_target = old_target × actual_time ÷ 1,209,600 s, with the time span clamped to between ¼ and 4× two weeks.
• Timestamps must exceed the median time past (median of the previous 11 blocks) and be no more than two hours ahead of a node's clock.
• Quirk: the retarget measures 2,015 intervals, not 2,016, an off-by-one from the original code. Together with loose timestamp rules this enables the “time warp” attack that the Great Consensus Cleanup proposal aims to close.

Script is stack-based and deliberately not Turing-complete: no loops, bounded execution, predictable cost. Each upgrade moved complexity off-chain or made it cheaper and more private.

1. P2PKH (2009): pay to the HASH160 of a public key. The lab above runs this one.
2. P2SH (BIP 16, 2012): pay to the hash of a script; the spender reveals and satisfies it. Made multisig practical.
3. SegWit v0 (BIP 141, 143, 144; block 481,824, August 2017): moves signatures into the witness, fixes malleability, adds a new signature hash that commits to input amounts, and paved the way for Lightning.
4. Taproot (BIP 340, 341, 342; block 709,632, November 2021): Schnorr signatures, a key-path spend that looks like any single-sig, and a tree of alternative scripts (MAST) where only the branch used is revealed. Tapscript adds OP_CHECKSIGADD for efficient threshold signatures.

Bitcoin uses the elliptic curve secp256k1: y² = x³ + 7 over the prime field p = 2²⁵⁶ − 2³² − 977.

• Private key: a random integer k with 1 ≤ k < n (the group order). Public key: K = k·G. Easy one way, infeasible to reverse.
• Signatures: ECDSA for legacy and SegWit v0; Schnorr (BIP 340) for Taproot, which is linear and enables key aggregation such as MuSig2.
• Hashes: SHA-256 for proof of work and txids; HASH160 = RIPEMD-160(SHA-256(x)) for legacy and v0 addresses. Taproot outputs commit directly to a tweaked 32-byte x-only key.
• Encodings: Base58Check for 1… and 3…; Bech32 (BIP 173) for bc1q…; Bech32m (BIP 350) for bc1p….
• Security rests on good randomness. Never generate keys with home-made methods.

• Nodes announce new data with inv messages and fetch it with getdata. Transactions are relayed with randomised delays to make tracing the origin harder.
• Compact block relay (BIP 152) sends short transaction IDs, since peers usually already have the transactions in their mempools, so blocks propagate quickly.
• BIP 324 adds encrypted peer-to-peer transport. Bitcoin Core can also run over Tor and I2P.
• Eclipse attacks try to surround a node with attacker peers. Defences include many outbound connections, diverse peer selection and anchor connections kept across restarts.
• A new node syncs headers first, then downloads and validates blocks: the initial block download.

Consensus rules decide which blocks are valid; every node must agree, or the network splits. Policy (standardness) decides which unconfirmed transactions a node relays and keeps in its mempool. Policy can differ between nodes and versions without a fork.

• Examples of policy: dust limits, which script types count as standard, minimum relay fee and mempool size.
• Fee bumping: replace-by-fee (BIP 125) and child-pays-for-parent. Newer policy work such as package relay and TRUC (v3) transactions (BIP 431) makes bumping more reliable, which matters for Lightning.
• Miners can include non-standard but valid transactions submitted to them directly.

• A channel is a 2-of-2 multisig funding output. Each side holds a signed commitment transaction paying out the current balances.
• Updating the channel revokes the old state by revealing a secret. Broadcast a revoked state and your peer can claim the whole channel with a penalty transaction. Watchtowers can watch for this on your behalf.
• Multi-hop payments use HTLCs: outputs locked to a hash H = SHA256(preimage), with timelocks that shrink at each hop so every node can settle safely.
• Onion routing (Sphinx) means each hop learns only its previous and next hop.
• The protocol is specified in the BOLTs. Newer work includes splicing, BOLT 12 offers, and PTLCs that use Schnorr adaptor signatures instead of shared hashes.

• Changes start as Bitcoin Improvement Proposals (BIPs), are debated in public, reviewed and implemented in node software.
• A soft fork tightens the rules, so old nodes still accept new blocks. A hard fork loosens them and splits off nodes that don't upgrade.
• Activation methods have included miner signalling with version bits (BIP 9) and Speedy Trial, used for Taproot. In the end, nodes enforce rules; the 2017 block-size dispute showed that miners alone can't change them.
• Proposals such as OP_CHECKTEMPLATEVERIFY (BIP 119) and OP_CAT (BIP 347) have been debated for years. Slow, careful change is a feature for a money people rely on.