How Bitcoin works: the technology

Date: 2026-10-09. Type: study notes, research not advice. Nothing here suggests buying, selling or holding anything. No keys, seed phrases or wallet data appear here; the BIP 39 word list saved under sources/bips/ is the public dictionary only.

How to read this. Each section starts with In plain language and then gives Technical detail. Every claim carries a citation:

• [S#] refers to the numbered Sources list at the end of the note (title, issuer, URL, date read).
• [BIP n] refers to a full saved copy in ../sources/bips/. BIPs 16, 34, 43, 44, 68 and 101 have no licence line, so they are linked on GitHub rather than copied. The index explains why.
• (unverified) marks something I could not check against a source today.
• Contested marks claims that one side disputes. Both sides' versions are given.
• Figures marked (computed) are my own arithmetic from the cited source data. The method is shown.

Related notes written in parallel by other researchers: the origins timeline, who Satoshi is, books, wallets (market/2026-10-09-wallets.md), and the hacks sources in sources/hacks/ (exchange and custody thefts). This note covers the protocol itself, and the bugs and attacks at the protocol level.

---

Snapshot: the network on 2026-10-09

Measure	Value	Source
Block height (chain tip when read on 2026-10-09)	970,681	[S6]
Genesis block	2009-01-03 18:15:05 UTC	[S6]
New coins per block (subsidy)	3.125 BTC since block 840,000 (2024-04-20)	[S4][S6]
Coins issued by the schedule up to the tip	≈ 20,095,881 BTC, about 95.7% of the 20,999,999.9769 BTC maximum (computed with Bitcoin Core's subsidy formula)	[S4]
Next halving	Block 1,050,000, which is 79,319 blocks away. At this epoch's 9.65-minute average that falls around 2028-03-24; at exactly 10 minutes, 2028-04-12 (computed estimate)	[S6]
Difficulty	≈ 132.7 trillion. Last retarget 2026-10-03 (−0.03%). Next at block 971,712, estimated around 2026-10-16 at about +3.7%	[S6]
Hashrate	Roughly 950–990 EH/s (mempool.space estimates over 1 month)	[S6]
Mining pools, last month (4,411 blocks)	Foundry USA 25.4%, AntPool 20.3%, F2Pool 15.8%, ViaBTC 9.3%, SpiderPool 7.8%, MARA 5.0%, SECPOOL 4.1%, Luxor 3.1%, OCEAN 2.7%, Braiins 1.5%	[S6]
Reachable full nodes	25,490, of which 49% are on Tor. User agents: 83.4% Bitcoin Core ("Satoshi"), 16.3% Bitcoin Knots. 86 nodes (0.34%) still advertise BIP-110	[S7]
Latest releases	Bitcoin Core v31.1 (2026-07-08). Bitcoin Knots v29.4.2.knots20260508 (2026-09-21)	[S22]
Lightning (public channels only)	1ML: 2,615.64 BTC capacity, 5,917 nodes, 19,770 channels (read 2026-10-09). mempool.space: 4,898 BTC, 17,438 nodes, 41,080 channels, but its newest data point is dated 2026-05-22. The two trackers count differently, and neither sees private channels	[S8]
Disk space Bitcoin Core assumes for the full chain	897 GB (m_assumed_blockchain_size, a built-in estimate rather than a measurement)	[S2]

---

1. The problem Bitcoin solves

In plain language. Digital files can be copied, so the hard part of digital cash is stopping someone from spending the same coin twice. Banks solve that by keeping the ledger. Bitcoin instead has thousands of computers each keep a copy of one public ledger. The order of transactions is fixed by a chain of blocks that takes real computing work to produce, so rewriting history costs more than it could earn.

Technical detail. - The whitepaper defines a coin as "a chain of digital signatures" (§2). It proposes a "peer-to-peer distributed timestamp server" (§1, detailed in §3) built on proof of work (§4). The system "is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes" (abstract). Proof of work "is essentially one-CPU-one-vote" (§4) [S1]. - The genesis block was mined on 2009-01-03. Its coinbase carries the text "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks". Its 50 BTC output is pay-to-public-key (P2PK) [S6]. That output cannot be spent: BIP 42 notes "the genesis coinbase output, which is not actually spendable" [BIP 42].

2. Blocks and proof of work

In plain language. A block is a batch of transactions plus a short header. To add a block, a miner must find a header whose fingerprint (hash) is below a target number. The only way to find one is to try enormous numbers of guesses. Each header contains the fingerprint of the block before it, so the blocks form a chain. Changing an old block means redoing its work and the work of every block after it. Nodes follow the valid chain that took the most work to build.

Technical detail. - Header: 80 bytes, holding the version, the previous block's hash, the merkle root of the block's transactions, the time, the target in compact form (nBits) and a nonce. All hashes are SHA256(SHA256()). The time must be greater than the median of the previous 11 blocks. Nodes reject headers more than two hours in the future [S11b]. - Chain choice: peers "follow the most difficult chain to recreate" and drop stale blocks [S11c]. The whitepaper calls this "the longest chain" [S1]. - Size limit: since SegWit the limit is block weight ≤ 4,000,000 [S5][BIP 141]. For example, block 840,000 (the 2024 halving) was 2,325,617 bytes at weight 3,993,281 [S6]. - Coinbase maturity: new coins cannot be spent for 100 blocks [S5][S11c]. - Confirmations: the whitepaper (§11) shows an attacker's chance of catching up shrinks exponentially with the number of blocks z built on top. With 10% of the hashpower (q = 0.1), the chance is 0.0009 at z = 5 and 0.0002 at z = 6. With 30% (q = 0.3), it is still 0.177 at z = 5 [S1].

3. Difficulty adjustment

In plain language. Every 2,016 blocks (about two weeks), every node checks how long those blocks took. It then moves the target so blocks keep arriving about every 10 minutes, however much mining equipment is switched on or off. Each adjustment is capped at a factor of four in either direction.

Technical detail. - The parameters are nPowTargetTimespan = 14 days and nPowTargetSpacing = 10 minutes [S2]. The new target is the old target × (actual time ÷ 14 days), clamped between ¼ and 4× [S3]. The whitepaper describes this as "a moving average targeting an average number of blocks per hour" [S1]. - The timewarp bug: the code measures from the first to the last block of the period ("Go back by what we want to be 14 days worth of blocks", nHeight - (2016-1)) [S3]. Combined with loose timestamp rules, this lets a majority-hashrate attacker push difficulty down. BIP 54 says: "In the worst case, an attacker can bring down the difficulty to its minimum within 38 days." BIP 54 (Consensus Cleanup) would fix it by constraining timestamps at period boundaries. Its status is Complete, which means not deployed [BIP 54]. Bitcoin Core 30.0 already made one BIP 54 rule (a 2,500 signature-operation cap) standard relay policy "to prepare for a possible BIP54 deployment" [S20]. - Live example: blocks have averaged 9.65 minutes this period, so the next retarget is estimated at about +3.7% [S6]. - Why minority forks stall: a split-off chain inherits the main chain's difficulty. With little hashpower it must still mine 2,016 blocks before difficulty can fall. That is why the August 2026 BIP-110 chain stopped after two blocks; a monitor cited by CoinDesk put its next retarget about 350 days away [S46][S47] (§15). Bitcoin Cash added an "Emergency Difficulty Adjustment" in 2017 for the same reason, then replaced it on 2017-11-13 with a per-block adjustment over the last 144 blocks [S24].

4. The UTXO model

In plain language. Bitcoin does not keep account balances. It keeps a list of unspent "coins" called outputs. Spending consumes whole coins and creates new ones, much like paying with banknotes and getting change. A wallet's "balance" is the total of the outputs it can unlock. Whatever the inputs hold beyond the outputs is left for the miner as the fee.

Technical detail. - Every transaction has at least one input and one output. An input points at an earlier output by its txid and output index ("vout"). An output holds an amount in satoshis and a locking script (scriptPubKey). "When your Bitcoin wallet tells you that you have a 10,000 satoshi balance, it really means that you have 10,000 satoshis waiting in one or more UTXOs" [S9]. - The full value of the inputs "must be spent or given to a miner as a transaction fee". Most transactions therefore include a change output [S9]. Fees are priced per byte, now per virtual byte, by demand for block space [S9][BIP 141]. - Fee bumping: an unconfirmed transaction can be replaced by a higher-fee version. BIP 125 defined opt-in signalling for this [BIP 125]. Bitcoin Core 28.0 (2024-10-05) made "full RBF" the default (mempoolfullrbf=1), so signalling is no longer needed on default nodes [S20b]. Since Core 31's cluster mempool, a replacement is accepted only if it makes the mempool's "feerate diagram" strictly better [S21]. - The coinbase is the first transaction in each block. It creates the subsidy plus the fees [S1 §6][S4]. - Duplicate transaction IDs: early coinbases could repeat, which allowed outputs to be overwritten. BIP 30 bans a new transaction from reusing the txid of one with unspent outputs, and grandfathers two historic violations at heights 91,842 and 91,880 [BIP 30]. BIP 34 forced block heights into coinbases [BIP 34 (link)]. BIP 54 would close the last gap, which reopens at height 1,983,702 [BIP 54]. (The coins lost in those two old duplicates are usually given as 2 × 50 BTC (unverified).) - Privacy: every amount and link between transactions is public. The whitepaper advises that "a new key pair should be used for each transaction", and notes that multi-input transactions still link owners [S1 §10].

5. Script

In plain language. Every coin is locked by a small program that says what is needed to spend it. Usually that is "a valid signature from key X". It can also be "2 of these 3 signatures", "not before a given date" or "whoever reveals a secret". The language is deliberately limited, with no loops, so every node can check it quickly and get the same answer.

Technical detail. - "The script language is a Forth-like stack-based language deliberately designed to be stateless and not Turing complete" [S9]. In a standard pay-to-pubkey-hash (P2PKH) spend, the spender supplies <sig> <pubkey> and the lock is OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG [S9]. - Early design flaws: - CVE-2010-5141 (2010-07-28): OP_RETURN "could be used to spend any output" [S10]. BIP 342 calls it "one of a major design flaws in the original bitcoin protocol as it permitted unconditional third party theft" [BIP 342]. - On 2010-08-25 Satoshi's "misc changes" commit disabled OP_CAT and 15 other opcodes. BIP 347 notes that, by folklore, OP_CAT could cause memory use exponential in script size [BIP 347]. - Features added later by soft fork: - Pay-to-script-hash (P2SH, addresses starting 3), enforced from 2012-04-01 [BIP 16 (link)]. - Absolute timelock OP_CHECKLOCKTIMEVERIFY, active at block 388,381 on 2015-12-14 [BIP 65][S2][S6]. - Relative timelocks (BIPs 68, 112, 113), active at block 419,328 on 2016-07-04 [BIP 112][BIP 113][S2][S6]. - Upgrade hooks: SegWit witness versions [BIP 141] and Tapscript OP_SUCCESSx opcodes [BIP 342]. - Consensus versus policy. Consensus rules decide which blocks are valid, and every node must agree on them. Policy (also called "standardness") is each node's own choice of which unconfirmed transactions to relay or mine. Bitcoin Core 30.0 (2025-10-13) changed its policy defaults: - It raised -datacarriersize to 100,000, which "effectively uncaps" OP_RETURN data. It had been 83 bytes before. - It allowed several OP_RETURN outputs per transaction [S20][S22].

This policy change sits at the centre of the 2025–26 data-embedding dispute (§15). BIP 110's motivation objects to "standardizing support for arbitrary data" [BIP 110]. - Proposed, not active: OP_CHECKTEMPLATEVERIFY (BIP 119, Draft), OP_CAT in Tapscript (BIP 347, Complete) and a list of other covenant opcodes. All appear in the BIP index as Draft or Complete. None is deployed [BIP 119][BIP 347][S12].

6. Keys, signatures and addresses

In plain language. A private key is a very large random number. From it you compute a public key, and a signature proves you know the private key without revealing it. An address is a short text encoding, with a checksum, of what a coin is locked to: usually a hash of a public key or of a script. Each upgrade brought its own address format, so the first characters tell you which kind it is. Anyone who learns a private key or seed controls the coins, which is why this repo stores none.

Technical detail. - Curve: secp256k1. Signatures were ECDSA, plus Schnorr since Taproot [S9][BIP 340]. ECDSA signatures are DER-encoded, variable length and up to 72 bytes. Schnorr signatures are a fixed 64 bytes with 32-byte "x-only" public keys [BIP 340]. - Encodings: - Legacy addresses use Base58Check. - SegWit v0 addresses use Bech32 [BIP 173]. - v1+ addresses (Taproot) use Bech32m. The switch was made because Bech32 has a weakness: "whenever the final character is a 'p', inserting or deleting any number of 'q' characters immediately preceding it does not invalidate the checksum" [BIP 350].

Type	Looks like	Since	What it locks to	Spec
P2PK	(no address; raw public key in the script)	2009	a public key, exposed on-chain	genesis output [S6]
P2PKH	1…	2009	hash of a public key	[S9]
P2SH	3…	2012	hash of a script (multisig and others)	[BIP 16 (link)]
P2SH-wrapped SegWit	3…	2017	SegWit program inside P2SH, for old wallets	[BIP 141][BIP 49]
P2WPKH	bc1q… (42 characters)	2017	hash of a public key, SegWit v0	[BIP 141][BIP 173]
P2WSH	bc1q… (62 characters)	2017	SHA-256 of a script, SegWit v0	[BIP 141][BIP 173]
P2TR	bc1p… (62 characters)	2021	tweaked Schnorr key, SegWit v1	[BIP 341][BIP 350]
P2A (anchor)	a fixed short bc1p…	standard policy since Core 28.0 (2024-10)	key-less anyone-can-spend output for fee bumping	BIP 433, Draft [S12][S20b]
P2MR (proposed)	—	not active	Taproot-like script tree with no key path (quantum hedge)	[BIP 360] Draft

7. HD wallets: one backup for every key (BIP 32/39/44)

In plain language. Modern wallets do not back up each key separately. They derive every key from one master secret, which is shown to the user as 12 or 24 words: the "seed phrase". Anyone with those words controls the coins. An optional passphrase can be added, sometimes called a 25th word. Standard "paths" let different wallet programs find the same addresses from the same words.

Technical detail. - BIP 32 (assigned 2012-02-11) derives a tree of keys from a seed. "Hardened" children need the parent private key; normal children can be derived from an extended public key (xpub). An xpub can therefore watch a wallet without being able to spend from it. BIP 32's own warning: "knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key" [BIP 32]. - BIP 39 (assigned 2013-09-10) turns 128–256 bits of entropy plus a checksum (ENT/32 bits) into 12–24 words from a 2,048-word list. The seed is PBKDF2-HMAC-SHA512 with 2,048 iterations, using "mnemonic" + passphrase as the salt [BIP 39]. The English list is saved at ../sources/bips/bip-0039/english.txt. - BIP 44 sets the path m / purpose' / coin_type' / account' / change / address_index [BIP 44 (link)]. Purpose numbers mark the address type: - 49' for P2SH-wrapped SegWit [BIP 49] - 84' for native SegWit, for example m/84'/0'/0'/0/0 for the first receiving address [BIP 84] - 86' for single-key Taproot [BIP 86] - PSBT (BIP 174) is the standard file format for passing an unsigned or partly signed transaction between wallets and hardware signers [BIP 174]. - Key-generation failures, such as the 2013 Android random-number flaw, are covered in §17 and in the wallets note.

8. SegWit (BIP 141, 143, 144, 147)

In plain language. SegWit, activated in August 2017, moved signatures (the "witness") into a separate part of the transaction. That had two effects:

• It fixed a long-standing problem where anyone could alter a transaction's ID before it confirmed ("malleability"). Malleability had blocked protocols like Lightning that chain unconfirmed transactions.
• It raised capacity by counting witness bytes at one quarter of the weight of other bytes.

Old nodes still accept SegWit blocks, which is what makes it a soft fork.

Technical detail. - Weight: weight = base size × 3 + total size. The rule is block weight ≤ 4,000,000. Virtual size = weight ÷ 4. BIP 141 explains why a single combined limit was chosen over two separate ones [BIP 141]. - Malleability: the txid leaves out the witness, so third parties can no longer change a SegWit input's txid. BIP 141 discusses why this matters for payment channels [BIP 141]. BIP 147 removes one further source of malleability, the CHECKMULTISIG dummy element [BIP 147]. - BIP 143 created a new signature hash. It fixes O(n²) hashing; in 2015 "a 1MB transaction with 5569 sigops may take 25 seconds to verify" (CVE-2013-2292). It also makes signatures commit to input amounts, so an offline hardware wallet can safely compute fees [BIP 143]. - BIP 144 covers the peer-to-peer changes [BIP 144]. - Witness versions 0–16 let future upgrades add output types. Version 1 became Taproot [BIP 141][BIP 341]. - Deployment: BIP 9 version bit 1, signalling window 2016-11-15 to 2017-11-15, 95% threshold [BIP 91][S23]. - Locked in at block 479,808 (2017-08-09). - Active at block 481,824 (2017-08-24) [S2][S6][S23]. - How the activation was fought over is told in §16.

9. Taproot (BIP 340, 341, 342)

In plain language. Taproot, activated in November 2021, brought Schnorr signatures and a new output type. A coin can be locked to one key that quietly commits to a tree of alternative spending scripts:

• If all parties agree, the spend looks like an ordinary single-signature payment: smaller, cheaper and more private.
• If they do not agree, only the branch actually used is revealed.

Technical detail. - BIP 340: 64-byte Schnorr signatures, 32-byte x-only keys, and tagged hashes. Schnorr signatures can be verified in batches [BIP 340]. - BIP 341: a witness-v1 output is a 32-byte tweaked key. It can be spent two ways: - by key path, with a single signature; - by script path, revealing one leaf of a Merkle tree plus a control block.

BIP 341 recommends a provably unspendable "NUMS" internal key when no key path is wanted [BIP 341]. - BIP 342 (Tapscript): signature checks use Schnorr. A new OP_CHECKSIGADD replaces CHECKMULTISIG so that multisig can be batch-verified. OP_SUCCESSx opcodes are reserved for future soft forks. The leaf version is 0xc0 [BIP 342]. - Activation ("Speedy Trial", a BIP 9 variant) [BIP 341]: - threshold 90% (1,815 of 2,016 blocks); - start 2021-04-24, timeout 2021-08-11; - min_activation_height 709,632.

It locked in the weekend before 2021-06-16 [S45] and activated at block 709,632 on 2021-11-14 [BIP 341][S6]. A user-activated alternative, BIP 343, is Closed [BIP 343]. - Side effects (contested): - Taproot's script path and the witness discount made cheap large data pushes possible. They were later used for "inscriptions" (Ordinals). BIP 110's authors treat this as an abuse to be resisted; opponents call it paid use of block space [BIP 110][S46][S47]. - Key-path outputs put a public key on-chain, which matters for quantum risk (§17). BIP 360 (P2MR, Draft) proposes Taproot without the key path [BIP 360].

10. The Lightning Network

In plain language. Lightning is a payment layer on top of Bitcoin:

• Two parties lock coins in a shared 2-of-2 output on the blockchain.
• They then swap signed but unbroadcast transactions that update who owns what. They can do this any number of times, instantly.
• A payment can hop across a chain of such channels.
• Only opening, closing or a dispute touches the blockchain.

The trade-offs:

• You, or a third party you delegate to (often called a "watchtower"), must watch the blockchain to catch a counterparty publishing an old channel state.
• Routing nodes keep keys online in a "hot wallet".
• A channel can only move the funds locked in it.
• Payments can fail to find a route.
• The extra complexity has produced real security bugs.

The first two points come from the original paper: "one should periodically monitor the blockchain ... or delegate a third party to do so", and intermediary nodes "should not be holding a substantial amount of money in this 'hot wallet'" [S39]. The bugs are in the technical detail below [S41].

Technical detail. - Origin: Poon and Dryja, draft v0.5.9.2 (2016-01-14), propose "a network of micropayment channels" whose transfers are enforceable on-chain "through a series of decrementing timelocks". They note this needs a fix for malleability [S39]. Payments are routed with hash time-locked contracts (HTLCs), whose timeouts are spaced by a cltv_expiry_delta between hops [S41]. They rely on Script's timelock opcodes [BIP 65][BIP 112] and on SegWit's malleability fix [BIP 141]. - Software: the spec is a set of documents called the BOLTs. There are four main implementations: LND, Core Lightning, Eclair and LDK [S41]. - Size: public capacity is about 2,600–4,900 BTC depending on the tracker. That is ≈ 0.01–0.02% of issued supply (computed). Trackers disagree, and private channels are invisible [S8]. - Security, replacement cycling (CVE-2023-40231/2/3/4, disclosed 2023-10-16): - An attacker uses the rules for replacing unconfirmed transactions to stop a routing node's timeout transaction from confirming, and can then take the funds in transit. - Mitigations shipped in LDK 0.0.118, Eclair 0.9.0, LND 0.17.0-beta and Core Lightning 23.08.01. - The reporter said it was "yet to be determined" whether those mitigations hold against advanced attackers [S41]. - Mempool changes that affect Lightning: Bitcoin Core 31.0 rebuilt the mempool ("cluster mempool") and removed the "CPFP carve-out" that Lightning anchor outputs had relied on. Contract protocols are now told to use TRUC transactions and sibling eviction [S21].

11. Mining, pools, ASICs (and the ASICBoost patents)

In plain language. Mining means hashing. It moved through four kinds of hardware:

• CPUs (2009)
• graphics cards (2010)
• FPGAs (2011)
• ASICs (from 2013): chips that do nothing but Bitcoin's hash, now vastly more efficient

Finding a block alone is a lottery, so most miners join pools that pay them small, steady amounts. The pool, not the individual miner, usually decides which transactions go in the block, which is a centralisation concern.

Technical detail. - Hardware eras (Taylor, IEEE Computer, 2017) [S33]: - first CUDA GPU miner September 2010, with an OpenCL one a month later; - pooled mining November 2010; - first open-source FPGA miner June 2011; - first ASIC January 2013, on a 130 nm process; - 16 nm by mid-2015; - in 2017 BitFury miners exceeded "0.07 W per GH/s" (≈ 70 J/TH), "100 times more energy efficient than the first 130-nm ASIC miners and 8,000 times more energy efficient than GPU miners". - Today's hardware: a retailer lists Bitmain's Antminer S23 Hydro 3U at 1,160 TH/s and 11,020 W, which is ≈ 9.5 J/TH (computed). This is a seller's spec sheet and is not independently verified [S38]. - Pools: a pool counts "shares", which are proofs of lower difficulty, to measure each miner's work. Payout methods include PPS (Pay-per-Share), FPPS (which also shares fees) and score-based schemes such as the original "slush's pool" method [S34]. - Concentration: over the last month the top three pools found 61.5% of blocks (computed from [S6]). In 2024 the researcher b10c observed that AntPool, BTC.com, Binance Pool, Poolin, EMCD, Rawpool and "possibly Braiins" sent miners identical block templates. That suggests real concentration is higher than pool names show. It is an observation of template data, not proof of common ownership [S35]. - Giving miners back control of templates: Stratum V2 encrypts miner-to-pool traffic and lets miners build their own templates [S36]. Ocean's DATUM has the same aim [S37]. During the August 2026 BIP-110 split, Ocean said some miners using its templates had unknowingly mined on the BIP-110 chain, and it reimbursed them [S47]. - ASICBoost and its patents: - What it is: a mining shortcut, "a speedup ... by a factor of approximately 20%", that reuses part of the SHA-256 work across header variants [S30]. - Patents: - US 11,113,676 B2, "Block mining methods and apparatus". Inventors Timo Hanke and Sergio Demian Lerner; priority 2013-11-19; filed 2016-04-28; granted 2021-09-07. Assigned in turn to Sunrise Tech Group (2016), Little Dragon Technology (2017), Top Galore (2018) and Circle Line International (2021). Google Patents shows "Active, expires 2036-04-16" with a "family has litigation" flag; Google's status is an assumption, not a legal finding [S31]. - Bitmain's Chinese patent CN105245327A covers the same idea. Priority 2015-08-21; listed inventors include Zhan Ketuan and Wu Jihan [S32]. - Contested: - Gregory Maxwell (2017-04-05) said covert ASICBoost is incompatible with SegWit. He wrote that "reverse engineering of a particular mining chip has demonstrated conclusively that ASICBOOST has been implemented", and proposed blocking the covert form [S28]. - Bitmain replied that its chips support ASICBoost and that it holds the Chinese patent, but that it "has never used ASICBOOST on the mainnet". It called the allegation political [S29]. - No public proof either way was found for this note (unverified). The open "version-rolling" form uses header version bits; see draft BIP 320 in the BIP index [S12].

12. Halvings and the supply schedule

In plain language. New bitcoins come only from block rewards. The reward started at 50 BTC and halves every 210,000 blocks, roughly every four years. There have been four halvings, and the reward is now 3.125 BTC. Total supply creeps towards just under 21 million, with the last fraction issued around the year 2140. Some coins can never be spent (the genesis reward) and an unknown number are lost.

Technical detail. - The formula: nSubsidy = 50 * COIN; nSubsidy >>= halvings with halvings = height / 210000. The reward is forced to zero once halvings >= 64 [S4]. - BIP 42: it was written as an April Fools' text but carries a real fix. Shifting by 64 or more bits was undefined behaviour in C++. On common platforms it would have restarted the 50 BTC reward every 64 halvings. The fix makes supply finite [BIP 42]. - The cap: because satoshis are whole numbers, the maximum is 20,999,999.9769 BTC (computed; Wikipedia gives the same figure for Bitcoin Cash, which shares the schedule) [S4][S24]. - The reward reaches 0 sat at the 33rd halving, block 6,930,000, so the last subsidised block is 6,929,999 (computed). - MAX_MONEY = 21,000,000 BTC is only a sanity bound used in validation [S5].

Halving	Block	Date (UTC, block timestamp)	Reward
1	210,000	2012-11-28 15:24	50 → 25
2	420,000	2016-07-09 16:46	25 → 12.5
3	630,000	2020-05-11 19:23	12.5 → 6.25
4	840,000	2024-04-20 00:09	6.25 → 3.125
5	1,050,000	est. late March to mid April 2028 (computed)	3.125 → 1.5625

Sources: [S6] for timestamps, [S4] for the rewards.

• Issued versus spendable: the schedule has issued ≈ 20,095,881 BTC up to block 970,681 (computed [S4]). Spendable supply is lower, for four reasons:
• the unspendable genesis output [BIP 42];
• the duplicated early coinbases [BIP 30];
• miners who claimed less than the full reward (unverified size);
• lost keys (unknown).
• Long-run security: the whitepaper expects that "once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees" [S1 §6]. Whether fees will be enough is an open question.

13. Node software

In plain language. A full node downloads every block and checks it against the rules itself, so it does not have to trust anyone. Most people run Bitcoin Core. About one reachable node in six runs Bitcoin Knots, which is built from Core. Its community backed BIP 110 [S47], and it is widely described as filtering data-carrying transactions more strictly by default, though that was not checked against its documentation here (unverified). Smaller implementations exist in Go, Rust, C++ and JavaScript. Light wallets check less and trust more.

Technical detail. - Bitcoin Core is the reference implementation, released under the MIT licence [S2]. - Releases (GitHub release dates) [S22]: - v30.0, 2025-10-13. Core's own advisories date it 2025-10-10 [S18]. - v31.0, 2026-04-20. - v31.1, 2026-07-08. - Older lines also get maintenance releases: v30.3 and v29.4 in July 2026. - Notable features: - compact block relay [BIP 152] - compact block filters for light clients [BIP 157][BIP 158] - encrypted v2 P2P transport [BIP 324] - the cluster mempool in 31.0 [S21] - assumeutxo snapshot data in the mainnet parameters [S2] - Version mix among reachable Core nodes: 31.x 8,961; 29.x 4,290; 27.x 1,957; 28.x 1,882; 30.x 1,527 [S7]. The low count for 30.x is sometimes read as operators avoiding the 30.0 OP_RETURN change. That reading is unverified. - Bitcoin Knots is a Core derivative run by 4,166 reachable nodes (16.3%) [S7]. The latest release is v29.4.2.knots20260508 [S22]. BIP 110 credits "Luke-Jr" with its original draft, and its reference implementation is a Knots branch [BIP 110]. - Other implementations (GitHub, read 2026-10-09) [S48]:

Software	Language	Licence	Latest release	Notes
btcd	Go	ISC	v0.26.2 (2026-07-24)	full node
utreexod	Go	ISC	v0.6.0 (2026-06-23)	full node using Utreexo accumulators instead of storing the UTXO set
Floresta	Rust	not asserted	v0.9.1 (2026-04-27)	"lightweight and embeddable Bitcoin client"
libbitcoin-server	C++	not asserted	v3.8.0 (2023-08-18)	commits active in 2026
bcoin	JavaScript	not asserted	v2.2.0 (2021)	last push February 2024; effectively dormant
Peter Todd's fork (petertodd/bitcoin)	—	MIT	no releases	the relay-policy variant called "Libre Relay" (unverified description)

• Caveats on node counts: only reachable, listening nodes are counted. Nodes that do not accept incoming connections are invisible. User agents are self-reported and can be faked [S7].
• Why diversity cuts both ways: more implementations mean less dependence on one codebase. But if they disagree on any consensus edge case, the chain splits. The 2013 split happened between two versions of the same software [BIP 50].

14. How the rules change: soft forks, hard forks, activation

In plain language.

• A soft fork tightens the rules. Old nodes still see new blocks as valid, so people can upgrade gradually.
• A hard fork loosens or changes the rules. Old nodes reject the new blocks, so there is a permanent split unless everyone upgrades.

Who "decides" is itself disputed:

• Miners signal readiness, but full nodes enforce the rules.
• Many argue the "economic majority" (exchanges, merchants, holders) settles which chain is "Bitcoin".

Technical detail: activation methods over time.

Method	Used for	How it worked	Source
Flag day by timestamp	P2SH	enforced from 2012-04-01	[BIP 16 (link)]
"IsSuperMajority"	BIPs 34, 66, 65	75% and then 95% of the last 1,000 block versions. Now "buried" as fixed heights: 227,931, 363,725 and 388,381	[BIP 90][S2]
BIP 9 version bits	CSV (bit 0, 2016) and SegWit (bit 1, 2017)	95% of a 2,016-block period, with a timeout	[BIP 9][BIP 113][BIP 141]
BIP 8	proposals	lock-in by height, with optional mandatory signalling	[BIP 8]
BIP 148	the 2017 SegWit "UASF" (user-activated soft fork)	user-activated mandatory signalling from 2017-08-01. A later fallback, BIP 149 (BIP 8 lock-in by 2018-07-04 if SegWit had failed by 2017-11-15), was never needed and is Closed	[BIP 148][BIP 149]
BIP 91	SegWit (via SegWit2x miners)	80% signalling in 336-block windows	[BIP 91]
"Speedy Trial"	Taproot	90%, with a minimum activation height	[BIP 341]
BIP 110's modified BIP 9	BIP 110	55% threshold, mandatory signalling, rules that expire after a year	[BIP 110]

The BIP process itself (now governed by BIP 3 [BIP 3]) takes no position on whether a proposal is a good idea. "Acceptance and adoption rests with the Bitcoin users" [S12]. BIP 2 (not saved) says a hard fork "requires adoption from the entire Bitcoin economy" (https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki).

15. Fork and incident timeline

Date (UTC)	Height	Event	Kind	Source
2010-07-15	—	Satoshi adds MAX_BLOCK_SIZE = 1000000 in commit a30b56eb. The commit message does not mention it	consensus limit	[S14][S13]
2010-07-28	—	CVE-2010-5141: OP_RETURN spend-anything bug fixed	theft bug	[S10]
2010-08-15	74,638	Value-overflow incident: a transaction creates 184,467,440,737 BTC. A fixed client ships within about 5 hours (soft fork). The good chain overtakes at 74,691	inflation bug	[S11][S10]
2010-08-25	—	OP_CAT and 15 other opcodes disabled	soft fork	[BIP 347]
2010-10-04	—	Satoshi: a larger block limit "can be phased in, like: if (blocknumber > 115000) maxblocksize = largerlimit"	forum post	[S15]
2012-04-01	—	P2SH enforced	soft fork	[BIP 16 (link)]
2013-03-11	—	Accidental split (CVE-2013-3220): v0.8 accepts a block that pre-0.8 nodes reject because of a Berkeley DB lock limit. The 0.8 side has ≈ 60% of hashpower. Pools downgrade to end it. At least one (experimental) double spend. The forking block's height is not in these sources (unverified)	unplanned hard fork	[BIP 50][S10]
2013-03-25	227,931	BIP 34 (height in coinbase) enforced	soft fork	[S2][S6][BIP 90]
2013-05	—	A planned change removes the hidden lock limit. From then on the 1 MB limit becomes the effective cap (the Bitcoin Wiki says "cleanly activated"). Exact date unverified	planned hard fork	[S13][BIP 50]
2015-07-04	363,725	BIP 66 (strict DER) enforced. A non-upgraded miner makes an invalid block. "Roughly half the network hash rate" was SPV-mining (building on blocks without checking them) and extends it, giving forks of 6 blocks (4 July) and 3 blocks (5 July)	soft-fork incident	[S16][S2]
2015	—	Bitcoin XT (BIP 101: 8 MB, doubling). Never activated, now Closed	proposed hard fork	[BIP 101 (link)][S25]
2015-12-14	388,381	BIP 65 CLTV	soft fork	[S2][S6]
2016-02	—	"Hong Kong Agreement": some miners and developers back SegWit plus a 2 MB hard fork. Timelines missed	agreement	[S25][S29]
2016	—	Bitcoin Classic (BIP 109, 2 MB). Never activated, now Closed	proposed hard fork	[BIP 109][S25]
2016-07-04	419,328	CSV (BIPs 68/112/113)	soft fork	[S2][S6]
2016-11-15	—	SegWit BIP 9 signalling opens	activation	[BIP 91][S23]
2017-04-05	—	Maxwell's covert-ASICBoost post; Bitmain rebuts	dispute	[S28][S29]
2017-05	—	"New York Agreement" (SegWit2x): SegWit at 80%, then a 2 MB hard fork within six months	agreement	[S23]
2017-07-21	476,784	BIP 91 locks in: 284 of the 336 blocks in 476,448–476,783 (84.5%) signalled bit 4. Active at 477,120 (2017-07-23)	soft fork (miner)	computed from block headers [S6]; [BIP 91]
2017-08-01	478,558 / 478,559	BIP 148 "UASF" date. Bitcoin Cash splits off: last common block 478,558; first BCH block 478,559	hard fork (new coin)	[BIP 148][S24][S6]
2017-08-09	479,808	SegWit locked in	soft fork	[S23][S6]
2017-08-24	481,824	SegWit active	soft fork	[S2][S6][S23]
2017-10-24	—	Bitcoin Gold splits off (Equihash proof of work)	hard fork (new coin)	[S27]
2017-11-08	—	SegWit2x hard fork cancelled "due to a lack of consensus"	cancelled	[S23][S25]
2017-11-13	—	BCH replaces its emergency difficulty rule	BCH hard fork	[S24]
2018-05	—	Bitcoin Gold 51% attack: ≈ 388,000 BTG (≈ $18M) double-spent against exchanges	attack (not BTC)	[S27]
2018-09-17	—	CVE-2018-17144: a duplicate-input bug lets a miner inflate supply in 0.15–0.16.2. Fixed in 0.16.3; no exploitation known	inflation bug	[S17]
2018-11-15	—	BCH splits into BCH (ABC) and BSV (Craig Wright / Calvin Ayre camp)	hard fork	[S26]
2020-11	—	BCH splits again (ABC → eCash/XEC)	hard fork	[S24]
2021-06-12 (weekend)	—	Taproot locked in	soft fork	[S45]
2021-11-14	709,632	Taproot active	soft fork	[BIP 341][S6]
2021-06 to 08	—	BSV hit by repeated 51% attacks	attack (not BTC)	[S26]
2023-10-16	—	Lightning "replacement cycling" CVEs disclosed	L2 vulnerability	[S41]
2025-10-13	—	Bitcoin Core 30.0: OP_RETURN policy relaxed; 2,500-sigop policy cap	policy	[S20][S22]
2025-10-24	—	BIP 110 (Reduced Data Temporary Softfork) first drafted	proposal	[BIP 110]
2025-12-01	—	BIP 110 signalling starts (bit 4, 55%, mandatory window before block 963,648)	activation attempt	[BIP 110]
2026-04-20	—	Bitcoin Core 31.0 (cluster mempool)	release	[S21][S22]
2026-05-05	—	CVE-2024-52911 disclosed: a use-after-free remote crash in 0.14–28.x, fixed in 29.0	DoS bug	[S19]
2026-08-08 (Sat)	961,632	BIP-110 chain split. BIP-110 nodes reject non-signalling blocks. AntPool mines the first non-signalling block. A group using Ocean's DATUM ("Roughnecks") mines 961,632 and 961,633 on the BIP-110 side, then stops. Only 51 of 2,016 blocks (2.53%) of the prior period signalled. Michael Saylor put the share of hashpower staying on the main chain at 99.85% (his figure, as reported)	failed soft fork / chain split	[S46][S47]
2026-08-09	—	BIP 110 marked Closed "following a chain split with stalled mining"	proposal closed	[BIP 110]
2026-09	—	Reports that the BIP-110 fork restarted with ~300 kB blocks (headline only; article blocked)	minority chain	[S49] (unverified)
2026-10-09	—	BIP 54 (timewarp, slow-block, 64-byte transaction and BIP 30 fixes) is Complete, not deployed	pending soft fork	[BIP 54]

16. The block-size dispute (2015–2017) and Bitcoin Cash

In plain language. From about 2015 the community split over how Bitcoin should grow.

• "Big blockers" wanted to raise the 1 MB block limit so more transactions fit on-chain and fees stayed low.
• "Small blockers" wanted to keep blocks small so ordinary people could afford to run full nodes. They preferred to scale with efficiency upgrades (SegWit) and layers on top (Lightning).

The fight ran through several rounds:

• rival node software: Bitcoin XT, Classic and Unlimited;
• industry deals: Hong Kong in 2016, New York in 2017;
• a user-activated soft-fork threat, BIP 148;
• a miner compromise, BIP 91, which activated SegWit in August 2017.

On 1 August 2017, big-block supporters split off as Bitcoin Cash. The 2 MB hard-fork half of the New York deal (SegWit2x) was dropped in November 2017.

Technical detail and each side's case. - The origin of the limit: Satoshi added the 1 MB constant in July 2010 [S14]. The Bitcoin Wiki says the real limit until 2013 was a forgotten database-lock limit of "around 500-750k" bytes [S13]. - Big-block case: - Satoshi's October 2010 post said the limit "can be phased in" at a future block height [S15]. Big blockers read that as intent to raise it. - Higher fees and slow confirmations would hurt adoption [S13 lists these arguments]. - In April 2017 Bitmain accused Bitcoin Core of being "almost controlled by a small secretive committee". It called the removal of Gavin Andresen's commit access a "coup" and pledged to protect larger blocks "at any cost" [S29]. These are Bitmain's claims; Core developers dispute them (contested). - Small-block case: - Bigger blocks raise the cost of running a full node, push validation toward large companies, increase orphan rates, and weaken the fee market that must eventually replace the subsidy [S13]. - The Bitcoin Wiki argues Satoshi "spoke conditionally, not intentionally" [S13]. That page itself takes the small-block side. - What SegWit did for capacity: it raised effective capacity through the weight rule rather than the base size limit [BIP 141]. Block 840,000, for example, was 2.3 MB [S6]. - ASICBoost: whether some miners blocked SegWit because it would disable covert ASICBoost is contested (§11) [S28][S29]. - Who activated SegWit (contested): - The UASF side, here the Bitcoin Wiki, says miners "blocked" SegWit "for political reasons" and that BIP 148 "was ultimately successful" [S50]. - Others credit the miners' New York Agreement and BIP 91, which locked in on 2017-07-21, before BIP 148's 2017-08-01 date (computed from [S6]; [S23]). - Both happened, so the causal weight of each is a matter of interpretation. - Bitcoin Cash: - In June 2017 Bitmain called a big-block hard fork a "contingency plan". The first implementation was Bitcoin ABC, and ViaBTC proposed the name. - The fork came at block 478,559 on 2017-08-01, with larger blocks: 8 MB at launch, raised to 32 MB in 2018. - Its emergency difficulty rule caused instability and was replaced on 2017-11-13. - BCH then split twice more: BSV in 2018 and eCash in 2020 [S24][S26]. - Book-length accounts: Jonathan Bier, The Blocksize War (small-block view), and Roger Ver with Steve Patterson, Hijacking Bitcoin (big-block view). Neither was read for this note, and their bibliographic details are unverified; see the books note.

17. Protocol-level bugs and attacks: what caused them and how they are defended against

Most stolen bitcoin has been taken from exchanges, custodians or individuals through phishing, hot-wallet breaches and the like, not through flaws in the protocol. This is my synthesis and is not quantified here; the cases are collected in sources/hacks/. The table below covers the protocol and its software.

Incident or attack	What happened or could happen	Root cause	Defence or fix	Status	Source
Value overflow (2010)	184 billion BTC created	integer overflow when summing outputs	soft fork rejecting overflow and outputs above 21M; chain reorganised	fixed	[S11][S10]
OP_RETURN spend-anything (2010)	anyone could spend any coin	script semantics	OP_RETURN redefined; risky opcodes disabled	fixed	[S10][BIP 342][BIP 347]
Database-lock split (2013)	network split in two; a double spend	an undocumented database limit acted as a consensus rule	coordinated rollback; new limits; lesson: consensus code must be deterministic; businesses should run new code behind a node on the majority version	fixed	[BIP 50][S10]
Duplicate transactions (2012)	confirmed transactions reverted or overwritten	coinbases could repeat	BIP 30 and BIP 34; BIP 54 would finish the job	mostly fixed; BIP 54 pending	[BIP 30][BIP 54]
Merkle-tree weaknesses (CVE-2012-2459, CVE-2017-12842)	2012: a block hash collision via the merkle root (network-split risk). 2017: fake inclusion proofs fooling light (SPV) clients	2012: duplicated leaves give the same root. 2017: "no commitment to block merkle tree depth", so a 64-byte transaction can pose as an inner node	node checks; BIP 54 would make 64-byte transactions invalid	partly fixed; BIP 54 pending	[S10][BIP 54]
Quadratic signature hashing (CVE-2013-2292)	blocks that take minutes or hours to validate	legacy signature hash is O(n²)	BIP 143 for SegWit; BIP 54 sigop cap for legacy (already policy in Core 30)	fixed for SegWit; legacy pending	[BIP 143][BIP 54][S20]
SPV-mining forks (2015)	6-block invalid fork; light wallets showed false confirmations	miners built on blocks they had not validated	full validation; extra confirmations; run your own node	resolved	[S16]
Transaction malleability	txid changed before confirmation; Mt. Gox claimed (2014) it was drained this way	signatures did not cover themselves	BIP 66, BIP 147 and SegWit. Decker and Wattenhofer found "no widespread use of malleability attacks before the closure of MtGox" (contested cause of Mt. Gox losses)	fixed for SegWit inputs	[BIP 141][BIP 66][S42]
CVE-2018-17144	a miner could double-spend inside one block, inflating supply	an optimisation in 0.14 skipped a duplicate-input check	0.16.3 patch; quiet coordination with miners before full disclosure	fixed; no exploitation known	[S17]
Remote crashes and DoS (disclosed 2024–26)	nodes crashed or stalled remotely	memory-safety and resource bugs, e.g. a use-after-free (CVE-2024-52911), blocktxn assert, addr spam	upgrade. Core's policy: low-severity bugs disclosed 2 weeks after the fixing release; medium and high 2 weeks after the last affected version reaches end of life	fixed in current versions	[S18][S19]
51% (majority) attack	the attacker can reverse their own recent payments and censor others, but cannot create coins or take coins "that never belonged to the attacker"	proof of work: the most-work chain wins	more confirmations for large amounts; high hashrate. Smaller forks have been hit: BTG (2018, 2020) and BSV (2021). No successful majority attack on BTC's main chain is documented in these sources (unverified as a negative)	ongoing theoretical risk	[S1 §11][S27][S26]
Selfish mining	a colluding pool earns more than its fair share by withholding blocks. The paper says this is "feasible for any group size", so a majority is not the real safety line	block-race incentives	Eyal and Sirer propose a change that protects only against pools below 1/4 of resources	research result	[S43]
Timewarp	a majority could push difficulty to its minimum within 38 days	how the difficulty window and timestamps interact	BIP 54 timestamp rules	unfixed; BIP 54 pending	[BIP 54][S3]
Eclipse attack	an attacker monopolises a node's peers, then double-spends or wastes its hashrate	peer-selection design	countermeasures in Heilman et al.; BIP 324 encryption; more and diverse peers	partly mitigated	[S44][BIP 324]
Covert ASICBoost	a hidden mining optimisation incompatible with protocol upgrades	SHA-256 header structure	proposal to inhibit it (2017); SegWit commitment structure	contested whether it was ever used	[S28][S29][S30]
Lightning replacement cycling	funds in transit stolen from routing nodes	interaction of mempool replacement rules and HTLC timeouts	implementation mitigations (2023); mempool redesign (Core 31)	partly mitigated	[S41][S21]
Weak randomness in wallets (2013 Android)	private keys recoverable by others	a flaw in Android's secure random-number generator	wallet updates and key rotation; good entropy (see the wallets note)	fixed for those apps	[S50b]
Quantum computers (future)	Shor's algorithm could derive private keys from public keys exposed on-chain ("long exposure") or in the mempool ("short exposure")	elliptic-curve signatures	BIP 360 (P2MR) and BIP 361 (phased sunset of ECDSA/Schnorr spends), both Draft. BIP 361 would eventually restrict spends from unmigrated coins, which is contested	proposals only	[BIP 360][BIP 361]
Data embedding ("spam" or legitimate use, contested)	larger blocks; arbitrary data stored in the chain	any byte a fee pays for can carry data	stricter relay filters (as reported for Knots, unverified) versus relaxed policy (Core 30); the BIP 110 consensus attempt failed with a chain split	unresolved debate	[S20][BIP 110][S46][S47]

General defences that follow from the table (my synthesis of the sources above):

1. Validate with your own full node for large amounts, rather than trusting third parties' confirmations [S16][S11c].
2. Wait for more confirmations as the amount at stake rises [S1 §11].
3. Apply security releases promptly; many past bugs were patched before anyone exploited them [S17][S18].
4. Treat consensus code changes as the highest-risk change. Both 2013 and 2018 show how subtle they can be [BIP 50][S17].
5. Generate keys with good randomness and protect the seed [S50b][BIP 39].
6. Most real-world theft happens at the human and custody layer, not the protocol: see sources/hacks/.

18. Open proposals (as of 2026-10-09, none active)

• BIP 54 Consensus Cleanup (Complete): fixes for timewarp, slow blocks, 64-byte transactions and duplicate coinbases [BIP 54].
• Covenants and new opcodes (Draft/Complete): CTV (BIP 119), OP_CAT in Tapscript (BIP 347), ANYPREVOUT (BIP 118), CHECKSIGFROMSTACK (BIP 348), OP_TXHASH (BIP 346), OP_TEMPLATEHASH (BIP 446) and others listed in the BIP index [BIP 119][BIP 347][S12].
• Quantum migration (Draft): BIP 360 (P2MR) and BIP 361 (legacy-signature sunset in phases: Phase A stops sending to vulnerable addresses about 3 years after activation; Phase B restricts legacy spends 2 years later) [BIP 360][BIP 361].
• BIP 110 is Closed. 86 reachable nodes still advertise it [BIP 110][S7].

---

Sources

All were read on 2026-10-09 unless stated otherwise. Copyrighted articles are summarised in my own words and linked, not copied.

Bitcoin Improvement Proposals. Full copies are in ../sources/bips/, with licence, author, assigned date and hash for each. The six linked only (no licence line) are BIP 16 https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki, BIP 34 …/bip-0034.mediawiki, BIP 43 …/bip-0043.mediawiki, BIP 44 …/bip-0044.mediawiki, BIP 68 …/bip-0068.mediawiki and BIP 101 …/bip-0101.mediawiki.

#	Title / description	Author or issuer	Date	URL
S1	"Bitcoin: A Peer-to-Peer Electronic Cash System" (§ numbers cited)	Satoshi Nakamoto	2008	https://bitcoin.org/bitcoin.pdf
S2	Bitcoin Core src/kernel/chainparams.cpp (mainnet parameters, buried activation heights, assumed chain size)	Bitcoin Core contributors (MIT)	master, read 2026-10-09	https://github.com/bitcoin/bitcoin/blob/master/src/kernel/chainparams.cpp
S3	Bitcoin Core src/pow.cpp (difficulty retarget, ×4 clamp)	Bitcoin Core contributors	master	https://github.com/bitcoin/bitcoin/blob/master/src/pow.cpp
S4	Bitcoin Core src/validation.cpp, GetBlockSubsidy	Bitcoin Core contributors	master	https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp
S5	Bitcoin Core src/consensus/consensus.h (MAX_BLOCK_WEIGHT, COINBASE_MATURITY) and src/consensus/amount.h (MAX_MONEY)	Bitcoin Core contributors	master	https://github.com/bitcoin/bitcoin/tree/master/src/consensus
S6	mempool.space REST API: tip height, block hashes and timestamps at the cited heights, difficulty-adjustment, hashrate (1 month), pools (1 month), block versions for 476,448–476,783	The Mempool Open Source Project	read 2026-10-09	https://mempool.space/docs/api/rest
S7	Bitnodes snapshot of reachable nodes (redirects to btcnodes.io), timestamp 2026-10-09 21:27 UTC; user-agent tally computed	Bitnodes	2026-10-09	https://bitnodes.io/api/v1/snapshots/latest/
S8	Lightning statistics	1ML (https://1ml.com/statistics); mempool.space (https://mempool.space/api/v1/lightning/statistics/latest, data point dated 2026-05-22)	2026-10-09	as given
S9	Bitcoin Developer Guide: Transactions	bitcoin.org / developer.bitcoin.org	read 2026-10-09	https://developer.bitcoin.org/devguide/transactions.html
S10	Common Vulnerabilities and Exposures (list)	Bitcoin Wiki (CC BY 3.0)	page as of 2026-10-09	https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures
S11	Value overflow incident	Bitcoin Wiki	—	https://en.bitcoin.it/wiki/Value_overflow_incident
S11b	Developer Reference: Block Chain (header format)	developer.bitcoin.org	—	https://developer.bitcoin.org/reference/block_chain.html
S11c	Developer Guide: Block Chain (most-work chain, coinbase maturity, light-client fork detection)	developer.bitcoin.org	—	https://developer.bitcoin.org/devguide/block_chain.html
S12	BIPs repository index (README)	BIP editors	commit 927b6de, 2026-10-02	https://github.com/bitcoin/bips/blob/master/README.mediawiki
S13	Block size limit controversy (written from a small-block viewpoint)	Bitcoin Wiki	—	https://en.bitcoin.it/wiki/Block_size_limit_controversy
S14	Commit a30b56eb "fix openssl linkage problems…" adding MAX_BLOCK_SIZE (2010-07-15)	s_nakamoto, via GitHub API	2010	https://github.com/bitcoin/bitcoin/commit/a30b56ebe76ffff9f9cc8a6667186179413c6349
S15	"Re: [PATCH] increase block size limit", post #8	satoshi, bitcointalk	2010-10-04	https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366
S16	"Some Miners Generating Invalid Blocks" alert	bitcoin.org	2015-07-04, updated 2015-07-15	https://bitcoin.org/en/alert/2015-07-04-spv-mining
S17	CVE-2018-17144 Full Disclosure	Bitcoin Core	2018-09-20	https://bitcoincore.org/en/2018/09/20/notice/
S18	Security Advisories (policy and list)	Bitcoin Core	read 2026-10-09	https://bitcoincore.org/en/security-advisories/
S19	CVE-2024-52911: Script Interpreter Remote Crash	Bitcoin Core	2026-05-05	https://bitcoincore.org/en/2026/05/05/disclose-cve-2024-52911/
S20	Bitcoin Core 30.0 release notes	Bitcoin Core	2025-10	https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-30.0.md
S20b	Bitcoin Core 28.0 release notes (full-RBF default, TRUC transactions, Pay-to-Anchor)	Bitcoin Core	2024-10-05	https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-28.0.md
S21	Bitcoin Core 31.0 release notes (cluster mempool, CPFP carve-out removed)	Bitcoin Core	2026-04	https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-31.0.md
S22	GitHub releases: Bitcoin Core and Bitcoin Knots	GitHub API	read 2026-10-09	https://github.com/bitcoin/bitcoin/releases ; https://github.com/bitcoinknots/bitcoin/releases
S23	"SegWit"	Wikipedia (CC BY-SA 4.0)	page as of 2026-10-09	https://en.wikipedia.org/wiki/SegWit
S24	"Bitcoin Cash"	Wikipedia	page as of 2026-10-09	https://en.wikipedia.org/wiki/Bitcoin_Cash
S25	"Bitcoin scalability problem"	Wikipedia	page as of 2026-10-09	https://en.wikipedia.org/wiki/Bitcoin_scalability_problem
S26	"Bitcoin SV"	Wikipedia	page as of 2026-10-09	https://en.wikipedia.org/wiki/Bitcoin_SV
S27	"Bitcoin Gold"	Wikipedia	page as of 2026-10-09	https://en.wikipedia.org/wiki/Bitcoin_Gold
S28	"BIP proposal: Inhibiting a covert attack on the Bitcoin POW function"	Gregory Maxwell, bitcoin-dev mailing list	2017-04-05	https://mailing-list.bitcoindevs.xyz/bitcoindev/CAAS2fgR84898xD0nyq7ykJnB7qkdoCJYnFg6z5WZEUu0+-=mMA@mail.gmail.com/
S29	"Regarding Recent Allegations and Smear Campaigns" (Wayback Machine copy)	Bitmain blog	April 2017	https://web.archive.org/web/2017id_/https://blog.bitmain.com/en/regarding-recent-allegations-smear-campaigns/
S30	"AsicBoost – A Speedup for Bitcoin Mining", arXiv:1604.00575	Timo Hanke	2016	https://arxiv.org/abs/1604.00575
S31	US 11,113,676 B2, "Block mining methods and apparatus" (US patent, public domain)	Hanke, Lerner; Google Patents record	granted 2021-09-07	https://patents.google.com/patent/US11113676B2/en
S32	CN105245327A, "Optimizing method, device and circuit for Hash computing chip of bitcoin proof of work"	Beijing Bitmain Technology; Google Patents record	published 2016-01-13	https://patents.google.com/patent/CN105245327A/en
S33	"The Evolution of Bitcoin Hardware", IEEE Computer 50(9), Sept 2017 (author's PDF read)	Michael Bedford Taylor	2017	https://ieeexplore.ieee.org/document/8048662 ; PDF https://cseweb.ucsd.edu/~mbtaylor/papers/Taylor_Bitcoin_IEEE_Computer_2017.pdf
S34	Pooled mining	Bitcoin Wiki	—	https://en.bitcoin.it/wiki/Pooled_mining
S35	"Mining pool template similarity" observation	b10c	2024-09-16	https://b10c.me/observations/12-template-similarity/
S36	Stratum V2 overview	Stratum V2 project	read 2026-10-09	https://stratumprotocol.org/
S37	DATUM documentation	OCEAN	read 2026-10-09	https://ocean.xyz/docs/datum
S38	Retailer listing "Antminer S23 Hydro 3U (1160 Th/s)" (seller spec, unverified)	cryptobox.cz	read 2026-10-09	https://cryptobox.cz/product/antminer-s23-hydro-3u-1160-th-s
S39	"The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments", draft 0.5.9.2	Joseph Poon, Thaddeus Dryja	2016-01-14	https://lightning.network/lightning-network-paper.pdf
S41	"Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 'All your mempool are belong to us'"	Antoine Riard, bitcoin-dev mailing list	2023-10-16	https://mailing-list.bitcoindevs.xyz/bitcoindev/CALZpt+GdyfDotdhrrVkjTALg5DbxJyiS8ruO2S7Ggmi9Ra5B9g@mail.gmail.com/
S42	"Bitcoin Transaction Malleability and MtGox", arXiv:1403.6676	Christian Decker, Roger Wattenhofer	2014	https://arxiv.org/abs/1403.6676
S43	"Majority is not Enough: Bitcoin Mining is Vulnerable", arXiv:1311.0243	Ittay Eyal, Emin Gün Sirer	2013	https://arxiv.org/abs/1311.0243
S44	"Eclipse Attacks on Bitcoin's Peer-to-Peer Network", USENIX Security 2015	Ethan Heilman, Alison Kendler, Aviv Zohar, Sharon Goldberg	2015	https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/heilman
S45	Bitcoin Optech topic "Taproot" and Newsletter 2021-06-16 ("Taproot locked in")	Bitcoin Optech	2021	https://bitcoinops.org/en/topics/taproot/ ; https://bitcoinops.org/en/newsletters/2021/06/16/
S46	"Controversial Bitcoin fork BIP-110 mines two blocks, then stops"	CoinDesk	2026-08-09 (updated 08-10)	https://www.coindesk.com/tech/2026/08/09/controversial-bitcoin-fork-bip-110-mines-two-blocks-then-stops
S47	"BIP-110 Fork Stalls at Two Blocks as Bitcoin Miners Refuse to Follow"	Mathew Di Salvo, Bitcoin Magazine	2026-08	https://bitcoinmagazine.com/news/bip110-stalls-bitcoin-miners-do-not-follow
S48	GitHub repository and release metadata: btcsuite/btcd, getfloresta/Floresta, utreexo/utreexod, libbitcoin/libbitcoin-server, bcoin-org/bcoin, petertodd/bitcoin	GitHub API	read 2026-10-09	https://github.com/btcsuite/btcd etc.
S49	"BIP-110 Fork Restarts After Stall, Shrinks Block Sizes to 300 KB" (headline from a search result; page returned HTTP 403)	Crowdfund Insider	2026-09	https://www.crowdfundinsider.com/2026/09/304479-bitcoin-improvement-proposal-bip-110-fork-restarts-after-stall-shrinks-block-sizes-to-300-kb
S50	Segregated Witness (UASF-side account)	Bitcoin Wiki	—	https://en.bitcoin.it/wiki/Segregated_Witness
S50b	"Android Security Vulnerability" alert	bitcoin.org	2013-08-11	https://bitcoin.org/en/alert/2013-08-11-android

Computed figures, and how. - Supply: summed 210000 × (50·10⁸ >> i) sats over every halving i, from Bitcoin Core's formula [S4]. - Halving date: remaining blocks × 579 s (this epoch's mempool.space average) or × 600 s. - BIP 91: counted the blocks with version top bits 001 and bit 4 set among the headers for 476,448–476,783 [S6]. - Pool share and node tallies: from the cited API responses.