I set out to explain blockchain end-to-end, but mean it — simple in shape, brutal in scope. Not "blocks are linked by hashes" hand-waving. Show the modular arithmetic. Walk SHA-256. Justify why ECDSA works. Put numbers on the 51% attack. What follows is that writeup, restructured as a long-form blog post.
Cryptography fundamentals
Cryptography is the science of moving data across an untrusted channel in a form that, even if intercepted, can't be read by an unauthorized party. The field is ancient — Egyptian hieroglyphics, Greek scytale, Caesar's cipher — but the modern shape of it is mathematical. Everything reduces to the same loop: plaintext → encryption algorithm → ciphertext → decryption → plaintext. Plaintext is what you want to send. Ciphertext is the unreadable form on the wire. Encryption is the forward direction; decryption is its inverse; both are governed by keys, and only the right key reverses the operation.
Plaintext: HELLO
Encrypted: KHOOR
Decrypted: HELLOUnderneath everything, cryptography is trying to guarantee four properties:
- Confidentiality. Private data stays unreadable to third parties.
- Integrity. Data hasn't been tampered with in transit or at rest.
- Authenticity. The sender is who they claim to be.
- Non-repudiation. A signer can't plausibly deny their signature.
Symmetric vs. asymmetric
There are two encryption families, and the distinction lives in the relationship between the encryption and decryption keys.
Symmetric encryption — one shared key for both sides. AES and DES are the canonical examples. The pain is key distribution: a company of n employees needs n(n−1)/2 keys to fully connect (≈ 499,500 for a thousand people), and every key has to be exchanged over a secure side-channel before any real traffic can flow.
Asymmetric encryption — two mathematically-linked keys: a public one anyone can hold, a private one that never leaves the owner. RSA and Elliptic Curve Cryptography are the workhorses. If Alice wants to send Bob a message, she encrypts with Bob's public key; only Bob's private key can decrypt. The private key is never transmitted, which is the entire point.
What blockchain actually is
A blockchain is a growing chain of records — each record a "block," each block linked to the previous one by a cryptographic hash. Distributed, decentralized, and immutable: distributed because copies live across many nodes, decentralized because no single node owns it, and immutable because changing one block invalidates every block after it.
Bitcoin and Ethereum are the visible faces, but the mechanism itself is just "a tamper-evident ledger anyone can verify." Each block carries a small bundle of fields:
- Version — chain protocol version.
- Data — transactions, or any arbitrary payload.
- Previous hash — SHA-256 of the previous block. This is the "chain" part.
- Hash — SHA-256 of this block's contents. The block's fingerprint.
- Difficulty target — upper bound the block hash must come in under.
- Timestamp — when the block was created.
- Nonce — the number miners increment to brute-force a valid hash.
Two more rules turn this from a fancy linked list into something secure. Consensus: a block isn't added until the network agrees, which in Bitcoin's case means Proof of Work — miners race to find a nonce that drives the block hash below the difficulty target. Peer-to-peer replication: every node stores its own copy and validates every chain it sees. No node is authoritative; the longest valid chain wins.
Hash functions
A cryptographic hash function H takes an input of any length and produces an output of fixed length. Formally:
Input x can be any binary string; output H(x) is exactly n bits. For SHA-256, n = 256. The properties that make hash functions useful for blockchain:
- Deterministic. Same input, same output, every time.
- Fixed-length output. 256-bit input or 256-megabyte input — same digest size.
- Pre-image resistance. Given H(x), it's computationally infeasible to recover x.
- Avalanche effect. A one-bit input change flips ≈ half the output bits.
- Collision resistance. No two inputs should produce the same hash.
- Efficient. Compute fast, even on enormous inputs.
MD5, SHA-1, SHA-256
Three families dominate the history of cryptographic hashing, and only one is still standing.
MD5. Ron Rivest, 128-bit output, broken by collision attacks. Don't use for anything cryptographic.
Text: Hello World
Hash: 65a8e27d8879283831b664bd8b7f0ad4SHA-1. NSA-designed, 160-bit output. Still appears in Git and legacy SSL but cryptographically retired after Google's 2017 SHAttered collision.
Text: Hello World
Hash: 943a702d06f34599aee1f8da8ef9f7296031d699SHA-256. SHA-2 family, 256-bit output, the basis of Bitcoin's Proof of Work and most modern digital signatures. No practical attacks; the wide hash space and strong avalanche make brute-force the only known approach.
Text: Hello World
Hash: a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b53a48a42f7a34e6f| Feature | MD5 | SHA-1 | SHA-256 |
|---|---|---|---|
| Hash size | 128 bits | 160 bits | 256 bits |
| Security | Low | Moderate | High |
| Collision resistance | Broken | Broken | Secure |
| Common uses | Checksums | SSL, Git | Blockchain, signatures, TLS |
| Status | Deprecated | Deprecated | Active |
Mathematical foundations
To follow SHA-256 you need a small grab-bag of primitives. None of them is deep on its own; what makes the algorithm hard to reason about is how many of them get stacked.
Modular arithmetic
Modular arithmetic is "clock arithmetic" — numbers wrap around a fixed modulus. For integers a and n, the expression a mod n is the remainder of a ÷ n. So 7 mod 5 = 2.
Bitwise operations
SHA-256 lives in the world of 32-bit words. The six bitwise operations you need:
AND (∧) OR (∨) XOR (⊕)
A = 1101 A = 1101 A = 1101
B = 1011 B = 1011 B = 1011
A&B = 1001 A|B = 1111 A⊕B = 0110
NOT (¬) SHL (<<) SHR (>>)
A = 1101 A<<2 = 110100 A>>2 = 0011
~A = 0010Right rotation (ROTR)
Right rotation is "shift right, but wrap the bits that fall off back to the left so nothing is lost." For an n-bit number x rotated by k:
Worked example with A = 110100112 and k = 3:
ROTR(A, 3) = (A >> 3) | (A << 5)
= 00011010 | 01100000
= 01111010Boolean functions
Two mixing functions appear inside the SHA-256 compression round.
Choice — selects between y and z based on x:
Majority — returns whichever value occurs at least twice:
Sigma functions
These four functions provide the diffusion that makes SHA-256's avalanche effect work — each one spreads input bits across the output by combining rotations at different offsets.
SHA-256, walked
SHA-256 turns an arbitrary-length message M into a 256-bit digest through padding, splitting, expansion, compression, and a final addition. Four stages.
1. Padding
First the message is padded so its total length is a multiple of 512 bits. The recipe is: append a single 1 bit, then enough 0 bits, then a 64-bit big-endian representation of the original length L:
2. Block splitting and message expansion
The padded message is split into 512-bit blocks. Each block is sliced into sixteen 32-bit words W0…W15, then extended to 64 words using a recurrence that mixes earlier words with σ0 and σ1:
3. Compression
Eight 32-bit state variables a, b, c, d, e, f, g, h are initialised from the SHA-256 constants:
H0 = 0x6a09e667 H4 = 0x510e527f
H1 = 0xbb67ae85 H5 = 0x9b05688c
H2 = 0x3c6ef372 H6 = 0x1f83d9ab
H3 = 0xa54ff53a H7 = 0x5be0cd19Each block runs 64 rounds. Every round mixes the state through Σ0, Σ1, Ch, Maj, the expanded word Wt, and a per-round constant Kt:
T1 = h + Σ1(e) + Ch(e,f,g) + Kt + Wt
T2 = Σ0(a) + Maj(a,b,c)
h = g
g = f
f = e
e = d + T1
d = c
c = b
b = a
a = T1 + T24. Final hash
After the last block, the working state is added (mod 232) back into the running hash, and the eight 32-bit words are concatenated to form the 256-bit digest:
Worked example — a Bitcoin block header
A real Bitcoin block header with plausible fields:
| Field | Example value |
|---|---|
| Version | 0x20000000 |
| Previous block hash | 0000…3667d652b |
| Merkle root | 871714dc…8e3f89e6 |
| Timestamp | 0x5B8D80C0 |
| Difficulty target | 0x17148EDF |
| Nonce | 0x1dac2b7c |
Concatenate the fields, run SHA-256 twice (Bitcoin double-hashes to protect against length-extension attacks), and compare against the target. If the resulting H2 < Target, the block is valid and the miner is paid.
H1 = SHA256(header)
H2 = SHA256(H1)
# Block is mined if:
H2 < TargetSHA-256 is the engine of every meaningful property a blockchain claims to have. Immutability, mining, transaction IDs, Merkle roots — all of them are one hash function applied carefully.
How blockchain uses hashes
In a blockchain, every block embeds the hash of the previous block in its own header. The link is not metadata — it's structural. Tamper with any block Bn and its hash changes (avalanche effect). But block Bn+1 embedded the old hash, so the link breaks; Bn+1's hash now also fails to match what Bn+2 embedded, and so on. The tamper cascades all the way to the chain head, and every node detects it instantly.
Block 0 (Genesis)
data: none
hash: 0000…0000
Block 1
data: Alice → Bob 1 BTC
prev: 0000…0000
hash: a3c1c3a7…d053f31
Block 2
data: Bob → Charlie 0.5 BTC
prev: a3c1c3a7…d053f31
hash: b4e9dbb5…fb5129eProof of Work
Proof of Work is Bitcoin's consensus mechanism. To add a block, a miner has to find a hash below a target value — and finding it requires enormous computational effort, while verifying it costs almost nothing.
Difficulty D is inversely proportional to the target T:
The probability behind the puzzle
SHA-256 has 2256 ≈ 1.16 × 1077 possible outputs. The probability of any single hash being below the target is:
Substituting T = Tmax / D:
Which means the expected number of hash attempts to find a valid block is exactly the difficulty:
Bitcoin readjusts difficulty every 2,016 blocks so the average block time stays near 10 minutes:
When miners get faster on aggregate, difficulty climbs and the puzzle gets harder. The block time is the regulator; everything else is a knob the network turns to keep it steady.
Merkle trees
A block can contain thousands of transactions; you don't want to re-hash all of them every time you verify one. Merkle trees solve this. Each transaction is hashed into a leaf, leaves are hashed pairwise into parents, parents are hashed into grandparents, and at the top of the tree sits a single hash — the Merkle root — that compresses every transaction in the block into 256 bits.
- Each transaction Ti becomes a leaf Li = H(Ti).
- Pairs of leaves are concatenated and hashed: Pi = H(Li ∥ Li+1).
- Pairs of parents are hashed again, recursively, until one root remains.

