Lecture 3: Bitcoin overview

There are three Bitcoin protocols

1. Consensus Protocol - decides what the ledger is
2. Transaction Protocol - assigns meaning to the ledger
3. Network Protocol - the P2P protocol which decides what new should be added to the ledger

Consensus Protocol

Bitcoin fields

1. (Virtual field) Hash - 4 bytes. SHA256-squared. This is not part of the block but is calculated on the fly.
2. Version - 4 bytes. Set to 3, might never change.
3. Previous block - 32 bytes. Hash of the previous block on which we build this block.
4. mrkl_root (Merkle root) - 32 bytes
5. Time - 4 bytes. Timestamp of mining the block.
6. Bits - 4 bits. This is the difficulty level.
7. Lock time - 4 bytes. The transaction cannot be posted on the blockchain till the lock time constraint is met.
8. Nonce - 4 bytes. Random nonce tweaked to find a block with the right difficulty.
9. n_tx & txn_data in the Merkle root are stored separately.

The nonce is only 32 bits, Changing that might not be sufficient to get the desired number of difficulty(70+ zeros). Therefore, changes can be made to the Coinbase transaction (explained below) to generate more randomness.

Block Validity Checks

1. Puzzle solution - fastest check
2. Correct difficulty
3. Previous block
4. The timestamp is plausible - (timestamp >2 hours local time or timestamp < median of last 11 blocks) then reject. A miner might want to collude and manipulate timestamps to keep the difficulty low - never happened but it is still a possibility.
5. Valid transaction data, including the coinbase transaction - transaction check is the slowest since that involves checking multiple signatures.

Blockchain Validity checks

1. The valid chain is the one that has the most difficulty in it. This is not the longest but is commonly referenced as the longest. The reason to prefer most work over longest is that anyone who is working in private can produce the longest chain with low difficulty.
2. Rooted in the genesis block - This is hardcoded in the Bitcoin mining software

A coinbase transaction is the first transaction of the block where the miner assigns new money to them based on the creation rate rules. It can contain an arbitrary string that can be changed to generate the hash of the desired difficulty. The order of transactions in the transaction Merkle tree also impacts the hash.

Difficulty calculation

Reset every 2016 blocks (= 2 weeks/10 minutes).

Dnew = Dold * (tLast - tFirst)/(14 * 24 * 60)

This has an off-on-one error; it should have been 20150 and not 20160. Difficulty goes up quickly. This cannot be changed, and it’s part of the Bitcoin ecosystem.

Transactions Merkle Tree

A binary tree with all the transactions in leaves. All parents are hashes of the children concatenated. This is stored outside the Bitcoin block hashes.

Transactions

Bitcoin has no notion of accounts and balances. Ethereum has. Bitcoin ledger consists of UTXO (unspent transaction outputs), which are outputs of a transaction. As soon as a UTXO is used as input for another transaction, it cannot be used again. Previous transaction output is referenced via its hash and an index into its outputs. Therefore, each transaction uses all the UTXO inputs. This UTXO set is growing pretty rapidly as well. Small-value UTXOs are nick-named dust.

Bitcoin is not limited to sending money to a public key address. All the money is spent via Bitcoin scripts. You send money to a function f(), and anyone who can produce an x such that f(x) is true can redeem it. The Bitcoin script is a stack-based language with no loops or backward jumps => code always finishes and is not Turing complete. It has no big number support or floating points either. What most transactions look like in theory is f(sig, key) { if key == k and verify(sig, key, transaction) { return true } }. This is expressed in a complicated Bitcoin script. This can be used for writing smart contracts. What happens in practice is more complicated. The UTXO (output transaction) has the redemption script “scriptPubKey” and the spending transaction (input transaction which is using the UTXO) specifies the signature “scriptSig”. Bitcoin VM runs “scriptSig || scriptPubKey” and waits for true as an output. Anything except true (including a crash) is a failure outcome. Try out the language here.

Some examples:

1. OP_TRUE - Anybody can spend the script.
2. <sig> <pubKey> - scriptSig and OP_DUP OP_HASH160 <pubkeyhash?> OP_EQUALVERIFY OP_CHECKSIG - scriptPubKey is the standard spending transaction.</pubkeyhash?>
3. OP_RETURN - Nobody can spend. Proof of burn to get something else in return. OP_RETURN can be followed by 40 bytes of the data on the chain permanently.
4. Multi-sig - k of n signers (joint control) or escrow.