cryptoinbrief.

EN | AR Light |

Bitcoin and crypto, from zero

By Moamen Basel, September 2026, 0 labs, ~7 min

From how mining works to why Bitcoin picked UTXO. Each topic has one drawing and a short explanation.

The original problemA bank solves it with one trusted clerk; Bitcoin deletes the clerk and replaces him with a lottery priced in electricity The bank way one clerk writes the ledger and you must trust him one point of failure The Bitcoin way no clerk, no one to trust the right to write is earned by work one vote per watt
Fig. 1.1 A bank hands the ledger to one clerk you have to trust. Bitcoin deletes the clerk and prices the pen in electricity.
Contents
  1. 01Who writes the next page
  2. 02The hash is a fingerprint machine
  3. 03The puzzle miners actually solve
  4. 04The nonce and the clock
  5. 05Nobody trusts anybody
  6. 06Why the history seals itself
  7. 07When two miners win at once
  8. 08How the chain knows a payment is yours
  9. 09The address is not the public key
  10. 10UTXO versus the account model
  11. 11The blockchain is not a data structure
  12. 12Monero makes privacy mandatory
  13. 13MEV, the dark side of ordering
  14. 14The trilemma is a budget

01 Who writes the next page

Strip away the price charts and Bitcoin is one shared ledger kept by millions of strangers. Its first problem is order. Imagine one output worth 1 BTC. Its owner signs two transactions that spend that same output, one paying Bob and one paying Carol. A node in Cairo hears about Bob first while a node in Tokyo hears about Carol first. Both signatures are valid. There is no trusted global clock or central record that can declare which message arrived first. A signature proves authorization, but it does not stop an owner from authorizing two conflicting spends.

Bitcoin makes every node check the rules, then settle on the valid chain with the greatest cumulative proof of work. When Bob's spend enters that shared history, Carol's conflicting transaction tries to reuse an output that is already spent, so nodes reject it. Timestamps help organize blocks, but they are not a trusted stopwatch and do not solve double spending by themselves. The original Bitcoin paper describes the network as publicly timestamping transactions into a proof of work chain that provides evidence of their order. Proof of stake bids for the same ordering job with money instead of watts (the full essay).

Why distributed money needs a shared orderTwo valid signatures spend the same output, different nodes receive them in different orders, and cumulative proof of work establishes one shared history UTXO 7 · 1 BTC signed spend pay Bob signed spend pay Carol Cairo node Bob first · Carol second Tokyo node Carol first · Bob second valid chain greatest cumulative work Bob counts in history Carol reuses spent output rejected Signatures authorize. The proof of work chain establishes shared order.
Fig. 1.2 Two valid signed spends can reach honest nodes in opposite orders. Bitcoin's valid chain with the greatest cumulative work gives them one shared history.

02 The hash is a fingerprint machine

A hash is not encryption. There is no decryption key. SHA-256 takes any input and returns a fixed 256-bit fingerprint, usually written as 64 hex characters. Deterministic means the same bytes produce the same fingerprint. One way means recovering an arbitrary input from its hash is computationally infeasible. Avalanche means a tiny input change unpredictably changes the output. A double SHA 256 calculation is cheap. The live fingerprint lab sits in Bitcoin from zero.

The avalanche property of a hashChanging one digit in the message flips the fingerprint completely Send 10 bitcoin SHA-256 eaf36db… Send 90 bitcoin SHA-256 4c1b7d7… One digit apart, two fingerprints with nothing in common.
Fig. 2.1 Change one digit of the message and the fingerprint turns over completely, with no visible relation between the two outputs.

03 The puzzle miners actually solve

The effort is not in computing one fingerprint. The demand runs the other way: find a header whose double SHA-256 value is below the network target. No useful shortcut is known, so miners test many candidates. In the simplified leading zero model, each extra hex zero multiplies expected work by 16. Bitcoin itself uses a numeric target that adjusts every 2,016 blocks. The same loop is in the mining lab.

The mining loopBuild the block once, then guess the nonce until the hash drops under the target Build the block: transactions + coinbase Compute the Merkle root, put it in the header Hash the header (80 bytes) Hash under the target? No: change the nonce Yes: broadcast the block
Fig. 3.1 Build the block once, then guess nonces until the fingerprint drops under the target.

04 The nonce and the clock

The nonce is not an anti replay value here. It is the fastest header field to vary between attempts. Miners can also alter the timestamp, version bits, transaction selection, or an extraNonce in the coinbase that changes the Merkle root. The timestamp helps enforce time bounds and retune difficulty every 2,016 blocks. A valid timestamp must be greater than the median of the previous 11 blocks and no more than two hours ahead of the validating node's clock.

