Bitcoin and Blockchain Technology: Addresses, Transactions, and Blocks. Ferdinando M. Ametrano

Transcription

1 Bitcoin and Blockchain Technology: Addresses, Transactions, and Blocks Ferdinando M. Ametrano

2 Table of Contents 1. Addresses and Wallet Import Formats 2. TxIns, TxOs, UTxOs 3. Bitcoin Script Language 4. Transaction Scripts 5. Odds and Sods 6. Blocks 7. Historical Transactions 2/108

3 Bitcoin Base58 Encoding Binary digits: 01 Decimal digits: Hexadecimal digits: ABCDEF Base58 digits: all alphanumeric characters (numbers, uppercase, and lowercase) omitting 0 (zero), O (capital o), I (capital i) and l (lower case L) ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijk mnopqrstuvwxy 3/108

4 Parsimonious Large Number Representation Larger digit set available less digits required to represent large numbers e.g. 16^5-2: Binary Decimal FFFFE Hex 6Nhs Base58 4/108

5 Base58Check Encoding 1. Payload 2. [Prefix +] Payload [+ Suffix] = ExtPayload 3. ExtPayload + Checksum 4. Base58 encoding Double SHA256 Checksum Calculation a. ExtPayload b. SHA256(ExtPayload) c. SHA256(SHA256(ExtPayload)) d. Checksum = first 4 bytes of the previous step The Base58Check decoding stage will first use the checksum to detect possible errors in ExtPayload before actual decoding 5/108

6 Base58 Representation of Public/private Keys Base58 is used for compact representation of Bitcoin Public/private keys: Address: Q in Base58 representation Wallet Import Format: q in Base58 representation 6/108

7 From Uncompressed Public Key to Address (1/4) Given the private key 0x18E14A7B6A307F426A94F E7C8E774E7F9A47E2C2035DB29A Start from the associated Public Key point in uncompressed representation (65 bytes: 1 byte for the x04 prefix, 32 bytes for the X coordinate, 32 bytes for the Y coordinate) AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B2352 2CD A299FA9E ABC11A1DF38855ED6F2EE187E9C582BA6 7/108

8 From Uncompressed Public Key to Address (2/4) 2. Perform SHA256 hashing on the Public Key 600FFE422B4E00731A59557A5CCA46CC A447BDB2D98D4B Perform RIPEMD160 hashing on the result of SHA D E5E39F86A0D273BEE Note: step 2-3 are often defined as HASH160 HASH160(PubKey) := SHA256(RIPEMD160(PubKey)) 4. Add version byte in front of HASH160 (0x00 for Main Network) to obtain the extended HASH D E5E39F86A0D273BEE The leading zeros, while irrelevant digits for a number, are retained through the following conversions and will lead to a leading 1 in the resulting address 8/108

9 From Uncompressed Public Key to Address (3/4) Base58Check encoding steps: 5. SHA256 hash on the extended HASH C7A8007A93D BB320A8FE2DEBD2AE1B47F0F50BC10BAE845C SHA256 hash on the result of the previous step D61967F63C7DD183914A4AE452C9F6AD5D462CE3D B107615C1A8A30 7. Take the first 4 bytes of the second SHA256 hash as address checksum D61967F6 9/108

10 From Uncompressed Public Key to Address (4/4) 8. Add the 4 checksum bytes from stage 7 at the end of extended HASH D E5E39F86A0D273BEED61967F6 9. Convert into a base58 string using Base58 encoding 16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM The bitcoin address is the Base58 encoding of the HASH160 of a Public key; it starts with 1 because of the 0x00 prefix. 10/108

11 From Compressed Public Key to Address Using the same private key as in the previous slide 0x18E14A7B6A307F426A94F E7C8E774E7F9A47E2C2035DB29A Start from the associated Public Key in compressed representation (33 bytes: 1 byte x02 or x03, 32 bytes corresponding to the X coordinate) AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B2352 Arrive to a Base58 encoded address 1PMycacnJaSqwwJqjawXBErnLsZ7RkXUAs Again: the address is the Base58 encoding of the HASH160 of a Public key; it starts with 1 because of the 0x00 prefix. 11/108

12 Private Key (Uncompressed) WIF Given a private key 0x0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D 1. Extended private key (80 prefix, no suffix) 0x800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D 2. 4 bytes checksum added 0x800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D507A5B8D 3. Base58 encode is 51 characters; it always starts with 5, because of the 0x80 prefix 5HueCGU8rMjxEXxiPuD5BDku4MkFqeZyd4dZ1jvhTVqvbTLvyTJ The uncompressed property does not refer to the private key: it is the public key point derived from uncompressed WIF that must be uncompressed 12/108

