Revision · Project 5 — Bitcoin Mini-Chain

Project 5 built btcmini, a Bitcoin-style mini-chain, and answered one question from the inside: how do strangers who have never met agree on who owns what, with no bank? Here’s what to carry forward.

What this part covered

• The double-spend problem — a coin is just data and data copies for free, so the whole design exists to get one agreed-upon ledger without a trusted third party.
• Hashing and chaining — a double-SHA-256 hash is a fingerprint; wrapping it in a Hash256 newtype and chaining each block by its predecessor’s hash makes any tampering detectable.
• The UTXO model — there are no balances, only unspent transaction outputs; spending is deletion from the UTXO set, and a double-spend is simply a missing row. Conservation and an integer-overflow bug (which really hit Bitcoin in 2010) show why the type checks matter.
• Keys and signatures — k256/ECDSA over secp256k1 (pure Rust, no C) gives keypairs; an address is a hash of the public key, ownership is a valid signature over the sighash, and the signing nonce must never repeat or it leaks the private key.
• Proof-of-Work — a target makes blocks costly to produce; the mining loop searches for a nonce, and the most-work chain rule (not merely “longest”) is how strangers converge on one history.
• A P2P node — the same std::net thread-per-connection model as kvlite, plus a mempool and a two-move newline-JSON protocol, lets two peers broadcast blocks and converge on the same chain.

The takeaway

The two threads meet here: Bitcoin replaces trust in a person with rules that are expensive to break, and Rust replaces trust in a programmer with rules that are impossible to break, both checked before anything can go wrong. Building one in the other is the point, and it sets up Project 6, the other branch of the family tree, where the ledger stops being a calculator and becomes a programmable world computer.