This unit is Part 3 of the Annotated Princeton Bitcoin Video Course.

Introduction (1 minute)

Up until now the material has discussed Bitcoin in general terms. This unit examines Bitcoin in low-level technical detail. We’ll see real data structures, and real scripts.

Bitcoin Transactions (11 minutes)

Bitcoin requires a way for users to know who owns what. One of two conceptual models could be used:

1. Account Model. Money is debited/credited from one account to another. This is not how Bitcoin works.
2. Coin Model. Users transfer value by transferring ownership of one or more coins. This is Bitcoin’s model.

Although both methods work (Bitcoin uses the coin model and Ethereum uses the account model), the coin model is simpler to implement and test.

The coin model requires four features:

1. Each coin requires a unique ID and face value.
2. A coin is completely spent in a transaction.
3. Coin value can split. The main reason would be to receive change.
4. Coin value can be combined in case a user has no single coin sufficient to make payment.

The structure of a Bitcoin transaction directly supports the coin model. Each transaction is composed of three sections:

1. header: This includes basic housekeeping information such as version.
2. list of outputs: An output creates a coin. Included are a face value and a locking condition. Many sources use the terms “output” and “coin” interchangeably.
3. list of inputs: An input spends a coin. Included are the coin’s unique ID and an unlocking condition. The unique ID includes the hash value of a previous transaction and the zero-based index of the output being spent.

Locking and unlocking conditions are defined through Bitcoin’s built-in programming language, which is the topic of the next section.

Bitcoin Scripts (15 minutes)

Script is Bitcoin’s built-in programming language. It was created specifically for Bitcoin and has been present since the first release. Script is a stack-based language similar to Forth. Script’s functionality is deliberately minimal.

Scripts are executed any time a node validates a transaction. The input script is run first, followed by the output script. Validation succeeds is the combined script leaves a non-zero value on the stack.

Since the video was published, much more complex scripts have begun to be used. One of the best-known examples is Lightning Network, which began operation on the Bitcoin mainnet in 2018.

Owning Bitcoin describes Script and the role it plays in Lightning Network and other advanced applications in detail.

Applications of Bitcoin Scripts (14 minutes)

Script offers a wide range of functionality through contracts. A contract is one or more transactions passed among parties outside of the block chain, often in invalid or unsigned state.

A number of possible applications are possible, three of which are detailed in this unit:

1. escrow. A coin is lock in a way that signatures from two out of three parties are needed to unlock it: a payer; a payee; and an arbitrator. Payer and payee can jointly spend without the arbitrator. Alternatively, either payer or payee can work with the arbitrator to resolve disputes.
2. green addresses. Here a third party pledges never to sign a double spend. This increases the security of unconfirmed transactions, at least in principle. In practice, green addresses are rarely used.
3. payment channels. Payer and payee lock a coin such that both signatures are required to spend. Money is spent when the payer sends a new half-signed transaction updating output values in such a way that the payee receives more money.

Advanced Script applications are described in detail in Owning Bitcoin.

Bitcoin Blocks (5 minutes)

Blocks are generated at an average rate of one very ten minutes. If a block could hold only one transaction, then throughput would be impractical. Throughput is increased by bundling multiple transactions into a block.

This video looks at the structure of a block:

• header: data relevant to hash puzzle and the only thing hashed during mining.
• transaction data: referenced in the block header by Merkle root. The coinbase transaction pays the node that generated a block.

The Bitcoin Network (18 minutes)

Nodes can join the network and leave at any time. There is no central point of coordination.This kind of network is known as a P2P network.

Every message (block or transaction) starts with a single node, which relays the message to the nodes it knows about (peers). Those peers relay the message to their peers, and so on. The overall result is known as propagation. Invalid messages are not relayed, saving network bandwidth, storage, and CPU power.

Whereas block generation is governed by the distributed consensus protocol, message passing is virtually unregulated. A node receiving an invalid block or transaction from a peer simply ignores it and refuses to relay it. Under certain conditions, a node can disconnect from a peer that sends many invalid messages.

Due to this lack of regulation, it’s possible for different parts of the message to have different pending transaction sets and recent blocks.

A fully validating node stores all valid block headers and transactions. In mid-2018 the size of the block chain stands at over 165 GB. This size imposes very demanding technical requirements on network nodes in terms of bandwidth, storage space, and CPU power.

Alternatively a node can store just block headers and interesting transactions. This approach is known by the general term simplified payment verification (SPV). The complete set of 80-byte block headers as of mid-2018 requires only about 37 MB, a large savings compared to storing all transactions.

Limitations & Improvements (11 minutes)

Bitcoin uses several hard coded properties, including: the block interval; the block size limit; the reward schedule; the signature algorithm, and hash functions. These properties can be changed.

The software industry has developed two terms to describe upgrades: forward-compatible and backward-compatible. These terms are often used in the context of changes made to a file format. Existing software installations can use a new backward-compatible file format without upgrading. In contrast, existing software installations must be upgraded to use a new forward-compatible file format.

A similar concept applies in Bitcoin. There are two possible types of upgrade to the block chain format, forward- and backward-compatible. Bitcoin uses special terminology around these changes:

• hard fork: protocol rules are relaxed in a forward-compatible way
• soft fork: protocol rules are constrained in a backward-compatible way

Both kinds of updates have occurred on the Bitcoin network. Soft fork updates include P2SH, OP_CHECKLOCKTIMEVERIFY, and OP_CHECKSEQUENCEVERIFY. Hard fork updates include Bitcoin Cash, Bitcoin Gold, and a host of other “forkcoins.”

Next Up: How to Store and Use Bitcoin