13 Private Key (Compressed) WIF Using the same private key as in the previous slide 0x0C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D 1. Extended private key (0x80 prefix, 0x01 suffix) 0x800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D bytes checksum added 0x800C28FCA386C7A227600B2FE50B7CAE11EC86D3BF1FBE471BE89827E19D72AA1D01A62019D2 3. Base58 encode is 52 characters (longer than uncompressed WIF because of the 0x01 suffix); it always starts with K or L, because of the 0x80 prefix KwdMAjGmerYanjeui5SHS7JkmpZvVipYvB2LJGU1ZxJwYvP98617 The compressed property does not refer to the private key: it is the public key derived from compressed WIF that must be compressed 13/108

14 Addresses/Keys Version Types Network Usage Version type Leading symbol(s) Mainnet Pubkey hash (address) 00 1 Mainnet prvkey (uncompressed WIF) 80 5 Mainnet prvkey (compressed WIF) 80 K or L Testnet Pubkey hash (address) 6F m or n Testnet prvkey (uncompressed WIF) EF 9 Testnet prvkey (compressed WIF) EF c 14/108

15 Relation Between Keys, Addresses, and WIF 1. prvkey < Base58Encoding > WIF 2. prvkey EC Multiplication > PubKey 3. PubKey HASH160 > PubKeyHash 4. PubKeyHash < Base58Encoding > address EC multiplication and hash functions are one-way Quantum computers will be able to factor private keys from public keys, but not to invert hash functions 15/108

16 Homework With the private key obtained with the previous homework: 1. Calculate the uncompressed WIF 2. Calculate the compressed WIF 3. Calculate the address from uncompressed Public key 4. Calculate the address from compressed Public key Check PrvKeyToWIFCompressed.py, PrvKeyToWIFUncompressed.py, and PubKeyToAddress.py in the scripts folder at Verify your results at (Wallet Details) 16/108

17 Table of Contents 1. Addresses and Wallet Import Formats 2. TxIns, TxOs, UTxOs 3. Bitcoin Script Language 4. Transaction Scripts 5. Odds and Sods 6. Blocks 7. Historical Transactions 17/108

18 Transactions Txs can be created by any means, even offline Txs can be propagated to the network even by non secure channels Nodes will validate Txs before propagating them further Txs consume one or more transaction inputs (TxIns) and generate one or more transaction outputs (TxOs) Coinbase transactions have no TxIns 18/108

19 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 19/108

20 Unspent TxOs: Electrum Testnet 2 UTxO (2BTC + 1BTC) on the address tb1qhd92h3tac67u2merxvyu3nen6cgf5y2k8q24hd 1 UTxO each ( and ) on two other addresses Balance includes all of them 20/108

21 TxIns reference and spend UTxOs Software can empower the user with coin control, i.e. picking TxIns 21/108

22 TxOs Locking Puzzle Every TxO is locked by a mathematical puzzle (encumbrance) To spend the TxO, the corresponding TxIn must provide the solution to (i.e. unlock) the puzzle Unlocking a TxO puzzle usually involves a digital signature using the private key related to the address the TxO is associated to 22/108

23 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) 23/108

24 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 00:00:00UTC 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) 24/108

25 Transaction Validity 1. can be finalized (i.e. it is not time locked) 2. 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 /108

26 TxIns, TxOs, and Fees σ TxO i σ TxIn i : the amounts of the newly generated TxOs must be less than or equal to the amount of TxIns σ TxO i + Fee = σ TxIn i : 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 not be a TxO because the winning miner is not known at transaction time 26/108

27 Transaction Fees A minimum fee of 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 27/108

28 Transaction Fees 28/108

29 29/108

30 Table of Contents 1. Addresses and Wallet Import Formats 2. TxIns, TxOs, UTxOs 3. Bitcoin Script Language 4. Transaction Scripts 5. Odds and Sods 6. Blocks 7. Historical Transactions 30/108

31 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 31/108

32 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 Script is purposefully stateless and not Turing-complete Limited flexibility is a deliberate security feature, preventing vulnerability from the transaction validation mechanism 32/108

33 Verify 2+3=5 Using Script 2 3 OP_ADD 5 OP_EQUAL Stack 2 3 OP_ADD 5 OP_EQUAL 33/108

