Transactions and Blocks

Slide 1

Slide 1 text

Bitcoin and Blockchain Technology Transactions and Blocks v2019.04.03 Comments, corrections, and questions: https://drive.google.com/open?id=1xEcBCyN3yLN40A3Ny8k-2PQ-xKJw1RlA © 2019 Digital Gold Institute

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Transactions ▪ Txs create new coins (transaction outputs TxOs) consuming existing unspent coins (UTxOs) which are used as transaction inputs (TxIns) ▪ Coinbase transactions create TxOs without TxIns ▪ The owner(s) of the TxIn coin(s) being spent must sign the Tx, for authentication (as legitimate owner) and integrity (Tx non being manipulated down the road) ▪ Txs can be created by any means, even offline, and can be propagated to the network even by non secure channels © 2019 Digital Gold Institute 6/99

Slide 7

Slide 7 text

TxOs and UTxO Pool ▪ TxOs are amount of bitcoins, recorded on the blockchain and associated to addresses ▪ Blockchain has neither accounts nor balances ▪ A given address usually has its associated bitcoins as (possibly many) TxOs scattered over (possibly many) blocks ▪ TxOs can only be spent once and fully as indivisible chunks ▪ bitcoins only exist as unspent TxOs (UTxOs) ▪ The UTxO pool is the LevelDB database cache used to record all current UTxOs © 2019 Digital Gold Institute 7/99

Slide 8

Slide 8 text

Unspent TxOs: Electrum Testnet ▪ 2 UTxO (2BTC + 1BTC) on the address tb1qhd92h3tac67u2merxvyu3nen6cgf5y2k8q24hd ▪ 1 UTxO each (2.99 and 43.59) on the two other addresses © 2019 Digital Gold Institute 8/99

Slide 9

Slide 9 text

Slide 10

Slide 10 text

TxOs Locking Puzzle ▪ Every TxO is locked by a mathematical puzzle (encumbrance), coded with Bitcoin Script language ▪ To spend the TxO, the corresponding TxIn must provide the solution to (i.e. unlock) the puzzle, again coded in Bitcoin Script language ▪ Unlocking a TxO puzzle usually involves a digital signature using the private key related to the address the TxO is associated to ▪ Scripts are smart contracts © 2019 Digital Gold Institute 10/99

Slide 11

Slide 11 text

TxIns Each TxIn must hold: ▪ the reference to the UTxO being spent: − hash pointer to the previous Tx (TxPrev) where the UTxO has been created − zero-based index identifying the UTxO among those created in TxPrev ▪ the unlocking solution of the UTxO mathematical puzzle (usually including private key signature) © 2019 Digital Gold Institute 11/99

Slide 12

Slide 12 text

nLockTime ▪ Earliest time that a transaction is valid and can be relayed on the network or added to the blockchain ▪ A transaction is finalized when its nLockTime has been reached − nLockTime < 500,000,000 it is interpreted as block number − nLockTime > 500,000,000 it is interpreted as Unix Epoch timestamp (number of second since Jan 1, 1970) ▪ A TxIn include a sequence number used to override a transaction prior to the expiration of its (nonzero) lock-time (nLockTime is ignored when the sequence numbers of all TxIns are set to UINT_MAX) © 2019 Digital Gold Institute 12/99

Slide 13

Slide 13 text

Transaction Validity All nodes validate all Txs before propagating them further. A Tx is valid if: 1. It can be finalized (i.e. it is not time locked) 2. Its TxIns reference UTxOs only 3. Each TxIn provides the unlocking solution for the mathematical puzzle of its referenced UTxO 4. The amounts of the newly generated TxOs is less than or equal to the amount of TxIns 5. ... © 2019 Digital Gold Institute 13/99

Slide 14

Slide 14 text

Slide 15

Slide 15 text

TxIns, TxOs, and Fees ▪ σ ≤ σ : the amounts of the newly generated TxOs must be less than or equal to the amount of TxIns ▪ σ − σ = : the difference between TxIns and TxOs is collected as additional fee reward in the coinbase transaction ▪ If the amount referenced by the used TxIns is greater than the amount of the intended transaction, a change must be sent to a change address ▪ The fee cannot be a TxO because the winning miner is not known at transaction time © 2019 Digital Gold Institute 15/99