The block header fieldsThe 80-byte header has six fields, with the nonce as the fastest field to vary The header, 80 bytes Prev hash 32 B Merkle root 32 B Version 4 B Time 4 B Bits 4 B Nonce 4 B
Fig. 4.1 The 80-byte header as six cells. Previous hash and Merkle root take 64 bytes, while the nonce is the fastest field to vary.

05 Nobody trusts anybody

When a miner announces a block, every node re checks the whole thing locally. Is the hash under the target? Are the signatures valid? A double spend is a fail. So is a coinbase past its cap. Break one rule and the block is discarded, not relayed. Cheating isn't forbidden on paper. It's simply the most expensive way to burn your own money.

Independent verificationThe block reaches several nodes and each one checks it alone, then accepts or rejects The miner broadcasts Node A Node B Node C every node checks alone: the hash, the signatures, no double spend, the coinbase cap nobody asks anyone for trust all checks pass: accept and relay any check fails: drop it
Fig. 5.1 Each node re checks the block on its own and either accepts and relays it or throws it away.

06 Why the history seals itself

Every block stores the hash of the block before it. That link is the chain. Change a transaction inside an old block and its Merkle root changes, which changes its header hash and breaks the next block's link. Rewriting that history requires rebuilding the proof of work from that point while the honest chain continues growing.

Blocks chained by hashesEditing one block breaks every link after it Block 1 sealed by its hash Block 2 prev hash matches Block 3 prev hash matches every block carries the hash of the one before it; the links hold Block 1 edited, new hash Block 2 prev link now wrong Block 3 broken as well one edit breaks every link after it; the only repair is re-mining them all
Fig. 6.1 Edit one old block and every link after it snaps. Re mining all of them, mid race, is the only repair.

07 When two miners win at once

You'll get two miners finding a block in the same second. Two different blocks with different hashes. The network splits for a moment. The system does not judge which block is better; it waits for the next draw. Whoever extends one branch first gives it more accumulated work, and everyone jumps to it. The losing branch is called stale. Its transactions go back into the queue. The rule is the most work, not the most blocks. Historic forks and the exact tiebreak are in Bitcoin from zero; other chains split the question differently, Solana orders first and Sui chases finality first.

Fork resolutionTwo branches compete and the next draw settles it for the one with more work 104 105-A 105-B two valid blocks at once: nobody picks, everyone waits 104 105-A 106-A 105-B the branch with more work wins 105-B is stale now, its transactions return to the queue
Fig. 7.1 The next draw settles it: the branch with more accumulated work wins and 105-B turns stale.

08 How the chain knows a payment is yours

There's no balance field anywhere. What you own are signed cheques made out to you, the UTXOs. To pay, you destroy an old cheque and mint new ones, and your signature proves the right to do it. Keys come in a pair. Private stays secret. Public is derived from it. The private key produces a signature, and anyone holding the public key can check it without ever seeing the secret. Alter one byte of the payment and the signature breaks.

Signing and verificationThe private key signs and the public key verifies without revealing the secret The sender private key (secret) signs the payment signature (r,s) on the network: payment + signature Any node public key verifies it the secret never shows
Fig. 8.1 The private key signs, any node verifies with the public key, and the secret never leaves the sender.

09 The address is not the public key

A classic Bitcoin P2PKH address is derived from a public key. Hash it with SHA-256 then RIPEMD-160, add a version byte and checksum, then encode the result in Base58Check. The checksum catches common typing errors and the version distinguishes networks. This describes legacy P2PKH addresses. SegWit and Taproot use different address encodings and scripts.

Deriving the addressFrom the public key through hash, checksum and encoding to the final address Public key HASH160 + version + checksum Base58 1K1j…
Fig. 9.1 Public key to address: hash, version byte, checksum, Base58.

10 UTXO versus the account model

Bitcoin runs on UTXO, the cheque model. Each output can be spent once. Ethereum uses accounts, where balances and contract state change in place. A repeated Bitcoin spend references an output that is already consumed, so validation rejects it. Explicit UTXO dependencies can also expose independent work. Account chains use per account nonces to order transactions and reject repeats.

A replay attack in both modelsAn account model without a nonce pays the same transfer twice; UTXO rejects the copy by itself Accounts, no nonce copy 1: move 5, accepted copy 2: move 5, accepted Omar is down 10: robbed you must bolt on a nonce counter UTXO copy 1: spend cheque #ab, accepted the cheque is gone copy 2: rejected the spent output cannot be reused
Fig. 10.1 Without a nonce the account model pays the same transfer twice. UTXO rejects the copy without any extra machinery.

