A Bitcoin Primer
================

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

Overview
--------

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*).

Unspents
--------

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.

Transactions
------------

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::

 0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098

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.


TxIn
----

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.


TxOut
-----

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!).


Fees
----

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.


Block
-----

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
------

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.


ECDSA Keys
----------

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).


Base58
------

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
-----

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`.
