Blockchain Nanodegree Notes 20181031

Term 1 S3 Lesson 4: Blockchain Data

Lesson Introduction

By the End of This Lesson…

You will be able to…

• Recognize the data structure of blocks and transactions.
• Recognize the purpose of Bitcoin Script opcodes that are commonly used in the input and output parts of a transaction process.
• Explore the limitations and best practices of embedding data in blockchain transactions.

Blockchain Data Models Overview

Block Header

• Previous Block’s Hash - The hash value for the block that comes directly before a given block in the chain. This is what links blocks in the blockchain together
• Time - The time the block was created is also held in the header
• Merkle Root - The merkle root is a hash that represents every transaction included inside the block. To get the merkle root, pairs of transactions within a block are repeatedly hashed together. Each pair results in a single hash. Then the hash of 2 pairs of transactions are again hashed together, over and over again until you are left with a single hash value. Given that final hash value, known as the merkle root, you can now use the hash to search the original transactions or hash values that created them. This searching allows you to find the original transactions that made up the block when starting from this single hash value.
• Nonce - A nonce (stands for “number only used once") is a number used in bitcoin mining. The blockchain miners are solving for the nonce what when added to a hashed block, and those 2 values are rehashed, will solve the mining puzzle.

Block Body

• Transactions
  • Inputs
  • Outputs

Transactions

Transactions encode the transfer of value between participants in the system. In more detail, a transaction is a data structure that encodes a transfer of value from a source of funds called an “input” to a destination called an “output”.

Inputs in one transaction are just the unspent outputs from another transaction. All inputs reference back to an output. Unspent Outputs is sometimes short-handed to UTXO.

Transactions stored in the bitcoin blockchain are stored in a double-hashed form. This means the raw transaction was put through SHA256 twice to get the Transaction hash we see on the blockchain.

Transaction Fees

• Sum(Inputs)-Sum(Outputs)

Transaction Data models

• Version
• Input Count
• Input Info
• Output Count
• Output Info
• Locktime
  • Earlist time or block a Tx can be added to the blockchain.
  • If <500 million, read as block height
  • If >500 million, read as Unix Timestamp (the number of secounds since the data Jan 1, 1970)
  • usually zero, means ASAP

Input Info - Unlocking Sript;

Output Info - Locking Script

Bitcoin Scripts

Script

A list of instructions recorded in each transaction that when executed determined if the transaction is valid and the bitcoins can be spent.

• Stack-based language
• Stores Numbers (data constants)
• Uses Opcods
  • push(add)
  • pop(remove)
  • Etc.

Bitcoin Scripts

• Bitcoin Script Basics

• Unlocking and locking scripts

  • What are their purposes?
  • How do they work?
  • Where to find them?

  Verification is to solve the locking script using unlocking script

View a bitcoin transaction: https://live.blockcypher.com/btc/tx/b138360800cdc72248c3ca8dfd06de85913d1aac7f41b4fa54eb1f5a4a379081/

Script Opcodes

https://en.bitcoin.it/wiki/Script stack-based language

• OP_ADD (returns the sum)
• OP_EQUAL (returns True of False)

Standard Script Notation

Let’s discuss standard script notation using this example, <sig><pubKey> OP_CHECKMULTISIG

• Bracketed values are data to be pushed to the stack.
  • For example, <sig>.
• Non-bracketed words are opcodes.
  • For example, OP_CHECKMULTISIG
• Sometimes you may see the OP prefix omitted.
  • For example, <sig><pubKey> OP_CHECKMULTISIG may be abbreviated to <sig><pubKey> CHECKMULTISIG

Attributes of Script

Attributes of Script

• Turing Completeness: Not turing complete
  • No loops or complex flow control
  • Completely deterministic (we know how and when it ends)
  • Provides simplicity and security
• Stateless Verification
  • No state saved prior to or after the script executes
  • Script is self-contained
  • Provides predictability no matter where script is executed