Title Text

Digital Currencies & Blockchain

Lecture 2

• Blocks
   
• Transactions
   
• Bitcoin Script
   
• Mining & Consensus Algos
   
• Bitcoin Core

Bitcoin Protocol 

Blocks

Number of transactions: How many transactions the block contains
Height: The number of the block in the blockchain
Block Reward: The amount rewarded to the miner for computing the block
Timestamp: The time the block was added
Mined by: Who mined the block (Can appear anonymous)
Merkle Root: The combined hash of all the transactions in this block
Previous Block: The previous block’s hash
Difficulty: A value used to calculate how difficult the block is to solve (This value is adjusted every 2016 blocks to aim for » 10 minutes computation time)
Size: The total size of the block
Version: Signals to the rest of the network about intentions to update
Nonce: A value that is changed to find a solution for the block

Blocks II.

Block header

Genesis Block

Coinbase Transaction

Transactions

• The fundamental building block of a bitcoin transaction is a transaction output.
• UTXO --> indivisible chunks of bitcoin currency
• UTXO set - The collection of all UTXOs
  • grows as new UTXO is created and shrinks when UTXO is consumed.
• To receive bitcoins mean:
  • wallet has detected a UTXO that can be spent with one of the keys controlled by that wallet
• Wallet calculates balance by scanning blockchain and aggregating the value of any UTXO the wallet can spend .
  • via DB service to store a quick reference set of all the UTXO they can spend with the keys they control.

Transactions I.

• A transaction consumes previously recorded unspent transaction outputs and creates new transaction outputs that can be consumed by a future transaction.
• This way, chunks of bitcoin value move forward from owner to owner in a chain of transac‐ tions consuming and creating UTXO
• Only exception is COINBASE transaction --> first transaction in each block.
  • placed there by the “winning” miner and creates brand-new bitcoin payable to that miner as a reward for mining.
  • does not consume UTXO; instead, it has a special type of input called the “coinbase.”
  • This is how bitcoin’s money supply is created during the mining process
    • ​What comes first - Input or Output? Chicken or Egg?

Transactions II.

UTXO

Unspent Transaction Output
 

• An amount of bitcoin, denominated in satoshis, the smallest bitcoin unit
• A cryptographic puzzle that determines the conditions required to spend the output
  • a.k.a locking script, a witness script, or a scriptPubKey

UTXO consists of:

UTXO - Advantages 

• Simplicity: Spending a UTXO is all or nothing. Since UTXOs are uniquely referenced and completely consumed upon spending, there is no chance for a transaction to be replayed.
   
• Transactions can be trivially verified in parallel. It is impossible for two transactions to affect the same UTXO. This is due to the stateless nature of UTXO transactions. Transactions do not refer to any input outside of the UTXOs consumed and corresponding signatures.
   
• Privacy-preserving behavior is encouraged in the UTXO model. Users are encouraged to generate a new address for every incoming transaction including change addresses. By using a new address each time, it is difficult to definitively link different coins to a single owner.

UTXO - Disadvantages 

• UI/UX considerations are tricky. Users tend to think of accounts when they conceptualize their money. Since there is no concept of an account within Bitcoin, it is up to the wallet provider to manage a potential set of addresses and sum the corresponding balances. Doing so in a privacy-preserving way may require running a local node.
   
• Smart contract abilities are quite limited in a UTXO model. Each UTXO has spending criteria that dictates spending conditions. This can require signatures from multiple parties, but there is little ability to reference outside the state such as oracles.

Transacations

Transacations II.

Transacations III.

Transacations IV.

Transacations V.

• Compensate the bitcoin miners for securing the network
  • making it economically infeasible for attackers to flood the network with transactions
     
• Fees also serve as a security mechanism themselves
• Most wallets calculate and include transaction fees automatically
  • more inputs --> higher fee
• Calculated based on the size of the transaction in kilobytes, not the value of the transaction in bitcoin
• Fee market

Transaction fees:

• Bitcoin Script: 
  • A (simple) programming language
  • "script": an executable program - a list of instructions
  • A transaction is validated if the respective script is successfully executed
     
• The constituents of each script can be distinguished into two basic types:
  • Opcodes (commands/functions): begin with prefix 'OP_', e.g., 'OP_HASH160'
  • Data: store data related to transactions - appear within '<.>', e.g., '<pubKeyHash>'

Bitcoin Script

