Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Transactions and Blocks

Transactions and Blocks

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

www.ametrano.net/bbt/

Ferdinando M. Ametrano

March 22, 2019
Tweet

More Decks by Ferdinando M. Ametrano

Other Decks in Technology

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

    View Slide

  2. First Transaction, From Satoshi to Hal Finney
    © 2019 Digital Gold Institute
    https://blockchain.info/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16
    2/99

    View Slide

  3. First Bitcoin Purchase: 2 Pizzas for
    BTC10,000
    © 2019 Digital Gold Institute
    https://bitcointalk.org/index.php?topic=137.msg1195#msg1
    3/99

    View Slide

  4. First Bitcoin Purchase: 2 Pizzas for
    BTC10,000
    © 2019 Digital Gold Institute
    https://blockchain.info/tx/a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d
    4/99

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  9. TxIns reference and spend UTxOs
    Software can empower the user with coin control, i.e. picking TxIns
    © 2019 Digital Gold Institute 9/99

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  14. © 2019 Digital Gold Institute
    https://blockstream.info/tx/5a42590fbe0a90ee8e8747244d6c84f0db1a3a24e8f1b95b10c9e050990b8b6b
    A Bitcoin Transaction
    14/99

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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
    consisting of OP_RETURN followed by exactly one pushdata operator
    © 2019 Digital Gold Institute
    https://en.bitcoin.it/wiki/Script
    33/99

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  41. Pay-To-Public-Key (P2PK): TX_PUBKEY


    ▪ OP_CHECKSIG
    Stack
    © 2019 Digital Gold Institute
    +

    41/99

    View Slide

  42. Pay-To-Public-Key (P2PK): TX_PUBKEY


    ▪ OP_CHECKSIG
    Stack

    © 2019 Digital Gold Institute
    +

    42/99

    View Slide

  43. Pay-To-Public-Key (P2PK): TX_PUBKEY


    ▪ OP_CHECKSIG
    Stack


    © 2019 Digital Gold Institute
    +

    43/99

    View Slide

  44. Pay-To-Public-Key (P2PK): TX_PUBKEY


    → OP_CHECKSIG
    Stack
    ▪ TRUE
    © 2019 Digital Gold Institute
    +

    44/99

    View Slide

  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

    View Slide

  46. Pay-To-Public-Key-Hash (P2PKH)
    TX_PUBKEYHASH
    +



    ▪ OP_DUP
    ▪ OP_HASH160

    ▪ OP_EQUALVERIFY
    ▪ OP_CHECKSIG
    Stack
    © 2019 Digital Gold Institute 46/99

    View Slide

  47. Pay-To-Public-Key-Hash (P2PKH)
    TX_PUBKEYHASH


    ▪ OP_DUP
    ▪ OP_HASH160

    ▪ OP_EQUALVERIFY
    ▪ OP_CHECKSIG
    Stack

    © 2019 Digital Gold Institute
    +

    47/99

    View Slide

  48. Pay-To-Public-Key-Hash (P2PKH)
    TX_PUBKEYHASH


    ▪ OP_DUP
    ▪ OP_HASH160

    ▪ OP_EQUALVERIFY
    ▪ OP_CHECKSIG
    Stack


    © 2019 Digital Gold Institute
    +

    48/99

    View Slide

  49. Pay-To-Public-Key-Hash (P2PKH)
    TX_PUBKEYHASH


    → OP_DUP
    ▪ OP_HASH160

    ▪ OP_EQUALVERIFY
    ▪ OP_CHECKSIG
    Stack



    © 2019 Digital Gold Institute
    +

    49/99

    View Slide

  50. Pay-To-Public-Key-Hash (P2PKH)
    TX_PUBKEYHASH


    ▪ OP_DUP
    → OP_HASH160

    ▪ OP_EQUALVERIFY
    ▪ OP_CHECKSIG
    Stack



    © 2019 Digital Gold Institute
    +

    50/99

    View Slide

  51. Pay-To-Public-Key-Hash (P2PKH)
    TX_PUBKEYHASH


    ▪ OP_DUP
    ▪ OP_HASH160

    ▪ OP_EQUALVERIFY
    ▪ OP_CHECKSIG
    Stack




    © 2019 Digital Gold Institute
    +

    51/99

    View Slide

  52. Pay-To-Public-Key-Hash (P2PKH)
    TX_PUBKEYHASH


    ▪ OP_DUP
    ▪ OP_HASH160

    → OP_EQUALVERIFY
    ▪ OP_CHECKSIG
    Stack


    © 2019 Digital Gold Institute
    +

    52/99

    View Slide

  53. Pay-To-Public-Key-Hash (P2PKH)
    TX_PUBKEYHASH
    +



    ▪ OP_DUP
    ▪ OP_HASH160

    ▪ OP_EQUALVERIFY
    → OP_CHECKSIG
    Stack
    ▪ TRUE
    © 2019 Digital Gold Institute 53/99

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  57. +


    ▪ OP_WHATEVER
    ▪ OP_RETURN

    Stack
    OP_RETURN makes the TxO
    unspendable
    © 2019 Digital Gold Institute
    OP_RETURN TX_NULL_DATA
    57/99

    View Slide

  58. ▪ OP_0

    ▪ …



    ▪ …


    ▪ OP_CHECKMULTISIGVERIFY
    © 2019 Digital Gold Institute
    Multisignature (M-of-N) Transaction
    TX_MULTISIG
    +

    Stack
    58/99

    View Slide

  59. ▪ 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

    View Slide

  60. ▪ OP_0

    ▪ …



    ▪ …


    → OP_CHECKMULTISIGVERIFY
    © 2019 Digital Gold Institute
    Multisignature (M-of-N) Transaction
    TX_MULTISIG
    +

    Stack
    ▪ TRUE
    60/99

    View Slide

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

    View Slide

  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:
    ▪ Lock the transaction with:
    OP_HASH160 OP_EQUAL
    ▪ Unlock with: <1 pubk1 pubk2 3 OP_CHECKMULTISIG>
    © 2019 Digital Gold Institute 62/99

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  66. +


    ▪ {[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

    View Slide

  67. +


    ▪ {[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
    67/99

    View Slide

  68. +


    → {[Pubkey] OP_CHECKSIG}
    ▪ OP_HASH160
    ▪ [20-byte-hash of {[Pubkey]
    OP_CHECKSIG}]
    ▪ OP_EQUAL
    Stack
    {[pubkey] OP_CHECKSIG}

    © 2019 Digital Gold Institute
    P2SH Example: Hash of a P2PK script
    68/99

    View Slide

  69. +


    ▪ {[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

    View Slide

  70. +


    ▪ {[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

    View Slide

  71. +


    ▪ {[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
    71/99

    View Slide


  72. ▪ [Pubkey]
    ▪ OP_CHECKSIG
    Stack

    Now keep validating using the current stack and the redeem script as
    © 2019 Digital Gold Institute
    P2SH Example: Hash of a P2PK script
    72/99

    View Slide


  73. → [Pubkey]
    ▪ OP_CHECKSIG
    Stack
    [pubkey]

    © 2019 Digital Gold Institute
    P2SH Example: Hash of a P2PK script
    73/99

    View Slide


  74. ▪ [Pubkey]
    → OP_CHECKSIG
    Stack
    TRUE
    © 2019 Digital Gold Institute
    P2SH Example: Hash of P2PK
    74/99

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

  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)
    − 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

    View Slide

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

    View Slide

  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

    View Slide

  81. Empty
    ▪ Anyone could spend an empty with a
    consisting of OP_TRUE only
    ▪ + = OP_TRUE
    © 2019 Digital Gold Institute 81/99

    View Slide

  82. HTLC
    © 2019 Digital Gold Institute 82/99

    View Slide

  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

    View Slide

  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

    View Slide

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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  92. Block structure: example
    © 2019 Digital Gold Institute 92/99

    View Slide

  93. © 2019 Digital Gold Institute
    https://blockexplorer.com/block/0000000000000000016a4f0250796c29542d6821c42b4837f3e41a6cca20cfaf
    Block details example
    93/99

    View Slide

  94. © 2019 Digital Gold Institute
    Block details example
    94/99

    View Slide

  95. Genesis Block
    © 2019 Digital Gold Institute 95/99

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  100. 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"

    View Slide