Slide 16

Slide 16 text

Transaction Fees ▪ A minimum fee of 0.0001 BTC is used as disincentive against "spam" transactions or system abuse ▪ Fees are an incentive for miners to prioritize a transaction for inclusion in the next block, especially if blocks are full ▪ Fees depend on the size of the transaction in kilobytes, not the transaction value in BTC ▪ The way transaction fees are calculated and the effect they have on transaction prioritization has been evolving according to market forces © 2019 Digital Gold Institute 16/99

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Transaction Chaining and Orphans ▪ Transaction chaining: child transaction spends the outputs of the parent transaction, which has not been confirmed yet ▪ Child might arrive before parent: it is put in the orphan transaction pool while waiting for the arrival of its parent ▪ There is a limit MAX_ORPHAN_TRANSACTIONS to the number of orphan transactions stored in memory, to prevent a denial-of- service attack ▪ If a transaction is stuck because of a low fee, child-pay-for- parent means that a child transaction can pay enough fee for prioritizing both parent and child © 2019 Digital Gold Institute 18/99

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Stack Data Structure ▪ Based on the Last In First Out (LIFO) principle ▪ Operators push data on the top of the stack or pop out data from the top of the stack ▪ Conditional operators evaluate a condition, pushing a TRUE/FALSE result on the top of the stack © 2019 Digital Gold Institute 21/99

Slide 22

Slide 22 text

Bitcoin Script Language A very simple Forth-like language that uses reverse-polish notation 1. no loops or complex flow control capabilities 2. ensure termination, i.e. finite time execution (implied by 1) 3. memory access is stack-based: there are no variables, calculations are performed on the stack Bitcoin Script is purposefully stateless and not Turing-complete Limited flexibility is a deliberate security feature, preventing vulnerability from the transaction validation mechanism © 2019 Digital Gold Institute 22/99

Slide 23

Slide 23 text

Bitcoin Script Language: Rationale “The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.” (Satoshi Nakamoto) https://bitcointalk.org/index.php?topic=195.msg1611#msg1611 © 2019 Digital Gold Institute 23/99

Slide 24

Slide 24 text

Bitcoin Script Language: Goals Fundamentally different programming model than ordinary programming: it favors a verification, not computation, model − provability (prove proof in finite time) − solvability (Turing complete) It is possible to verify arbitrary code execution, without the need for Turing-completeness ▪ Computational efficiency (all nodes will verify the script: provide proofs, do not require excessive computation) ▪ Soundness (keep it simple: sophistication must not introduce attack vectors) ▪ Privacy ▪ Compactness (small impact on blockchain, less data also increases efficiency and privacy) © 2019 Digital Gold Institute 24/99

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Interactive Script Playgrounds ▪ https://siminchen.github.io/bitcoinIDE/build/editor.html ▪ Bitcoin Debug Script Execution https://webbtc.com/script ▪ convert Script to JavaScript http://www.crmarsh.com/script- playground/ © 2019 Digital Gold Institute 31/99

Slide 32

Slide 32 text

Operators 256 opcodes total (15 disabled, 75 reserved) ▪ Arithmetic ▪ If/then ▪ Logic/data handling ▪ Crypto − Hashes − Signature verification − Multi-signature verification © 2019 Digital Gold Institute 32/99

Slide 33

Slide 33 text

Operators ▪ OP_DUP duplicates the top stack value ▪ OP_HASH160 performs double hashing of the top stack value, first using SHA256 and then RIPEMD160 ▪ OP_HASH256 performs double hashing of the top stack value using SHA256 ▪ OP_EQUAL returns TRUE if the two top stack values are exactly equal, FALSE otherwise ▪ OP_VERIFY marks transaction as invalid if top stack value is not TRUE. The top stack value is removed. ▪ OP_EQUALVERIFY is equivalent to OP_EQUAL followed by OP_VERIFY ▪ OP_CHECKSIG checks that the input signature is a valid signature using the input public key for the hash of the current transaction ▪ OP_RETURN marks transaction as invalid. A standard way of attaching extra data to transactions is to add a zero-value TxO with a consisting of OP_RETURN followed by exactly one pushdata operator © 2019 Digital Gold Institute https://en.bitcoin.it/wiki/Script 33/99