To verify that T1 is in the block, a verifier only needs L2 and P2 — log2(n) hashes instead of all n. That logarithmic verification cost is what makes lightweight clients (SPV wallets) possible.
Security of the hash itself
SHA-256 needs to resist two specific attacks for blockchain to mean anything.
Pre-image resistance
Given a hash y, finding any x with H(x) = y takes O(2256) operations on average. At 1,000 hashes per second:
The age of the universe is ≈ 1.4 × 1010 years. The brute-force bound isn't large; it's laughable.
Collision resistance
Finding any two inputs that hash to the same output is easier than pre-image, thanks to the birthday paradox — but only down to:
Still infeasible. 2128 ≈ 3.4 × 1038, which exceeds the total computational work the human species has ever performed by many orders of magnitude.
| Attack | Complexity | Why it fails |
|---|---|---|
| Pre-image | O(2^256) | Hash space is astronomical; brute force is the only known approach. |
| Collision | O(2^128) | Birthday paradox halves the exponent but the bound is still beyond reach. |
Digital signatures and ECDSA
Signatures answer a different question to hashing: not "has this been tampered with," but "who authorised it." In blockchain, every transaction is signed by its sender's private key, and anyone holding the matching public key can verify it without ever seeing the private key. The sender can't plausibly deny the signature — non-repudiation — and the verifier can't forge one because they'd need the private key to do it.
Where d is the private key, e is the public key, and M is the message. If the decrypted signature matches the message hash, the signature is genuine.
Elliptic curve cryptography
RSA works, but ECC gives equivalent security at much smaller key sizes — which matters when you're storing keys on every transaction in a public ledger. ECC is built on the algebra of points on an elliptic curve over a finite field 𝔽p:
The discriminant condition keeps the curve non-singular. The two operations you do on curve points are addition and scalar multiplication. Adding two distinct points P(x1, y1) and Q(x2, y2) uses the slope between them:
Scalar multiplication is then just repeated addition: kP means "add P to itself k times." Computing kP is fast. Reversing it — recovering k given P and kP — is the Elliptic Curve Discrete Logarithm Problem (ECDLP), and the best known algorithm runs in O(√n) time. For curves with n ≈ 2256, that's 2128 operations: the same wall we hit for hash collisions.
ECDSA — signing a transaction
ECDSA is the digital signature scheme Bitcoin and Ethereum actually use. To sign a message M with private key d:
- Hash the message: H(M) = SHA256(M).
- Pick a one-time secret random nonce k.
- Compute the curve point (x, y) = k · G, where G is the curve's base point. Set r = x mod n.
- Compute s = k−1 · ( H(M) + r · d ) mod n.
- Publish the signature (r, s).
Verification reverses the process using the signer's public key P = d · G:
The nonce k has to be both fresh and secret. Reusing it across two signatures leaks the private key — this is exactly how Sony's PS3 signing key was extracted in 2010. Every "ECDSA postmortem" article ever written is, in the end, about k.
Blockchain security in aggregate
Every block Bn can be written as a hash of three things — its data, the hash of the previous block, and its nonce:
Change any single Dn and the avalanche effect ensures the new Bn′ ≠ Bn. Block Bn+1 embedded the old hash, so its hash also changes when you re-derive it with the new previous-hash field, and the ripple continues all the way to the chain head. Tamper detection is mechanical, not heuristic.
The 51% attack
The textbook attack on Proof of Work is the 51% attack: an adversary controlling a majority of the network's hash rate can mine a competing chain faster than honest miners, eventually overtaking the canonical chain and rewriting history. The math admits this — the attacker's probability of catching up grows with the fraction of hashpower they hold:
For p = 0.51 this is (1.0408)n, which trends to 1 as n grows. But the cost grows with it. Re-mining n blocks against the network's combined hashpower requires roughly:
For Bitcoin in 2024, that's on the order of billions of US dollars per day of sustained majority hashpower, plus the hardware required to produce it, plus the electricity. And the reward — being able to double-spend, briefly — is bounded by the size of the transactions you can reverse before the network notices. The attack is mathematically feasible and economically nonsensical, which is the entire design.
Reflection
Two things stood out writing this. The first is how much of blockchain's security reduces to "SHA-256 doesn't leak structure and ECDLP has no shortcut." Take either of those away and the rest of the building falls. The second is how cleanly the economic and the cryptographic layers compose. The math says a 51% attack is possible; the economics says it isn't worth it; together they say the system is secure. Neither half is sufficient on its own, and pretending otherwise — "blockchain is unhackable" or "blockchain is fundamentally insecure" — misses the joint argument that's actually doing the work.
References
- Alman, S. & Hirsh, S. (2020). Blockchain. ALA Neal-Schuman.
- Laurence, T. (2023). Blockchain for Dummies.
- Shen, M., Zhu, L. & Xu, K. (2020). Blockchain: Empowering Secure Data Sharing. Springer.
- Mammeri, Z. (2024). Cryptography: Algorithms, Protocols, and Standards for Computer Security. Wiley.
- Buterin, V. (2017). The Meaning of Decentralization. Medium.
- Konstantopoulos, G. (2017). Understanding Blockchain Fundamentals, Part 1: Byzantine Fault Tolerance. Loom Network.
- Castor, A. (2017). A (Short) Guide to Blockchain Consensus Protocols. CoinDesk.
- Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