34 Verify 2+3=5 Using Script 2 3 OP_ADD 5 OP_EQUAL Stack 2 3 OP_ADD 5 OP_EQUAL 2 34/108

35 Verify 2+3=5 Using Script 2 3 OP_ADD 5 OP_EQUAL Stack 2 3 OP_ADD 5 OP_EQUAL /108

36 Verify 2+3=5 Using Script 2 3 OP_ADD 5 OP_EQUAL Stack 2 3 OP_ADD 5 OP_EQUAL 5 36/108

37 Verify 2+3=5 Using Script 2 3 OP_ADD 5 OP_EQUAL Stack 2 3 OP_ADD 5 OP_EQUAL /108

38 Verify 2+3=5 Using Script 2 3 OP_ADD 5 OP_EQUAL Stack 2 3 OP_ADD 5 OP_EQUAL TRUE 38/108

39 Interactive Script Playgrounds Bitcoin Debug Script Execution convert Script to JavaScript 39/108

40 Operators 256 opcodes total (15 disabled, 75 reserved) Arithmetic If/then Logic/data handling Crypto Hashes Signature verification Multi-signature verification 40/108

41 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 41/108

42 Table of Contents 1. Addresses and Wallet Import Formats 2. TxIns, TxOs, UTxOs 3. Bitcoin Script Language 4. Transaction Scripts 5. Odds and Sods 6. Blocks 7. Historical Transactions 42/108

43 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) 43/108

44 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 44/108

45 Script Execution Scripts are not really concatenated anymore: executed separately for security reason, stack being transferred between the two 45/108

46 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 46/108

47 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 47/108

48 Pay-To-Public-Key (P2PK) <scriptsig> + <scriptpubkey> <sig> <pubkey> OP_CHECKSIG TX_PUBKEY Stack 48/108

49 Pay-To-Public-Key (P2PK) <scriptsig> + <scriptpubkey> <sig> <pubkey> OP_CHECKSIG TX_PUBKEY Stack <sig> 49/108

50 Pay-To-Public-Key (P2PK) <scriptsig> + <scriptpubkey> <sig> <pubkey> OP_CHECKSIG TX_PUBKEY Stack <pubkey> <sig> 50/108

51 Pay-To-Public-Key (P2PK) <scriptsig> + <scriptpubkey> <sig> <pubkey> OP_CHECKSIG TX_PUBKEY Stack TRUE 51/108

52 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 52/108

53 Pay-To-Public-Key-Hash (P2PKH) <scriptsig> + <scriptpubkey> <sig> <pubkey> OP_DUP OP_HASH160 <pubkeyhash?> OP_EQUALVERIFY OP_CHECKSIG TX_PUBKEYHASH Stack 53/108

54 Pay-To-Public-Key-Hash (P2PKH) <scriptsig> + <scriptpubkey> <sig> <pubkey> OP_DUP OP_HASH160 <pubkeyhash?> OP_EQUALVERIFY OP_CHECKSIG TX_PUBKEYHASH Stack <sig> 54/108

55 Pay-To-Public-Key-Hash (P2PKH) <scriptsig> + <scriptpubkey> <sig> <pubkey> OP_DUP OP_HASH160 <pubkeyhash?> OP_EQUALVERIFY OP_CHECKSIG TX_PUBKEYHASH Stack <pubkey> <sig> 55/108

56 Pay-To-Public-Key-Hash (P2PKH) <scriptsig> + <scriptpubkey> <sig> <pubkey> OP_DUP OP_HASH160 <pubkeyhash?> OP_EQUALVERIFY OP_CHECKSIG TX_PUBKEYHASH Stack <pubkey> <pubkey> <sig> 56/108

57 Pay-To-Public-Key-Hash (P2PKH) <scriptsig> + <scriptpubkey> <sig> <pubkey> OP_DUP OP_HASH160 <pubkeyhash?> OP_EQUALVERIFY OP_CHECKSIG TX_PUBKEYHASH Stack <pubkeyhash> <pubkey> <sig> 57/108

58 Pay-To-Public-Key-Hash (P2PKH) <scriptsig> + <scriptpubkey> <sig> <pubkey> OP_DUP OP_HASH160 <pubkeyhash?> OP_EQUALVERIFY OP_CHECKSIG TX_PUBKEYHASH Stack <pubkeyhash?> <pubkeyhash> <pubkey> <sig> 58/108