• Script is a Forth-like reverse polish notation, stack-based execution language, which is not Turing-complete and does not include loops.
   
• Forth is an imperative stack-based computer programming language and environment.
   
• Some applications of Forth
   
• Small ebook that helps you learn Forth.

Bitcoin Script II.

• uses a data structure called a stack.
• very simple data structure that can be visualized as a stack of cards.
• A stack allows two operations:
  • Push adds an item on top of the stack.
  • Pop removes the top item from the stack.
• Operations on a stack can only act on the topmost item on the stack.
• A stack data structure is also called a Last-In-First-Out, or “LIFO” queue.

Bitcoin Script III.

• Turing complete or computationally universal if it can be used to simulate any Turing machine
  
  
• The bitcoin transaction script language contains many operators, but is deliberately limited in one important way—there are no loops or complex flow control capabili‐ ties other than conditional flow control. This ensures that the language is not Turing Complete, meaning that scripts have limited complexity and predictable execution times. Script is not a general-purpose language. These limitations ensure that the lan‐ guage cannot be used to create an infinite loop or other form of “logic bomb” that could be embedded in a transaction in a way that causes a denial-of-service attack against the bitcoin network.
  
  
• Every Bitcoin Script will terminate in finite steps.

Turing incomplete

• The bitcoin transaction script language is stateless
• There is no state prior to execution of the script, or state saved after execution of the script.
• Therefore, all the information needed to execute a script is contained within the script.
• A script will predictably execute the same way on any system. If your system verifies a script, you can be sure that every other system in the bitcoin network will also verify the script, meaning that a valid transaction is valid for everyone and everyone knows this.
• This predictability of outcomes is an essential benefit of the bitcoin system.

Stateless Verification

• P2PKH: Pay To Public Key Hash
  • Public Key Hash refers to a bitcoin address
  • In other words, “send funds to this bitcoin address”
• Typical TX: Sender (S) sends some BTC to Receiver (R)
  • The underlying script for this transaction consists of two scripts:
    • scriptSig: <sig> <pubKey>
    • scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
  • S needs a private key, a public key and an address created from the public key (scriptSig)
  • Then, S creates a scriptPubKey using R's address
• The transaction is completed once the overall script is successfully evaluated
  • Overall script: concatenation of scriptSig and scriptPubKey
  • Successfully evaluated: 'True'

Most Common TXs

• Locking script:
  • spending condition placed on an output
  • it specifies the conditions that must be met to spend the output in the future
  • Called also scriptPubKey, because it usually contained a public key or bitcoin address (public key hash)
• Unlocking script
  • a script that “solves,” or satisfies, the conditions placed on an output
  • called also scriptSig because usually contains a digital signature produced by the user’s wallet
  • part of every transaction input

Script Construction (Lock +Unlock)

• Every  node validates transactions by executing the locking and unlocking scripts together.
• Each input contains an unlocking script and refers to a previously existing UTXO.
• The validation software will copy the unlocking script, retrieve the UTXO referenced by the input, and copy the locking script from that UTXO.
• The unlocking and locking script are then executed in sequence.
• The input is valid if the unlocking script satisfies the locking script conditions
• All the inputs are validated independently, as part of the overall validation of the transaction

Script Verification 

• Initially, P2PK - Pay to Public Key
   
• Now - P2PKH - Pay to Public key hash = bitcoin address
   
• An output locked by a P2PKH script can be unlocked (spent) by presenting a public key and a digital signature created by the corresponding private key

BTC Address

Public Key to BTC Address

• P2PK - Pay To Public Key
  • ​Original format
  • Privacy issues and waste of blockspace​
• P2PKH - Pay to Public Key Hash
  • ​addresses that start with "1"
  • when spending from this address sender needs to reveal PK
• P2SH - Pay to Script Hash
  • An elegant solution for more complex unlocking scripts (timelock, multisig)
  • hides script (created by the receiver), saves space & fees,
  • Addresses that start with "3"
• Bech32
  • ​Native Segwit - the latest form of addresses
  • saves block space
  • start with "bc1"

Evolution of BTC addressess

