Transactions and Blocks

Fifth lesson for the Bitcoin and Blockchain Technology course of Milano-Bicocca and Politecnico di Milano

www.ametrano.net/bbt/

Transcript

1. 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
2. First Transaction, From Satoshi to Hal Finney © 2019 Digital Gold Institute https://blockchain.info/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16 2/99
3. First Bitcoin Purchase: 2 Pizzas for BTC10,000 © 2019 Digital Gold Institute https://bitcointalk.org/index.php?topic=137.msg1195#msg1 3/99
4. First Bitcoin Purchase: 2 Pizzas for BTC10,000 © 2019 Digital Gold Institute https://blockchain.info/tx/a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d 4/99
5. Table of Contents 1. TxIns, TxOs, and UTxOs 2. Bitcoin Script Language 3. Standard Transaction Scripts 4. Transactions: Signatures and Smart Contracts 5. Blocks © 2019 Digital Gold Institute 5/99
6. 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
7. 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
8. 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
9. TxIns reference and spend UTxOs Software can empower the user with coin control, i.e. picking TxIns © 2019 Digital Gold Institute 9/99
10. 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
11. 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
12. 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
13. 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
14. © 2019 Digital Gold Institute https://blockstream.info/tx/5a42590fbe0a90ee8e8747244d6c84f0db1a3a24e8f1b95b10c9e050990b8b6b A Bitcoin Transaction 14/99
15. 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
16. 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
17. © 2019 Digital Gold Institute Transaction Fees https://blockchain.info/charts/transaction-fees?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address 17/99
18. 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
19. Replace By Fee (BIP125) ▪ RBF allows replacing a 0-confirmations transaction by transmitting another transaction with a higher fee ▪ RBF is opt-in © 2019 Digital Gold Institute 19/99
20. Table of Contents 1. TxIns, TxOs, and UTxOs 2. Bitcoin Script Language 3. Standard Transaction Scripts 4. Transactions: Signatures and Smart Contracts 5. Blocks © 2019 Digital Gold Institute 20/99
21. 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
22. 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
23. 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
24. 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
25. Verify 2+3=5 Using Script 2 3 OP_ADD 5 OP_EQUAL ▪ 2 ▪ 3 ▪ OP_ADD ▪ 5 ▪ OP_EQUAL Stack © 2019 Digital Gold Institute 25/99
26. Verify 2+3=5 Using Script 2 3 OP_ADD 5 OP_EQUAL → 2 ▪ 3 ▪ OP_ADD ▪ 5 ▪ OP_EQUAL Stack ▪ 2 © 2019 Digital Gold Institute 26/99
27. Verify 2+3=5 Using Script 2 3 OP_ADD 5 OP_EQUAL ▪ 2 → 3 ▪ OP_ADD ▪ 5 ▪ OP_EQUAL Stack ▪ 3 ▪ 2 © 2019 Digital Gold Institute 27/99
28. Verify 2+3=5 Using Script 2 3 OP_ADD 5 OP_EQUAL ▪ 2 ▪ 3 → OP_ADD ▪ 5 ▪ OP_EQUAL Stack ▪ 5 © 2019 Digital Gold Institute 28/99
29. Verify 2+3=5 Using Script 2 3 OP_ADD 5 OP_EQUAL ▪ 2 ▪ 3 ▪ OP_ADD → 5 ▪ OP_EQUAL Stack ▪ 5 ▪ 5 © 2019 Digital Gold Institute 29/99
30. Verify 2+3=5 Using Script 2 3 OP_ADD 5 OP_EQUAL ▪ 2 ▪ 3 ▪ OP_ADD ▪ 5 → OP_EQUAL Stack ▪ TRUE © 2019 Digital Gold Institute 30/99
31. 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
32. 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
33. 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 <scriptPubKey> consisting of OP_RETURN followed by exactly one pushdata operator © 2019 Digital Gold Institute https://en.bitcoin.it/wiki/Script 33/99
34. 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
35. Table of Contents 1. TxIns, TxOs, and UTxOs 2. Bitcoin Script Language 3. Standard Transaction Scripts 4. Transactions: Signatures and Smart Contracts 5. Blocks © 2019 Digital Gold Institute 35/99
36. Transaction Script ▪ TxOs include a <scriptPubKey> 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 <scriptSig> unlocking solution (usually including, in some way, the private key signature) © 2019 Digital Gold Institute 36/99
37. Script Evaluation ▪ The Unlock+Lock script (<scriptSig>+<scriptPubKey>) 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
38. Script Execution Scripts are not really concatenated anymore: executed separately for security reason, stack being transferred between the two © 2019 Digital Gold Institute 38/99
39. 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
40. 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
41. Pay-To-Public-Key (P2PK): TX_PUBKEY ▪ <sig> ▪ <PubKey> ▪ OP_CHECKSIG Stack © 2019 Digital Gold Institute <scriptSig> + <scriptPubKey> 41/99
42. Pay-To-Public-Key (P2PK): TX_PUBKEY → <sig> ▪ <PubKey> ▪ OP_CHECKSIG Stack ▪ <sig> © 2019 Digital Gold Institute <scriptSig> + <scriptPubKey> 42/99
43. Pay-To-Public-Key (P2PK): TX_PUBKEY ▪ <sig> → <PubKey> ▪ OP_CHECKSIG Stack ▪ <pubKey> ▪ <sig> © 2019 Digital Gold Institute <scriptSig> + <scriptPubKey> 43/99
44. Pay-To-Public-Key (P2PK): TX_PUBKEY ▪ <sig> ▪ <PubKey> → OP_CHECKSIG Stack ▪ TRUE © 2019 Digital Gold Institute <scriptSig> + <scriptPubKey> 44/99
45. 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
46. Pay-To-Public-Key-Hash (P2PKH) TX_PUBKEYHASH <scriptSig> + <scriptPubKey> ▪ <sig> ▪ <PubKey> ▪ OP_DUP ▪ OP_HASH160 ▪ <PubKeyHash> ▪ OP_EQUALVERIFY ▪ OP_CHECKSIG Stack © 2019 Digital Gold Institute 46/99
47. Pay-To-Public-Key-Hash (P2PKH) TX_PUBKEYHASH → <sig> ▪ <PubKey> ▪ OP_DUP ▪ OP_HASH160 ▪ <PubKeyHash> ▪ OP_EQUALVERIFY ▪ OP_CHECKSIG Stack ▪ <sig> © 2019 Digital Gold Institute <scriptSig> + <scriptPubKey> 47/99
48. Pay-To-Public-Key-Hash (P2PKH) TX_PUBKEYHASH ▪ <sig> → <PubKey> ▪ OP_DUP ▪ OP_HASH160 ▪ <PubKeyHash> ▪ OP_EQUALVERIFY ▪ OP_CHECKSIG Stack ▪ <pubKey> ▪ <sig> © 2019 Digital Gold Institute <scriptSig> + <scriptPubKey> 48/99
49. Pay-To-Public-Key-Hash (P2PKH) TX_PUBKEYHASH ▪ <sig> ▪ <PubKey> → OP_DUP ▪ OP_HASH160 ▪ <PubKeyHash> ▪ OP_EQUALVERIFY ▪ OP_CHECKSIG Stack ▪ <pubKey> ▪ <pubKey> ▪ <sig> © 2019 Digital Gold Institute <scriptSig> + <scriptPubKey> 49/99
50. Pay-To-Public-Key-Hash (P2PKH) TX_PUBKEYHASH ▪ <sig> ▪ <PubKey> ▪ OP_DUP → OP_HASH160 ▪ <PubKeyHash> ▪ OP_EQUALVERIFY ▪ OP_CHECKSIG Stack ▪ <pubKeyHash> ▪ <pubKey> ▪ <sig> © 2019 Digital Gold Institute <scriptSig> + <scriptPubKey> 50/99
51. Pay-To-Public-Key-Hash (P2PKH) TX_PUBKEYHASH ▪ <sig> ▪ <PubKey> ▪ OP_DUP ▪ OP_HASH160 → <PubKeyHash> ▪ OP_EQUALVERIFY ▪ OP_CHECKSIG Stack ▪ <pubKeyHash?> ▪ <pubKeyHash> ▪ <pubKey> ▪ <sig> © 2019 Digital Gold Institute <scriptSig> + <scriptPubKey> 51/99
52. Pay-To-Public-Key-Hash (P2PKH) TX_PUBKEYHASH ▪ <sig> ▪ <PubKey> ▪ OP_DUP ▪ OP_HASH160 ▪ <PubKeyHash> → OP_EQUALVERIFY ▪ OP_CHECKSIG Stack ▪ <pubKey> ▪ <sig> © 2019 Digital Gold Institute <scriptSig> + <scriptPubKey> 52/99
53. Pay-To-Public-Key-Hash (P2PKH) TX_PUBKEYHASH <scriptSig> + <scriptPubKey> ▪ <sig> ▪ <PubKey> ▪ OP_DUP ▪ OP_HASH160 ▪ <PubKeyHash> ▪ OP_EQUALVERIFY → OP_CHECKSIG Stack ▪ TRUE © 2019 Digital Gold Institute 53/99
54. 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
55. 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
56. 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
57. <scriptSig> + <scriptPubKey> ▪ <WHATEVER> ▪ OP_WHATEVER ▪ OP_RETURN ▪ <data> Stack OP_RETURN makes the TxO unspendable © 2019 Digital Gold Institute OP_RETURN TX_NULL_DATA 57/99
58. ▪ OP_0 ▪ <sig1> ▪ … ▪ <sigM> ▪ <M> ▪ <pubKey1> ▪ … ▪ <pubKeyN> ▪ <N> ▪ OP_CHECKMULTISIGVERIFY © 2019 Digital Gold Institute Multisignature (M-of-N) Transaction TX_MULTISIG <scriptSig> + <scriptPubKey> Stack 58/99
59. ▪ N ▪ <pubKeyN> ▪ … ▪ <pubKey1> ▪ M ▪ <sigM> ▪ … ▪ <sig1> ▪ 0 ▪ OP_0 ▪ <sig1> ▪ … ▪ <sigM> ▪ <M> ▪ <pubKey1> ▪ … ▪ <pubKeyN> → <N> ▪ OP_CHECKMULTISIGVERIFY OP_CHECKMULTISIG VERIFY bug: it consumes one extra ignored data element Fast forward here <scriptSig> + <scriptPubKey> © 2019 Digital Gold Institute Multisignature (M-of-N) Transaction TX_MULTISIG Stack 59/99
60. ▪ OP_0 ▪ <sig1> ▪ … ▪ <sigM> ▪ <M> ▪ <pubKey1> ▪ … ▪ <pubKeyN> ▪ <N> → OP_CHECKMULTISIGVERIFY © 2019 Digital Gold Institute Multisignature (M-of-N) Transaction TX_MULTISIG <scriptSig> + <scriptPubKey> Stack ▪ TRUE 60/99
61. 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 <scriptPubKey> 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 <scriptSig> © 2019 Digital Gold Institute 61/99
62. 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: <redeem script 20-byte Hash160> ▪ Lock the transaction with: OP_HASH160 <redeem script 20-byte Hash160> OP_EQUAL ▪ Unlock with: <Sig2><1 pubk1 pubk2 3 OP_CHECKMULTISIG> © 2019 Digital Gold Institute 62/99
63. 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 <scriptPubKey> in the (present) UTxO set, larger <scriptSig> 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
64. 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
65. 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
66. <scriptSig> + <scriptPubKey> ▪ <sig> ▪ {[Pubkey] OP_CHECKSIG} ▪ OP_HASH160 ▪ [20-byte-hash of {[Pubkey] OP_CHECKSIG}] ▪ OP_EQUAL Stack © 2019 Digital Gold Institute P2SH Example: Hash of a P2PK script 66/99
67. <scriptSig> + <scriptPubKey> → <sig> ▪ {[Pubkey] OP_CHECKSIG} ▪ OP_HASH160 ▪ [20-byte-hash of {[Pubkey] OP_CHECKSIG}] ▪ OP_EQUAL Stack <sig> © 2019 Digital Gold Institute P2SH Example: Hash of a P2PK script 67/99
68. <scriptSig> + <scriptPubKey> ▪ <sig> → {[Pubkey] OP_CHECKSIG} ▪ OP_HASH160 ▪ [20-byte-hash of {[Pubkey] OP_CHECKSIG}] ▪ OP_EQUAL Stack {[pubkey] OP_CHECKSIG} <sig> © 2019 Digital Gold Institute P2SH Example: Hash of a P2PK script 68/99
69. <scriptSig> + <scriptPubKey> ▪ <sig> ▪ {[Pubkey] OP_CHECKSIG} → OP_HASH160 ▪ [20-byte-hash of {[Pubkey] OP_CHECKSIG}] ▪ OP_EQUAL Stack [20-byte-hash of {[pubkey] OP_CHECKSIG}] <sig> © 2019 Digital Gold Institute P2SH Example: Hash of a P2PK script 69/99
70. <scriptSig> + <scriptPubKey> ▪ <sig> ▪ {[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}] <sig> © 2019 Digital Gold Institute P2SH Example: Hash of a P2PK script 70/99
71. <scriptSig> + <scriptPubKey> ▪ <sig> ▪ {[Pubkey] OP_CHECKSIG} ▪ OP_HASH160 ▪ [20-byte-hash of {[Pubkey] OP_CHECKSIG}] → OP_EQUAL Stack <sig> © 2019 Digital Gold Institute P2SH Example: Hash of a P2PK script 71/99
72. <scriptPubKey> ▪ [Pubkey] ▪ OP_CHECKSIG Stack <sig> Now keep validating using the current stack and the redeem script as <scriptPubKey> © 2019 Digital Gold Institute P2SH Example: Hash of a P2PK script 72/99
73. <scriptPubKey> → [Pubkey] ▪ OP_CHECKSIG Stack [pubkey] <sig> © 2019 Digital Gold Institute P2SH Example: Hash of a P2PK script 73/99
74. <scriptPubKey> ▪ [Pubkey] → OP_CHECKSIG Stack TRUE © 2019 Digital Gold Institute P2SH Example: Hash of P2PK 74/99
75. © 2019 Digital Gold Institute https://p2sh.info/dashboard/db/home-dashboard?orgId=1&from=now-5y&to=now Pay-to-script-hash (P2SH) 75/99
76. Table of Contents 1. TxIns, TxOs, and UTxOs 2. Bitcoin Script Language 3. Standard Transaction Scripts 4. Transactions: Signatures and Smart Contracts 5. Blocks © 2019 Digital Gold Institute 76/99
77. TxIn signature: <scriptSig> 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
78. 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) − <scriptSig> 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
79. Segregated Witness (SegWit) "witness" is a solution to a cryptographic puzzle, e.g.: <scriptSig> ▪ every TxIn in a transaction is followed by the witness data that unlocks its corresponging TxO. ▪ Segregated Witness moves the <scriptSig> 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
80. 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
81. Empty <scriptPubKey> ▪ Anyone could spend an empty <scriptPubKey> with a <scriptSig> consisting of OP_TRUE only ▪ <scriptSig>+<scriptPubKey> = OP_TRUE © 2019 Digital Gold Institute 81/99
82. HTLC © 2019 Digital Gold Institute 82/99
83. 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
84. 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
85. Homework (1/2) ▪ Create a Hashlock transaction, i.e. an output locking script <scriptPubKey> including a hash value, spendable with an input unlocking script <scriptSig> 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
86. 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
87. Table of Contents 1. TxIns, TxOs, and UTxOs 2. Bitcoin Script Language 3. Standard Transaction Scripts 4. Transactions: Signatures and Smart Contracts 5. Blocks © 2019 Digital Gold Institute 87/99
88. 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
89. 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
90. 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
91. 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
92. Block structure: example © 2019 Digital Gold Institute 92/99
93. © 2019 Digital Gold Institute https://blockexplorer.com/block/0000000000000000016a4f0250796c29542d6821c42b4837f3e41a6cca20cfaf Block details example 93/99
94. © 2019 Digital Gold Institute Block details example 94/99
95. Genesis Block © 2019 Digital Gold Institute 95/99
96. 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
97. 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
98. 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
99. 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
100. Ferdinando M. Ametrano Executive Director ferdinando@dgi.io Paolo Mazzocchi Chief Operating Officer paolo@dgi.io www.github.com/dginst www.facebook.com/DigitalGoldInstitute www.twitter.com/DigitalGoldInst www.dgi.org/feed.xml info@dgi.io www.dgi.io www.linkedin.com/company/digital-gold-institute "Scarcity in the Digital Realm"