bitcoinbegins.com
Part 1 of 2 — Overview and Block Header
Block 170 is one of the most historically significant blocks in the entire Bitcoin blockchain. It contains exactly two transactions:
Before block 170, Bitcoin had only been used to mine coins and distribute block rewards to a single person (Satoshi). This block is the moment the network became a system for transferring value between participants. It proved the entire mechanism worked end-to-end: create a transaction, sign it with a private key, broadcast it, have a miner include it in a block, and have the recipient be able to spend the output. Every Bitcoin transaction since follows the same pattern.
Block 170 was mined approximately nine days after the genesis block. By this point, the network was tiny — Satoshi was effectively the only miner. The block reward was 50 BTC, difficulty was at its minimum, and blocks were being found at irregular intervals since there was no competition to regulate the rate.
The previous block (169) had been mined at 11 January 2009 23:24:05 UTC — about four hours before block 170. This is a typical gap for the early network where a single low-powered machine was doing all the mining.
| Property | Genesis (Block 0) | Block 1 | Block 170 |
|---|---|---|---|
| Date | 3 Jan 2009 | 9 Jan 2009 | 12 Jan 2009 |
| Transactions | 1 (coinbase only) | 1 (coinbase only) | 2 (coinbase + transfer) |
| Block reward | 50 BTC (unspendable) | 50 BTC (spendable) | 50 BTC (spendable) |
| Bits | ffff001d | ffff001d | ffff001d |
| Difficulty | 1 (minimum) | 1 (minimum) | 1 (minimum) |
| Historic significance | Network launch | First spendable reward | First peer-to-peer transfer |
Like every Bitcoin block, block 170 begins with an 80-byte header. The header is the only part of the block that miners hash repeatedly during proof-of-work. Below is the complete raw header, with each field colour-coded.
| Version | 4 bytes | 01000000 → 1 (little-endian) Version 1, the only version used during the early network. Indicates the block follows the original Bitcoin protocol rules. |
| Previous Block Hash | 32 bytes | 55bd840a78798ad0da853f68974f3d183e2bd1db6a842c1feecf222a00000000 → display: 000000002a22cfee1f2c846adbd12b3e183d4f97683f85dad08a79780a84bd55 The hash of block 169, stored in reversed byte order. This is what chains the blocks together — any change to block 169 would change its hash, invalidating block 170's reference to it. |
| Merkle Root | 32 bytes | ff104ccb05421ab93e63f8c3ce5c2c2e9dbb37de2764b3a3175c8166562cac7d → display: 7dac2c5666815c17a3b36427de37bb9d2e2c5ccec3f8633eb91a4205cb4c10ff A cryptographic fingerprint of all transactions in this block. With only two transactions, this is simply the double-SHA256 of the two TXIDs concatenated. Any change to either transaction would produce a completely different merkle root, invalidating the header. |
| Timestamp | 4 bytes | 51b96a49 → 0x496ab951 = 1,231,731,025 (little-endian) → 12 January 2009, 03:30:25 UTC Unix timestamp set by Satoshi when constructing the block. Approximately 4 hours and 6 minutes after block 169 (11 Jan 2009, 23:24:05 UTC). Timestamps in early Bitcoin were set by the miner's local clock and are not guaranteed to be precise. |
| Bits | 4 bytes | ffff001d → 0x1d00ffff = 486,604,799 (little-endian) The compact representation of the mining difficulty target. The same value as the genesis block and block 1 — difficulty had not yet adjusted. A valid block hash must be numerically less than the target derived from this value. |
| Nonce | 4 bytes | 283e9e70 → 0x709e3e28 = 1,889,418,792 (little-endian) The value Satoshi incremented until the block hash fell below the difficulty target. Starting from zero and working upward, it took 1,889,418,792 attempts to find a valid hash — a relatively modest number at minimum difficulty. On modern hardware this would take milliseconds; on Satoshi's 2009 machine it took several hours. |
The block hash is produced by running the 80-byte header through SHA-256 twice (double-SHA256). The result, reversed into display byte order, must begin with enough leading zeros to satisfy the difficulty target.
| Raw header (80 bytes) | 0100000055bd840a78798ad0da853f68974f3d183e2bd1db6a842c1feecf222a00000000ff104ccb05421ab93e63f8c3ce5c2c2e9dbb37de2764b3a3175c8166562cac7d51b96a49ffff001d283e9e70 | |
| First SHA-256 | internal intermediate value — not typically displayed | |
| Second SHA-256 (internal LE) | eea2d48d2fced43468428356659e49d4233f06d4034469a890571 4d100000000 | |
| Block hash (display, reversed) | 00000000d1145790a8694403d4063f323d499e655c83426834d4ce2f8dd4a2ee Eight leading zero bytes — satisfying the minimum difficulty target of 0x1d00ffff. The hash must be less than: 00000000ffff0000000000000000000000000000000000000000000000000000 |
With only two transactions in this block, the merkle tree is as simple as it can get: the two transaction IDs are concatenated (in internal byte order) and hashed with double-SHA256 to produce the root directly.
| TX 0 — Coinbase TXID (display) | b1fea52486ce0c62bb442b530a3f0132b826c74e473d1f2c220bfa78111c5082 | |
| TX 1 — Transfer TXID (display) | f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16 | |
| TX 0 internal (reversed) | 82501c1178fa0b222c1f3d474ec726b832013f0a532b44bb620cce8624a5feb1 | |
| TX 1 internal (reversed) | 169e1e83e930853391bc6f35f605c6754cfead57cf8387639d3b4096c54f18f4 | |
| Concatenated (64 bytes) | 82501c1178fa0b222c1f3d474ec726b832013f0a532b44bb620cce8624a5feb1169e1e83e930853391bc6f35f605c6754cfead57cf8387639d3b4096c54f18f4 | |
| Double-SHA256 | ff104ccb05421ab93e63f8c3ce5c2c2e9dbb37de2764b3a3175c8166562cac7d | |
| Merkle root (display) | 7dac2c5666815c17a3b36427de37bb9d2e2c5ccec3f8633eb91a4205cb4c10ff Matches the value in the block header exactly (after reversing). With a two-transaction block the merkle "tree" has only one level — the two leaves hash directly to the root. |
The bits value 0x1d00ffff encodes the mining difficulty target. To decode it:
0x1d (= 29 decimal) is the exponent — indicating how many bytes long the target is0x00ffff are the coefficient — the significant digits of the target0x00ffff × 2^(8 × (29 − 3)) = 00000000ffff0000…0000 (32 bytes)The block hash 00000000d114… is numerically less than the target 00000000ffff…, so the proof of work is valid. At minimum difficulty, any hash with at least 8 leading zero bytes qualifies.
0x1d00ffff — the minimum possible difficulty — remained unchanged from the genesis block all the way to block 32,255. The difficulty adjustment algorithm fires every 2,016 blocks, and with Satoshi mining alone (and probably at low CPU), blocks were found slowly enough that difficulty never needed to increase in this early period. Block 32,256 was the first to see a difficulty adjustment.
Beyond the 80-byte header, the block body contains a transaction count followed by the raw transaction data. For block 170:
| Header | 80 bytes | Version, previous hash, merkle root, timestamp, bits, nonce — as described above |
| Transaction count | 1 byte | 02 VarInt encoding — value 2, indicating two transactions follow |
| Transaction 0 | ~100 bytes | The coinbase transaction — Satoshi claiming the 50 BTC block reward. Covered in Part 2. |
| Transaction 1 | ~275 bytes | The historic transfer — Satoshi sending 10 BTC to Hal Finney. The first-ever Bitcoin transaction between two people. Covered in Part 2. |