• OP_DUP - Duplicates the top stack item
• OP_HASH160 - The input is hashed twice: first with SHA-256 and then with RIPEMD-160
• OP_EQUALVERIFY -Same as OP_EQUAL, but runs OP_VERIFY afterward
• OP_EQUAL - Returns 1 if the inputs are exactly equal, 0 otherwise
• OP_CHECKSIG -The entire transaction's outputs, inputs, and script are hashed. The signature used by OP_CHECKSIG must be a valid signature for this hash and public key. If it is, 1 is returned, 0 otherwise ​

Transaction locking script

Alice --> Bob's cafe

Two scripts together:

Unlocking script

Text

• When executed, this combined script will evaluate to TRUE if, and only if, the unlocking script matches the conditions set by the locking script.
• In other words, the result will be TRUE if the unlocking script has a valid signature from the cafe’s private key that corresponds to the public key hash set as an encumbrance.

OP_RETURN

Text

• is a script opcode used to mark a transaction output as invalid. Since any outputs with OP_RETURN are provably unspendable, OP_RETURN outputs can be used to burn bitcoins.
   
• Many members of the Bitcoin community believe that use of OP_RETURN is irresponsible in part because Bitcoin was intended to provide a record for financial transactions, not a record for arbitrary data. Additionally, it is trivially obvious that the demand for external, massively-replicated data store is essentially infinite. Despite this, OP_RETURN has the advantage of not creating bogus UTXO entries, compared to some other ways of storing data in the blockchain.
   
• OP_RETURN can be used for digital asset proof-of-ownership, and has at times been used to convey additional information needed to send transactions

Reading:

Bitcoin Wiki Script:

 https://en.bitcoin.it/wiki/Script

    Playgrounds:
1  - https://www.crmarsh.com/script-playground/

2 - https://github.com/siminchen/bitcoinIDE

Bitcoin Script Resources:

• Elliptic Curve Digital Signature Algorithm
   
• A digital signature is a mathematical scheme that consists of two parts. The first part is an algorithm for creating a signature, using a private key (the signing key), from a message (the transaction). The second part is an algorithm that allows anyone to ver‐ ify the signature, given also the message and a public key.

Digital Signatures (ECDSA)

 ECDSA - Secp256k1

• Proves that the owner of the private key, who is by implication the owner of the funds, has authorized the spending of those funds.
   
• The proof of authorization is undeniable (nonrepudiation).
   
• The signature proves that the transaction (or specific parts of the transaction) have not and cannot be modified by anyone after it has been signed.

Digital Signatures (ECDSA) II.

3 key functions:

Transaction details

Balance

•  There is no concept of a “balance” --> values are constructed by the blockchain explorer
• “Total Received” --> explorer first decodes the Base58Check encoding of the bitcoin address to retrieve the 160-bit hash of Bob’s public key that is encoded within the address.
• Then, it searches through the database of transactions, looking for outputs with P2PKH locking scripts that contain Bob’s public key hash.
  • -->summing up the value of all the outputs

• Node incentivization via new bitcoins
   
• The mechanism to reach CONSENSUS
   
• Securing the ledger

Purpose of Mining

• The purpose of the bitcoin network is to propagate transactions and blocks to all participants
   
• Any bitcoin node that receives a valid transaction it has not seen before will immediately PROPAGATE it to all other nodes to which it is connected

Adding transaction to the Ledger

• Mining nodes validate all transactions by reference to bitcoin’s consensus rules. Therefore, mining provides security for bitcoin transactions by rejecting invalid or malformed transactions.
   
• Mining creates new bitcoins in each block, almost like a central bank printing new money. The amount of bitcoin created per block is limited and diminishes with time, following a fixed issuance schedule.
   
• Miners solve a cryptographic puzzle (PC --> GPU --> ASIC)

Mining

• New transactions constantly flow into the network
  -->seen by the network nodes --> they add them to temporary pool of unverified transactions maintained by each node --> MEMPOOL
   
• As miners construct a new block, they add unverified transactions from this pool to the new block and then attempt to prove the validity of that new block, with the mining algorithm (Proof-of-Work)
   
• Each miner starts the process of mining a new block of transactions as soon as he receives the previous block from the network, knowing he has lost that previous round of competition

Mining II.

Transaction Confirmation Overview

Link:
https://teachbitcoin.io/presentations/confirmation_model.html#/

Block Rules

• Each block is chained to a parent block
• Each block meet its difficulty target and has sufficient proof of work
• Block timestamps fall in a window relative to recent blocks
• The Merkle root matches the block’s transactions
• No blocks were larger than the allowed maximum size
• Each block’s first (and only first) transaction is a coinbase transaction
• Coinbase outputs don’t pay more than the appropriate block reward
• No blocks contained more than the allowed signature operations