Slide 34

Slide 34 text

Alternative to Script: e.g. Simplicity ▪ SegWit introduced the possibility of having alternative scripting languages, affecting only the involved transactions ▪ E.g.: Simplicity https://blockstream.com/2018/11/28/simplicity-github/ © 2019 Digital Gold Institute 34/99

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Transaction Script ▪ TxOs include a locking mathematical puzzle (usually including, in some way, the bitcoin address or the public key) ▪ The puzzle must be solved in order to spend the UTxO ▪ The spending TxIn provides unlocking solution (usually including, in some way, the private key signature) © 2019 Digital Gold Institute 36/99

Slide 37

Slide 37 text

Script Evaluation ▪ The Unlock+Lock script (+) is evaluated ▪ If the script fails or its result is FALSE then the TxIn is invalid ▪ A UTxO is unaffected by failed attempts to spend it ▪ A TxIn that satisfies the UTxO conditions does spend it: the TxO remains in the blockchain, but it is removed from the UTxO pool © 2019 Digital Gold Institute 37/99

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Standard Transactions Many different scripts are possible, but for security reason a transaction is usually relayed only if IsStandard(), i.e. ▪ does not violate good network behavior rules ▪ its scripts match a small set of believed-to-be-safe templates: − pay-to-public-key (P2PK, the easiest and oldest) − pay-to-public-key-hash (P2PKH, the most common) − null data (OP_RETURN) − multi-signature (limited to 15 keys) − pay-to-script-hash (P2SH, the most versatile) − {SegWit transactions} Valid non-standard transactions, if included in blocks, are accepted © 2019 Digital Gold Institute 39/99

Slide 40

Slide 40 text

Pay-To-Public-Key (P2PK) The first transaction type was Pay-To-Public-Key (P2PK) In the early days of Bitcoin ▪ coins were assigned to uncompressed Public keys ▪ spent using DER signatures © 2019 Digital Gold Institute 40/99

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Quantum Resistance Problem: to publish a public key on the blockchain is not quantum resistant, as such it is not future proof Solution: pay to the hash of the public key, publishing only the public key hash (i.e. the address) on the blockchain … or maybe not… © 2019 Digital Gold Institute 45/99

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Pay-To-Public-Key-Hash (P2PKH) ▪ Public keys are revealed at redemption time only ▪ Problem: multiple UTxOs associated to the same address would see their common public key revealed when the first UTxO is spent ▪ Solution: use a different address (i.e. public key) for each TxO! © 2019 Digital Gold Institute 54/99

Slide 55

Slide 55 text

Blockchain for Data Unrelated to Transactions ▪ The 20-byte destination address can be used to store any data in the blockchain, e.g. file hash for proof-of-existence of the file on the transaction date ▪ Blockchain as distributed and time-stamped ledger system for digital notary services, stock certificates, smart contracts, etc. Blockchain abuse or clever use? ▪ Waste: if the address does not correspond to a private key the UTxO can never be spent, associated bitcoins are lost ▪ Bloat: blockchain disk storage, UTxO cache RAM © 2019 Digital Gold Institute 55/99

Slide 56

Slide 56 text

A Better Approach: OP_RETURN ▪ 80 bytes of nonpayment data are allowed after OP_RETURN ▪ OP_RETURN forces the failure of any script including it; the associated TxO cannot be spent ▪ As such, its TxO is provably unspendable: it is stored in the blockchain but prunable from the UTxO pool (limited bloat) ▪ The TxO can have zero bitcoin associated (no waste) see www.eternitywall.com, www.eternitywall.com/notarize, and www.opentimestamps.org © 2019 Digital Gold Institute 56/99

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

▪ N ▪ ▪ … ▪ ▪ M ▪ ▪ … ▪ ▪ 0 ▪ OP_0 ▪ ▪ … ▪ ▪ ▪ ▪ … ▪ → ▪ OP_CHECKMULTISIGVERIFY OP_CHECKMULTISIG VERIFY bug: it consumes one extra ignored data element Fast forward here + © 2019 Digital Gold Institute Multisignature (M-of-N) Transaction TX_MULTISIG Stack 59/99