59 Pay-To-Public-Key-Hash (P2PKH) <scriptsig> + <scriptpubkey> <sig> <pubkey> OP_DUP OP_HASH160 <pubkeyhash?> OP_EQUALVERIFY OP_CHECKSIG TX_PUBKEYHASH Stack <pubkey> <sig> 59/108

60 Pay-To-Public-Key-Hash (P2PKH) <scriptsig> + <scriptpubkey> <sig> <pubkey> OP_DUP OP_HASH160 <pubkeyhash?> OP_EQUALVERIFY OP_CHECKSIG TX_PUBKEYHASH Stack TRUE 60/108

61 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! 61/108

62 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 62/108

63 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 and 63/108

64 OP_RETURN TX_NULL_DATA <scriptsig> + <scriptpubkey> Stack <WHATEVER> OP_WHATEVER OP_RETURN <data> OP_RETURN makes the TxO unspendable 64/108

65 Multisignature (M-of-N) Transaction TX_MULTISIG <scriptsig> + <scriptpubkey> OP_0 <sig1> <sigm> <M> <pubkey1> <pubkeyn> <N> OP_CHECKMULTISIGVERIFY Stack 65/108

66 Multisignature (M-of-N) Transaction TX_MULTISIG <scriptsig> + <scriptpubkey> Fast forward here OP_0 <sig1> <sigm> <M> <pubkey1> <pubkeyn> <N> OP_CHECKMULTISIGVERIFY Stack N <pubkeyn> <pubkey1> M <sigm> <sig1> 0 OP_CHECKMULTISIGVERIF Y bug: it consumes one extra ignored data element 66/108

67 Multisignature (M-of-N) Transaction TX_MULTISIG <scriptsig> + <scriptpubkey> Stack OP_0 <sig1> <sigm> <M> <pubkey1> <pubkeyn> <N> OP_CHECKMULTISIGVERIFY TRUE 67/108

68 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> 68/108

69 From TX_MULTISIG To TX_SCRIPTHASH This 65*3+3 bytes <redeem script> <2 pubk1 pubk2 pubk3 3 OP_CHECKMULTISIG> 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> <Sig3> <2 pubk1 pubk2 pubk3 3 OP_CHECKMULTISIG> 69/108

70 BIP16 Pay-To-Script-Hash (P2SH) pay to a script matching this hash, a script that will be presented to spend this output in the future: the sender does not handle complexity, the recipient will Scripts are coded as addresses: complex scripts are replaced by shorter fingerprints in the TxO A future spending TxIn will contain the redeem script whose hash is contained in the UTxO: the fee cost for a complex script is shifted from the current sender to the recipient at future redemption time Smaller <scriptpubkey> in the (present) UTxO set, larger <scriptsig> in the (future) blockchain Public keys are revealed at redemption time only 70/108

71 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 specification is not recursive Redeem script cannot include OP_RETURN 71/108

72 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 72/108

73 P2SH Example: One Signature Required <scriptsig> + <scriptpubkey> Stack <sig> {[pubkey] OP_CHECKSIG} OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG}] OP_EQUAL 73/108

74 P2SH Example: Hash of P2PK <scriptsig> + <scriptpubkey> Stack <sig> {[pubkey] OP_CHECKSIG} OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG}] OP_EQUAL <sig> 74/108

75 P2SH Example: Hash of P2PK <scriptsig> + <scriptpubkey> Stack <sig> {[pubkey] OP_CHECKSIG} OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG}] OP_EQUAL {[pubkey] OP_CHECKSIG} <sig> 75/108

76 P2SH Example: Hash of P2PK <scriptsig> + <scriptpubkey> Stack <sig> {[pubkey] OP_CHECKSIG} OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG}] OP_EQUAL [20-byte-hash of {[pubkey] OP_CHECKSIG}] <sig> 76/108

77 P2SH Example: Hash of P2PK <scriptsig> + <scriptpubkey> Stack <sig> {[pubkey] OP_CHECKSIG} OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG}] OP_EQUAL [20-byte-hash of {[pubkey] OP_CHECKSIG}] [20-byte-hash of {[pubkey] OP_CHECKSIG}] <sig> 77/108

78 P2SH Example: Hash of P2PK <scriptsig> + <scriptpubkey> Stack <sig> {[pubkey] OP_CHECKSIG} OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG}] OP_EQUAL <sig> 78/108

79 P2SH Example: Hash of P2PK Now keep validating using the current stack and the redeem script as <scriptpubkey> [pubkey] OP_CHECKSIG <scriptpubkey> Stack <sig> 79/108