Transaction Rules

• Input and output values are sane
   
• Transactions only spend unspent outputs
   
• All inputs being spent have valid signatures
   
• No coinbase transaction outputs were spent within 100 blocks of their creation.
   
• No transactions spend inputs with a locktime before the block in which they are confirmed.

More rules at:
https://en.bitcoin.it/wiki/Protocol_rules

Mining Pools

Cambridge Bitcoin Electricity Consumption Index

https://www.cbeci.org/

Blockchain Simulation:

1. https://anders.com/blockchain/public-private-keys/keys.html

2. https://anders.com/blockchain/hash.html

Full Nodes make sure that

• Nobody has inflated the monetary supply except for miners, and only according to a well-defined schedule
   
• Nobody ever spent money without having the appropriate private key(s).
   
• Nobody ever spent the same money twice.

Node Stratification

• Full Node = a node that is capable of validating transactions and blocks. Instead of searching through the blocks database every time, full nodes keep some state, i.e. a UTXO (unspent transaction output or “coins”) set.
  • Pruning Nodes: download and process blocks to build the necessary databases for validation, then discard the old blocks to save disk space. Since they have all of the information and can validate all new blocks and transactions, they are full nodes.
  • Archive Node = a node that has a copy of the entire history of the blockchain. These nodes are capable of validating incoming transactions and blocks, as well as querying block and transaction data from any point in history, including those that are no longer relevant to validation (hence the naming “archive”). It’s crucial that archive nodes exist, as new nodes need to catch up on the entire history in order to become full nodes. They can only do so by downloading the history, one block at a time, from archive nodes.

Node Stratification II.

• Mining Node = a node that produces new blocks. This involves keeping a mempool of unconfirmed transactions, validating new transactions, and solving the Proof-of-Work hash puzzle (i.e. finding the nonce) to construct a block. Mining nodes often use extra hardware to assist them in solving the hash puzzle (e.g. ASICs) or participate in mining pools.
  • Technically, there are also non-full nodes that join a mining pool, connect to a full node that manages the pool, and help solve PoW on a block without doing any validation (so there are mining but non-full nodes)

Node Stratification III.

• Light Clients = generic term for a node that doesn’t keep the full state necessary for full validation and instead trusts other full nodes to do so. A light client may keep a limited amount of data in order to verify its own transactions, but not fully validate all blocks.
  • Within Bitcoin Core, “light client” is often used synonymously with Simplified Payment Verification (SPV) Nodes, and not to be confused with Pruning Nodes. In some contexts, these aren’t called “nodes” because they don’t do most of the things [full] nodes usually do.

1. New TX is broadcasted
 

2. Each node collects TXs into a block
 

3. In each "round" a random node is selected to decide what is
"truth"

4. Other nodes accept/reject the block based on predefined criteria
 

5. Block acceptance is expressed by including its hash into the next block they build upon

Blockchain Synchronisation

Hard Fork

- Bitcoin Cash creation in 2017

Soft Fork

• Proof of Stake

• Delegated Proof of Stake

• Proof of Authority

• Proof of Importance

• Proof of Burn

• Proof of Activity

• Proof of Elapsed Time

• Federated Consensus

• Practical Byzantine Fault Tolerance

• and many more

Alternative Consens Mechanisms

PoW vs PoS

History of Consensus Algorithms

Bitcoin Core

• Initially, developed by Satoshi Nakamoto
• Now supported by a team of developers: https://github.com/bitcoin/bitcoin
• Main functionality at a glance:
  • Execute transactions verification
  • Connect to the Bitcoin network
  • Manage wallet that enables the transfer of bitcoins
• Main programs
  • Bitcoin Core (formerly Bitcoin-Qt): Graphical User Interface (GUI) front-end
  • bitcoind: deamon, i.e., command line program
  • bitcoin-cli: command line program interface for interacting with bitcoind (client)
    • Via remote procedure call (RPC)-based commands
    • The responses of bitcoind are in JSON format

Bitcoin Core

• You can download the appropriate Bitcoin installer from https://bitcoin.org/en/download
   
• After installation you will have to wait until the initial synchronization of the entire Bitcoin blockchain is done, which may take, depending on your bandwidth and the number of connected Bitcoin nodes, several days