Slide 60

Slide 60 text

Slide 61

Slide 61 text

From TX_MULTISIG To TX_SCRIPTHASH TX_MULTISIG: up to 15-of-15 (1650 bytes signature script limit) Problems: ▪ Public keys are published on the blockchain ▪ A multisig is bigger than the P2PKH one ▪ Expensive for the sender, beneficial for the receiver Solution: create a new type of UTxO that shifts the burden into the redemption © 2019 Digital Gold Institute 61/99

Slide 62

Slide 62 text

From TX_MULTISIG To TX_SCRIPTHASH ▪ A 2-of-3 multising script is 65*2+3 bytes = 133 bytes <1 pubk1 pubk2 2 OP_CHECKMULTISIG> ▪ This redeem script can be represented by its much shorter 20 bytes HASH160: ▪ Lock the transaction with: OP_HASH160 OP_EQUAL ▪ Unlock with: <1 pubk1 pubk2 3 OP_CHECKMULTISIG> © 2019 Digital Gold Institute 62/99

Slide 63

Slide 63 text

BIP16 Pay-To-Script-Hash (P2SH) ▪ Move the script from TxO to TxIn ▪ Scripts are hashed and encoded as addresses: complex scripts are replaced by shorter fingerprints in the TxO ▪ Pay to a script matching this hash: script will be presented in the future to spend UTxO. A future spending TxIn will contain the redeem script whose hash is contained in the UTxO ▪ Sender does not handle the complexity of receiver’s policy ▪ Smaller in the (present) UTxO set, larger in the (future) blockchain ▪ Fee cost for a complex script is shifted from sender to recipient at future spending time ▪ Public keys and full script are revealed at redemption time only © 2019 Digital Gold Institute 63/99

Slide 64

Slide 64 text

BIP16 Pay-To-Script-Hash (P2SH) ▪ P2SH transactions can contain any valid script allowing for experimentation with new and complex types of transactions ▪ Transactions that redeem P2SH TxO are considered standard if the redeem script is, itself, one standard transaction type ▪ A TxO locked with the hash of an invalid script is valid, but cannot be spent with a valid TxIn ▪ P2SH can be nested without becoming recursive ▪ Redeem script cannot include OP_RETURN © 2019 Digital Gold Institute 64/99

Slide 65

Slide 65 text

P2SH Addresses (BIP16) ▪ Base58Check encode of a P2SH use version prefix of 5 (instead of 0), resulting in an address starting with a “3” (instead of “1”) ▪ P2SH “3” addresses designate the beneficiary of a bitcoin transaction as the hash of a script ▪ Bitcoins sent to “3” P2SH addresses require something more than the presentation of one public key (hash) and one private key signature to be spent ▪ Requirements are designated at the time the address is created, within the script © 2019 Digital Gold Institute 65/99

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

+ ▪ ▪ {[Pubkey] OP_CHECKSIG} → OP_HASH160 ▪ [20-byte-hash of {[Pubkey] OP_CHECKSIG}] ▪ OP_EQUAL Stack [20-byte-hash of {[pubkey] OP_CHECKSIG}] © 2019 Digital Gold Institute P2SH Example: Hash of a P2PK script 69/99

Slide 70

Slide 70 text

+ ▪ ▪ {[Pubkey] OP_CHECKSIG} ▪ OP_HASH160 → [20-byte-hash of {[Pubkey] OP_CHECKSIG}] ▪ OP_EQUAL Stack [20-byte-hash of {[pubkey] OP_CHECKSIG}] [20-byte-hash of {[pubkey] OP_CHECKSIG}] © 2019 Digital Gold Institute P2SH Example: Hash of a P2PK script 70/99

Slide 71

Slide 71 text

Slide 72

Slide 72 text

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

Slide 77

Slide 77 text

TxIn signature: Hash Type When signing TxIns, the sighash marker indicates which of the newly created TxOs are also covered by the signature 1. SIGHASH_ALL (default): all TxOs, so modifying any TxO would require the TxIn to be signed again 2. SIGHASH_NONE: no TxO, so all TxOs in the transaction can be changed (used in cooperative transaction construction) 3. SIGHASH_SINGLE: the equal index TxO (i.e. the TxO of the same index as the TxIn), so that one cannot be changed 2-3 does allow other TxIns to update their sequence numbers, 1 does not SIGHASH_ANYONECANPAY is combined with the previous ones to indicate which TxIn is covered by the signature: only the current TxIn if TRUE, all TxIns if FALSE © 2019 Digital Gold Institute 77/99

