A Bitcoin Primer

We will describe bitcoin specifically here. Many cryptocurrencies are variations of bitcoin that tweak a few details.


Bitcoin is a digital currency that will eventually generate a number of bitcoins slightly under 21 million (2.1e7). Each bitcoin can be further subdivided into ten million (1e8) quantum units each of which is known as a “satoshi”.

The Bitcoin network is a distributed append-only database that is designed to append one block to the linked-list of blocks once every ten minutes. This database keeps track of unspents (more commonly known as “UTXOs” for unspent transaction outputs).


An unspent can be thought of as a roll of coins of any number of satoshis protected by a puzzle script (more commonly known as a “script pubkey”, because it almost always contains a reference to a public key). This puzzle is written in a custom bitcoin stack-based low level scripting language, but is usually one of only a few common forms, including pay-to-public-key, and pay-to-script.

An unspent is a potential input to a transaction.

Unspent Database

The bitcoin database is a ledger of unspents. It doesn’t explicitly define ownership of bitcoins; instead, rules are applied that allow bitcoin to be reassigned if the puzzles can be solved. So you can think of “owning” bitcoin as being equivalent to having the information required to solve the puzzle. In other words, the only benefit ownership confers is the ability to reassign ownership. This may seem odd at first, but it’s the essence of how all money works.


To spend coins, one creates a transaction (or Tx). Roughly speaking, a transaction unrolls rolled-up and locked coins from unspents, puts them in a big pile, then rerolls them and locks them in new unspents. The old unspents are now spent and discarded as historical relics.

A transaction consists of a bit of metadata, one or more inputs, each of which is known as a TxIn (commonly known as a vin), and one or more outputs, each of which is known as a TxOut (or vout).

Transactions are named by their transaction ID, which is a 256-bit binary string, generally expressed as a 64-character hex id. Example:


This binary string is generated by streaming the transaction to a binary blob in a canonical way, then taking the sha256 hash of the blob twice. Note that by convention, the hex id is written in reverse, little-endian order.


A TxIn defines the input coins for a transaction. It points to unspent coins via transaction ID and the index of the TxOut. This TxOut must not be spent by any other confirmed transaction (this is called a “double-spend”, and is akin to offering the same ten dollar bill to two different people).

Each TxIn refers to exactly one unspent, and includes a solution script that corresponds to the unspent’s puzzle script, and “unlocks” it. If the unspent’s puzzle script is a lock, the solution script is a key – but a key that (usually) unlocks the coins only for the transaction the TxIn is embedded in.

To “unlock” the coins, the puzzle script must be solved. This generally requires knowing the private key corresponding to the public key, and creating a signature proving that the private key is known and approves the resultant transfer of coins expressed by the transaction. This is done by hashing parts of the transaction, including the TxOut list, and having the solution include a digital signature on that hash.


A TxOut defines the output coins of a transaction. It’s a structure that includes an integer representing the number of satoshis dedicated to this output and the puzzle script that protects these coins.

Each TxOut of a confirmed transaction corresponds to an unspent, that can be referred to by a TxIn in a future transaction (but only one!).


The total coins reassigned in the list of TxOut objects must be no greater than the coins collected up in the list of TxIn objects (or else coins can be created out of thin air). However, the TxOut total can be less than the TxIn total, in which case, the excess coins are a “fee” that can be collected by the miner that confirms the transaction, encouraging its confirmation. In practice, all transactions have a fee, and it is generally proportional to the size of the transaction in bytes.

Puzzle Script

A puzzle script is a program written in a non-Turing-complete language known as Bitcoin script. Bitcoin script is a low-level interpreted stack-based script language with opcodes that operate on the stack, with a few special opcodes tuned to verifying ECDSA digital cryptographic signatures.


Transactions are passed around the peer-to-peer Bitcoin network, and eventually reach validating nodes known as “miners”. Miners attempt to bundle transactions into a block using a proof-of-work trick that makes finding blocks a time-consuming process. Each block includes a reference to the previous block, forming a linked list-style data structure, known as a blockchain.

Although blocks are hard to find, their correctness is easy to verify. Once a block is found, it’s shared with peers on the network who can verify it’s correctness, accept the block as the next “ledger page” in the ledger, and begin trying to extend the blockchain by creating a new block that refers to the previous.


Mining is conceptually akin to this process: create a lottery ticket (a block that includes a list of transactions), check to see if the ticket is a winner, and repeat until a winner is found.

It’s quite simple to create a potential block candidate: assemble a list of validated transactions and increment a nonce until the block header starts with a sufficient number of zero bits.

Blocks contain a reward, consisting of a block reward that decreases over time (from 50 BTC, to 25 BTC, 12.5 BTC, etc., each step lasting about four years), plus all the fees from each transaction included in the block. All coins in existence can be traced back to the initial block in which they are generated as a reward for creating the block.


A bitcoin ECDSA private key is an integer between 1 and 115792089237316195423570985008687907852837564279074904382605163141518161494336 which is about 1.15e77 (inclusive). This number is called a “secret exponent”.

Each private key has a corresponding public key of the form (x, y) where x and y are 256-bit integers. Note that once x is determined, the y value is also determined to be one of two values Y1 or Y2, one of which is odd, the other of which is even. So it’s enough to specify the x value and the parity of y.

These public keys are streamed to a binary blob using the SEC standard, which defines a compressed (33-byte) and uncompressed (65-byte, legacy and generally no longer used) form. The 33-byte compressed form is 02 or 03 byte depending on y being even or odd, then the 32 bytes of x value. The 65-byte uncompressed form is a 04 byte, followed by the 32 bytes of x value, then the 32 bytes of y value.

Public Key Hash (PKH)

After public keys is formatted as a binary blob using the SEC standard, it is hashed twice: first to a 256 bit value using sha256, then that result is hashed to a 160 bit value using ripmd160. This value is called a hash160, or a public key hash (pkh).


Base 58 is frequently used by bitcoin to encode data that would otherwise be binary. It consists of the digits (10 characters), the upper case letter (26 characters), and the lower case letters (26 characters) EXCEPT 0 (zero), o (lower-case O), i (lower-case I) and l (lower case L). These characters were likely excluded due to their potential confusion with other similar-looking characters. Note that 10 + 26 + 26 - 4 = 58.


BIP32 (where BIP stands for “Bitcoin improvement proposal”) describes a way to create a hierarchical tree of private or public keys, where child keys can be derived by keys higher in the tree. For examples, please refer to the documentation for ku.