Local Files

• bitcoin.conf file: configuration file
• wallet.dat file: Bitcoin wallet of mainnet
• blocks directory: blocks of mainnet
• chainstate directory: chain of blocks of mainnet
• testnet3 directory: all testnet files and directories

GUI & CLI II.

• The complete reference to the Bitcoin client Application Programming Interface (API) can be found here: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
   
• Using the command line interface you can:
  • Get information about the status of the Bitcoin network
  • Manage your wallet
  • Explore and decode transactions
  • Explore blocks
  • Create, sign and submit transactions with unspent outputs

Wallet Service

Bitcoin and Lightning 

from the Commnad Line

Link:

https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line

Commands

Managing your wallet (CLI)

Managing your wallet (CLI) II.

Exploring Transactions

• Transaction IDs (txid) are not authoritative until a transaction has been confirmed. Absence of a transaction hash in the blockchain does not mean the transaction was not processed.
  
  
  
   
• This is known as “transaction malleability”, as transaction hashes can be modified prior to confirmation in a block. After confirmation, the txid is immutable and authoritative.
   
• Fixed with Segwit

Confirmed transaction

• Once the transaction is confirmed, by inclusion in the block, the gettransaction command returns additional information, showing the block hash (identifier) and block index for the block in which the transaction was included.

Escrow Transactions

• Escrow transactions can be implemented using MULTISIG
  In 2-of-3 multisig :
  1. Find a relatively trustworthy escrowr (Arbitrator).
  2. Create a multisig address requiring 2 signatures out of the buyer, seller and mediator.
  3. Buyer sends funds to this address.
  4. Seller ships the product.
  5. When the product arrives, buyer and seller sign a tx sending funds to seller.
  7. If the product doesn't arrive, mediator verifies this fact, and buyer and mediator sign a tx sending funds to buyer.
  8. If the product arrives but buyer refuses to pay, mediator verifies this fact, and seller and mediator sign a tx sending funds to seller.

Trustless Escrow 

• The buyer commits a payment to escrow.

• The seller receives a transaction with the money in escrow, but he can’t spend it until the buyer unlocks it.

• The buyer can release the payment at any time after that, which could be never.

  • This does not allow the buyer to take the money back, but it does give him the option to burn the money by never releasing it.

• The seller has the option to release the money back to the buyer.

  • While this system does not guarantee the parties against loss, it takes the profit out of cheating. If the seller doesn’t send the goods, he doesn’t get paid.

  • The buyer would still be out the money, but at least the seller has no monetary motivation to cheat.

• The buyer can’t benefit by failing to pay. He can’t get the escrow money back. He can’t fail to pay due to lack of funds.

• The seller can see that the funds are committed to his key and can’t be sent to anyone else.”

• Mastering Bitcoin - Chapters 2, 6, 3 and 10

Optional Articles: 

• Annotated BTC WP: https://medium.com/coinmonks/bitcoin-white-paper-down-into-the-rabbit-hole-efbaeba3a83e
• Bitcoin Network: https://medium.com/@gloriazhao/map-of-the-bitcoin-network-c6f2619a76f3
• Tech Essentials: https://nakamoto.com/introduction-to-cryptocurrency/
• Blockchain vs Database: https://hackernoon.com/databases-and-blockchains-the-difference-is-in-their-purpose-and-design-56ba6335778b

Reading:

• Installing Bitcoin Core: https://en.bitcoin.it/wiki/Help:Installing_Bitcoin_Core
• How to Guide: 
• https://medium.com/@CoinMeteor/how-to-set-up-the-bitcoin-core-wallet-client-for-beginners-and-send-your-first-transaction-819c6d5b9790
• G. Maxwell Presentation on Bitcoin Core (2017): https://people.xiph.org/~greg/gmaxwell-sf-015-2017.pdf

Sources:

• Bitcoin Tech explained: https://learnmeabitcoin.com/ 
   
• Script Playground - https://www.crmarsh.com/script-playground
   
• Bitcoin Script for Dummies: https://github.com/siminchen/bitcoinIDE
   
• Bitcoin Wiki Script: https://en.bitcoin.it/wiki/Script

Extras

• Contact: david@fumbi.network
   
• Evolution of the Bitcoin protocol:
  https://coinstory.tech/book/chapter-06-evolution-of-the-bitcoin-protocol/

Thank you!