Stanford CS251: Lecture 12

Recap: alt-coins Bitcoin is a replicated state machine, the system moves within S States with I inputs producing O outputs. For Bitcoin, S is the set of UTXOs. For Namecoin, the state consists (name, value). Ethereum’s goal was to implement this functionality in a general way by building a “consensus computer” expressed in a Turing-complete language. Ethereum State: Great arbitrary storage space, arbitrary code (isolated memory space), and account balance. Inputs: (address, input data) Transition: update storage and change account balance ...

Stanford CS251: Lecture 11

Lecture 11: Altcoins Three ways to improve Bitcoin Code update - This can update or change the P2P network Soft fork - To introduce a stricter verification for example P2SH Hard fork - transaction improvements and consensus change Altcoin = Any cryptocurrency except Bitcoin Launching an altcoin Sales pitch - new features Value/exchange rate Code Miners - the value of the currency will bring them or go for merge mining (explained below) Genesis block - For bootstrapping the right blockchain, it can be rooted in Bitcoin as well Examples, ...

Stanford CS251: Lecture 10

Lecture 10: Anonymity on Blockchain (Coinjoin continued from the previous lecture) Each participant writes an input transaction (input address, change address) on say Pastebin. Over Tor, each participant writes an output address. These two entries and not linkable to each other. Now, each participant signs a CoinJoin transaction only if they like their own input and output entries. Someone sends the final transaction to the miner. DoS attacks on CoinJoin: ...

Stanford CS251: Lecture 9

Lecture 9: Wallet & Anonymity Wallet A user has a lot of bitcoin address, each of which is H(p_k) or H(script). A wallet manages p_k/s_k, post/verify transactions, and show balances. A wallet can be Cloud wallets like Coinbase or desktop based like Electrum or hardware-based like Trezor. SPV or Simplified Payment Verification clients are not full mining nodes but can verify incoming payments. An SPV downloads all the block headers and then specifically requests a list of addresses which are in your wallet to fetch the transactions associated with those addresses from a server. The server returns the relevant transactions associated with those addresses and the corresponding Merkle proof of that. ...

Stanford CS251: Lecture 8

Lecture 8 - Alternative consensus Puzzle solutions are probabilistic proof of work. A typical puzzle utilization function can be modeled as P(challenge, randomness - nonce, difficulty, …) -> true/false P(c, r, d) for Bitcoin is SHA256^2(c, r, d) <= 2^256-d There are many objections to this. It wastes resources on a meaningless computation, it is highly parallelizable and has returns of scale, randomness, long wait time between blocks, and leads to the creation of the mining pools. It is possible to redesign the system to make mining pools impossible but that would lead to only big players doing the mining. The centralized signing also eliminates all these issues and “private blockchain” is just a misnomer for a centralized blockchain. ...

Stanford CS251: Lecture 7

Lecture 7: Community, Economics, and Politics David Chaum - digital cash in 1981 Satoshi Nakamoto - Oct 2008, bitcoin.org was registered in Aug 2008 Genesis block was mined in Jan 2009 First BTC payment - Feb 2010 First online exchange - July 2010, the price went up 10x by then First GPU miner - Aug 2010 First mining pool - Sep 2010, Satoshi disappeared at this point Silk road launched - Jan 2011 First BTC conference - Nov 2011 Bitcoin requires three levels of consensus ...

Stanford CS251: Lecture 6

Lecture 6: Bitcoin Miner interactions and Game Theory Game Theory: P x S -> R x P P: Players S: Strategies R: Rewards Examples For the prisoner’s dilemma, tit-for-tat with some positive randomization is the best strategy. Trench soldiers in World War 2 decided to start aiming artillery at random “safe” locations instead of killing the enemy. This all happened without any communication. Mechanism design: Design the rules of the game with the outcome you want. ...

Stanford CS251: Lecture 5

Lecture 5: Bitcoin mining How to mine Bitcoin Download and run Bitcoin-core to run full Bitcoin node Listen for a new transaction, assemble a pre-block Solve the puzzle (~270 attempts) Broadcast the block Profit The network runs on port 8333. Non-responding nodes are forgotten after 3 hours (5000-10000 nodes as of Sep 2016). Some seed nodes are hard-coded into the software. Zero transaction fee transactions were accepted until April 2012 before Satoshi Dice came around. Blocks are just an artifact of the mining process. Otherwise, it is just a stream of transactions. Changing the network layer is easy. Changing the protocol layer to add new opcodes is hard. ...

Stanford CS251: Lecture 4

Lecture 4: Blockchains 80 bytes block consists of 32 bytes previous block hash, 32 bytes transactions Merkle tree hash, timestamp, bits, nonce, etc. Each block is <= 1MB to minimize the propagation times. Therefore, large transactions require more service fee to compensate miners to include the transaction in the block. Miner’s transaction checks ScriptSig (from spending transaction) || ScriptPubKey (from funding transaction) executes and this should produce non-empty stack. Empty stack or zero is false. Transaction inputs are in the UTXO set. Sum of all outputs <= Sum of all inputs As of Oct 2016, 43M UTXO, 475K unique addresses, and 15.9M BTC in circulation. ...

Stanford CS251: Lecture 3

Lecture 3: Bitcoin overview There are three Bitcoin protocols Consensus Protocol - decides what the ledger is Transaction Protocol - assigns meaning to the ledger Network Protocol - the P2P protocol which decides what new should be added to the ledger Consensus Protocol Bitcoin fields (Virtual field) Hash - 4 bytes. SHA256-squared. This is not part of the block but is calculated on the fly. Version - 4 bytes. Set to 3 , might never change. Previous block - 32 bytes. Hash of the previous block on which we build this block. mrkl_root (Merkle root) - 32 bytes Time - 4 bytes. Timestamp of mining the block. Bits - 4 bits. This is the difficulty level. Lock time - 4 bytes. The transaction cannot be posted on the blockchain till the lock time constraint is met. Nonce - 4 bytes. Random nonce tweaked to find a block with the right difficulty. 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. ...