Slide 78

Slide 78 text

Transaction Malleability ▪ Transaction signature does not cover all the data in a transaction that is hashed to create the transaction hash ID ▪ One can alter a Tx, without changing the Tx economics (TxIn, TxOut, and spendability conditions), resulting in a different Tx ID e.g.: − DER-encoded ASN.1 octet representation (fixed by BIP66) − for every ECDSA signature (r, s), the signature (r, N-s) is a valid signature of the same message (fix with canonical low-s encoding) − is not signed and can be manipulated with additional data then removed with OP_DROP, etc. (fixed by SegWit) ▪ This breaks everything relying on Tx ID ▪ A transaction’s hash can be manipulated without altering © 2019 Digital Gold Institute 78/99

Slide 79

Slide 79 text

Segregated Witness (SegWit) "witness" is a solution to a cryptographic puzzle, e.g.: ▪ every TxIn in a transaction is followed by the witness data that unlocks its corresponging TxO. ▪ Segregated Witness moves the outside of the transaction data structure, into a separate witness data structure that complements the transaction ▪ Clients may request transaction data with or without the accompanying witness data. © 2019 Digital Gold Institute 79/99

Slide 80

Slide 80 text

SegWit Benefits ▪ Transaction malleability fix ▪ Signature verification optimization (linear scaling of sighash operations) ▪ Increased security for multisig via pay-to-script-hash (P2SH) ▪ Script versioning ▪ Network and storage scaling ▪ Offline signing improvement © 2019 Digital Gold Institute https://bitcoincore.org/en/2016/01/26/segwit-benefits/ 80/99

Slide 81

Slide 81 text

Slide 82

Slide 82 text

Slide 83

Slide 83 text

Merkelized Abstract Script Tree ▪ Scripts involves OR combinations of keys, lock-times, hash- locks, etc. and reveal all of them ▪ MAST introduces branches in script ▪ Merkle tree of scripts − TxO includes (and reveal) only the Merkle tree root − TxIn will include the spending script, the path along the tree to the root, and signatures ▪ Only reveal the actually used spending condition, not all the other alternatives © 2019 Digital Gold Institute 83/99

Slide 84

Slide 84 text

MAST Application: Taproot ▪ Tweak keys with redeem script hash : 2 = 1 + ℎℎ 1 || 2 = 1 + ℎℎ 1 || ▪ Pay-to-contract combines P2PK and P2SH, allowing to spend either using Pubkey or redeem script: − Key spending: sign with 2 − Script spending: 1 , , inputs ▪ Graftroot is an evolution of the above using delegation instead of Merkle Tree (requires interactive key setup) © 2019 Digital Gold Institute 84/99

Slide 85

Slide 85 text

Homework (1/2) ▪ Create a Hashlock transaction, i.e. an output locking script including a hash value, spendable with an input unlocking script composed only by the hash pre- image ▪ Preferably use the hash value with seven leading zero you obtained in the first lesson homework (hint: use OP_HASH265 and OP_EQUAL) ▪ Check the result with online script engines or python code ▪ Why is such a transaction not secure? (hint: who see your spending transaction? What attack could be performed? Why do we usually rely on asymmetric cryptography?) © 2019 Digital Gold Institute 85/99

Slide 86

Slide 86 text

Homework (2/2) ▪ See also: https://webbtc.com/tx/09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1 ▪ Study the script logic at: https://webbtc.com/script/09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1:0 © 2019 Digital Gold Institute 86/99

Slide 87

Slide 87 text

Slide 88

Slide 88 text

Transaction Bundling ▪ Transactions are bundled in blocks for practical reasons (shorter chain, single unit of work for validators, faster history validation) ▪ Transactions in a block are actually packaged in a Merkle Tree prev_hash nonce Tx Tx Tx prev_hash nonce Tx Tx Tx prev_hash nonce Tx Tx Tx prev_hash nonce Tx Tx Tx prev_hash nonce Tx Tx Tx © 2019 Digital Gold Institute 88/99