80 P2SH Example: Hash of P2PK <scriptpubkey> Stack [pubkey] OP_CHECKSIG [pubkey] <sig> 80/108

81 P2SH Example: Hash of P2PK <scriptpubkey> Stack [pubkey] OP_CHECKSIG TRUE 81/108

82 Pay-to-script-hash (P2SH) 82/108

83 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?) 83/108

84 Homework (2/2) See also: d1db51ff3100d285956a40cc0e4f8c8c2c4a80559 b1 Study the script logic at: 363d1db51ff3100d285956a40cc0e4f8c8c2c4a80 559b1:0 84/108

85 Table of Contents 1. Addresses and Wallet Import Formats 2. TxIns, TxOs, UTxOs 3. Bitcoin Script Language 4. Transaction Scripts 5. Odds and Sods 6. Blocks 7. Historical Transactions 85/108

86 TxIn signature <scriptsig> Hash Type Which of the newly created TxOs are covered by the TxIns signature 1. SIGHASH_ALL (default): modifying any TxO in a transaction would require all the TxIns to be signed again 2. SIGHASH_NONE: any TxO in the transaction can be changed 3. SIGHASH_SINGLE: the TxO of the same index as the TxIn 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: the current TxIn if TRUE, all TxIns if FALSE 86/108

87 Malleability Transaction signature does not cover all the data in a transaction that is hashed to create the transaction hash A transaction s hash can be manipulated without altering TxIn, TxOut, and spendibility conditions; e.g. DER-encoded ASN.1 octet representation for every ECDSA signature (r, s), the signature (r, N-s) is a valid signature of the same message the <scriptsig> is not signed and can be manipulated with additional data then removed with OP_DROP, etc. 87/108

88 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. 88/108

89 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 89/108

90 Empty <scriptpubkey> Anyone can spend an empty <scriptpubkey> with a <scriptsig> consisting of OP_TRUE only <scriptsig>+<scriptpubkey> = OP_TRUE 90/108

91 Transaction Chaining and Orphan Transactions Transaction chaining: child transaction spends the outputs of the parent transaction The child might arrive before the parent: it is put it 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 91/108

92 Replace By Fee - BIP 125 RBF allows replacing a 0-confirmations transaction by transmitting another transaction with a higher fee RBF is opt-in 92/108

93 Table of Contents 1. Addresses and Wallet Import Formats 2. TxIns, TxOs, UTxOs 3. Bitcoin Script Language 4. Transaction Scripts 5. Odds and Sods 6. Blocks 7. Historical Transactions 93/108

94 Transaction Bundling Transactions are bundled in blocks for practical reasons (shorter chain, single unit of work for validators, faster history validation) nonce prev_hash Tx Tx Tx nonce prev_hash Tx Tx Tx nonce prev_hash Tx Tx Tx nonce prev_hash Tx Tx Tx nonce prev_hash Tx Tx Tx Transactions in a block are actually packaged in a Merkle Tree 94/108

95 Hash chain of blocks Block Structure prev: H( ) trans: H( ) prev: H( ) trans: H( ) prev: H( ) trans: H( ) H( ) H( ) Hash tree (Merkle tree) of transactions in each block H( ) H( ) H( ) H( ) transaction transaction transaction transaction 95/108

96 Block structure Block structure Block size 4 bytes Block header 80 bytes Number of Transactions 1-9 bytes Transactions Variable bytes The average block contains more than 2000 transactions. The maximum block size, as fixed in Bitcoin Core, is 1MB 96/108

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

98 Block structure: example 98/108

99 99/108

100 100/108

101 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 or any other block explorer 101/108

102 Table of Contents 1. Addresses and Wallet Import Formats 2. TxIns, TxOs, UTxOs 3. Bitcoin Script Language 4. Transaction Scripts 5. Odds and Sods 6. Blocks 7. Historical Transactions 102/108

103 Genesis Block 103/108

104 Genesis Block Number Of Transactions: 1; Difficulty: 1; Nonce: ; Block Reward: 50 BTC Hash: d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f 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 /108

105 First Transaction, From Satoshi to Hal Finney 105/108

106 First Purchase: Pizza Transaction msg1 106/108

107 First Purchase: Pizza Transaction 107/108

108 Bibliography A. Narayanan, et al., Bitcoin and Cryptocurrency Technologies, chapter 3 Pedro Franco, Understanding Bitcoin, Wiley, chapter 6 Andreas Antonopoulos, Mastering Bitcoin, O'Reilly, chapters 2, 4, 6, /108