11 The blockchain is not a data structure

There's no import blockchain anywhere. A blockchain is a system architecture, not a data type, the same way a database or an operating system isn't one structure. It's an assembly. A hash linked list for the blocks, a Merkle tree for the transactions, a key value store for disk, a set for the UTXO, a hash map for the mempool. If one structure must represent it, take the hash linked list: a linked list whose pointer is a hash of the content, so any forgery snaps the chain.

The parts of a blockchainOne system assembled from several ordinary data structures a blockchain is a system hash-linked list joins the blocks Merkle tree commits transactions key-value DB stores the blocks set UTXO hash map mempool
Fig. 11.1 One system assembled from several ordinary structures, each doing one job.

12 Monero makes privacy mandatory

Bitcoin's ledger is public. Monero hides receivers with one time addresses, obscures the signer with a ring signature, and hides amounts with RingCT while still proving balance. Transaction privacy is mandatory, so private transactions share an anonymity set. Network metadata remains a separate problem. Monero uses relay protections such as Dandelion++, but Tor or I2P can still matter against network observers. The machinery is dissected in Monero under the hood; Zcash makes a different tradeoff with proofs instead of decoys.

Monero's three hidden layersReceiver, sender and amount are hidden on-chain; the network layer stays exposed The receiver stealth address The sender ring signature, 1 of 16 The amount RingCT network metadata needs its own protections
Fig. 12.1 Receiver, sender and amount hidden on chain; the network layer stays as exposed as Bitcoin's.

13 MEV, the dark side of ordering

Whoever builds the block has ordering power. Taking higher fee transactions first is the normal auction for scarce block space. MEV appears when a builder earns from relative ordering, such as placing a buy before a victim and a sell after it. Plain Bitcoin transfers usually expose less ordering value than on chain exchange trades, but Bitcoin still has fee ordering and other forms of miner extractable value. Solana's ordering market and Bitcoin's corner of it are covered in their own essays.

The sandwich attackThe builder puts his buy before the victim and his sell after her the victim buys at the market price no builder in the queue: the order carries nothing to steal 1. the builder buys ahead of the victim 2. the victim buys at a worse price 3. the builder sells and pockets the spread the builder's profit is the price difference he forced on the victim
Fig. 13.1 The builder's buy lands before the victim and his sell right after; the profit is the price gap he created.

14 The trilemma is a budget, not a law

Every chain in this series is answering the same question with different money. The blockchain trilemma is the popular shorthand for that question: a public chain wants to be decentralized, secure and scalable at once, and pushing hard on two tends to charge the third. It is a design heuristic that came out of the Ethereum research community, not a proven theorem, and you should treat anyone who claims to have deleted the tradeoff with suspicion. The useful version is narrower: name the three costs, then ask which one a design is paying.

Decentralization is how cheap it is to verify the chain yourself and how many independent parties decide what happened. The honest measure is the cost of running a full node on ordinary hardware, not the number of tokens in circulation. Security is what an attacker must spend to rewrite or censor history, whether that is energy under proof of work or stake that gets destroyed under proof of stake. Scalability is throughput and cost per transaction at the point where ordinary people actually use it.

The blockchain trilemmaA triangle with decentralization at the top and security and scalability at the lower corners. Each step rings one corner and names the cost a design pays when it pushes hardest on the other two. decentralization security scalability throughput pays openness pays attack cost pays
Fig. 14.1 Step through the three corners. Whichever two a design pushes hardest, the ringed one is what it spends. No design deletes the tradeoff; it moves the cost somewhere its users can live with.

Read the rest of the series as four answers to that budget. Bitcoin spends throughput to keep verification cheap and the attack cost physical. Proof of stake replaces energy with capital at risk, which lowers the cost of participating but introduces slashing rules and a stake distribution to argue about. Solana buys throughput with hardware, raising the cost of running a validator so users get cheap fast blocks. Sui narrows the problem instead of the hardware, executing transactions that touch nothing in common without putting them through consensus at all.

Privacy sits outside this triangle, which is exactly why it is worth naming separately. Monero and Zcash both keep a public ledger and pay for concealment in verification work and proof size. That is a fourth budget, not a fourth corner, and a chain can be decentralized, secure, fast and still leak everything you do.

This page sums up a long conversation series on how Bitcoin and crypto work. Details and live experiments are in Bitcoin from zero and Monero under the hood. As of September 2026 the block reward is 3.125 BTC. Monero ring size is 16. FCMP++ is audited but not yet activated.