Slide 89

Slide 89 text

trans: H( ) prev: H( ) Block Structure trans: H( ) prev: H( ) trans: H( ) prev: H( ) H( ) H( ) H( ) H( ) H( ) H( ) transaction transaction transaction transaction Hash chain of blocks Hash tree (Merkle tree) of transactions in each block © 2019 Digital Gold Institute 89/99

Slide 90

Slide 90 text

Block structure Block size 4 bytes Block header 80 bytes Number of Transactions 1-9 bytes Transactions Variable bytes Block structure The average block contains more than 2000 transactions. The maximum block size, as fixed in Bitcoin Core, is 1MB Block header 80 bytes © 2019 Digital Gold Institute 90/99

Slide 91

Slide 91 text

Block size 4 bytes Block header 80 bytes Number of Transactions 1-9 bytes Transactions Variable bytes Block structure Field Description Size Version Block version number 4 bytes Previous block hash Reference to the hash of the previous block 32 bytes Timestamp Block time creation time (seconds from Unix Epoch) 4 bytes Difficulty target Nonce Merkle root Hash of the root of the Merkle tree of the block’s transaction 32 bytes New software is released A new block comes in Every few seconds A transaction is accepted Updated when Nonce Number used for the proof-of-work 4 bytes Partial Inversion Hash Puzzle is solved Block header 4 bytes Every 2016 blocks © 2019 Digital Gold Institute 91/99

Slide 92

Slide 92 text

Slide 93

Slide 93 text

Slide 94

Slide 94 text

Slide 95

Slide 95 text

Slide 96

Slide 96 text

Genesis Block https://blockchain.info/tx/4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b Number Of Transactions: 1; Difficulty: 1; Nonce: 2083236893; Block Reward: 50 BTC Hash: 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f Merkle Root: 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b The genesis block reward can't be spent due to a quirk in the way that the genesis block is expressed in the code. It is not known if this was intentional or an accident https://en.bitcoin.it/wiki/Genesis_block https://github.com/bitcoin/bitcoin/blob/9546a977d354b2ec6cd8455538e68fe4ba343a44/src/main.cpp#L1668 © 2019 Digital Gold Institute 96/99

Slide 97

Slide 97 text

Homework ▪ First halving: provide block height and hash pointer of the first 25BTC coinbase transaction ▪ Last halving: provide block height and hash pointer of the last halving coinbase transaction Hint: use https://blockstream.info, https://blockexplorer.com/ or any other block explorer © 2019 Digital Gold Institute 97/99

Slide 98

Slide 98 text

Bibliography ▪ A. Narayanan, et al., “Bitcoin and Cryptocurrency Technologies” http://bitcoinbook.cs.princeton.edu/ − chapter 3 «Mechanics of Bitcoin» ▪ Pedro Franco, “Understanding Bitcoin”, Wiley − chapter 6 «Transactions» − chapter 7 «The Blockchain» ▪ Andreas Antonopoulos, “Mastering Bitcoin” 2nd edition, O'Reilly https://github.com/bitcoinbook/bitcoinbook − chapter 6 «Transactions» − chapter 7 «Advanced Transactions and Scripting» − chapter 8 «The Blockchain» ▪ https://en.bitcoin.it/wiki/Script © 2019 Digital Gold Institute 98/99

Slide 99

Slide 99 text

Takeaways ▪ Bitcoin is programmable money: Script allows simple and powerful smart contracts ▪ Block headers are a succinct view of the blockchain data set ▪ The Bitcoin protocol has moved forward in term of privacy, security, and scalability ▪ SegWit fixed transaction malleability and added many improvement, it was not just block size increase © 2019 Digital Gold Institute 99/99

Slide 100

Slide 100 text

Ferdinando M. Ametrano Executive Director [email protected] Paolo Mazzocchi Chief Operating Officer [email protected] www.github.com/dginst www.facebook.com/DigitalGoldInstitute www.twitter.com/DigitalGoldInst www.dgi.org/feed.xml [email protected] www.dgi.io www.linkedin.com/company/digital-gold-institute "Scarcity in the Digital Realm"