Digital Currencies & Blockchain

Lecture 3

• Mining
   
• Consensus Algorithms
   
• Bitcoin Core

Content

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

Node as a Server

Some examples of non-node clients that may use a node as a server:

• Users running a node to send and receive bitcoins.
• Wallets which manage keys, create transactions, and maybe keep some UTXO state associated with those keys but don’t have a copy of the blockchain and instead rely on a node to get up-to-date information.
• User-Facing Software Services and Applications such as block explorers, exchanges, and merchants that query full nodes for information and display them on a webpage or application.
• Developers creating nodes in regtest mode to test functionality or the interfaces themselves.
• Developer-Facing Software such as SDKs, APIs, and other interfaces. For example, the Bitcoin Core CLI (bitcoin-cli) uses the RPC interface to implement a command-line interface.

Node Map

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

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

Alternative Consens Mechanisms

Bitcoin Core

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

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.

Managing your wallet (CLI) III.

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

Exploring Transactions II.

• To retrieve the full transaction code we can use two commands:
  • getrawtransaction 
  • decoderawtransaction
• The getrawtransaction command uses the transaction ID as a parameter and returns the full transaction as a “raw” hex string, exactly as it is on the Bitcoin network.

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

Exploring Blocks

• We can retrieve block by index (“block height”), where “0” is the height of the Genesis block
   
• The Genesis block only contains one transaction (the coinbase transaction). Prior to the first Bitcoin transaction (found on block 170), all blocks only contained the coinbase transaction.

Multi Sig transactions

•  a MultiSig transaction must have multiple independent approvals before the funds can be spent.
  • Multi-signature  transactions prevent thieves from stealing the contents of a wallet by simply gaining access to a single key-pair.
• The most common scheme for multi-signature transactions is to employ an “M-of-N scheme”, for instance, 2-of-3, in which case, at least 2 people (i.e. signers) must approve a transaction.
  • The way this works is that 3 public keys are listed as potential signers of a transaction, and at least 2 of those must be used to create a transaction’s signature in order to spend it.
• There is currently a limitation of 15 public keys that can be used to sign a transaction, and any combination of the “M-of-N scheme” may be used.

Readings

• Andreas M. Antonopoulos: Mastering Bitcoin, Chapter 3 & 10

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