CCC: Cryptocurrency Course slide set

## Merkle Trees (aka Hash Trees)
- A tree, often binary, where each *leaf* node stores the data and a *hash* of that data
  - Often an *almost perfect binary tree*, like a binary heap
- Each *internal node* stores the hash of the concatenation of the hashes of its children
  - Can be other operations other than concatenation
- Purpose: to prevent changing one leaf node without changing all the hashes above it

<aside data-markdown class="notes">
- It can actually be many operations other than concatenation, but we'll only discuss concatenation
- Typically presented as an *almost-perfect binary tree*, although that's not strictly required
- Named after Ralph Merkle, who invented them
</aside>

## Merkle Trees (aka Hash Trees)
<a href='https://en.wikipedia.org/wiki/Merkle_tree'><img src='images/bitcoin/Hash_Tree.svg' alt='Merkle Tree' style='background:white;border-radius:30px'></a>

## Merkle Trees Uses
- File transfer, including peer-to-peer
  - ensure no errors in the transferred file parts
- File systems
  - to detect & counter data degradation
- Git and Mercurial VCS 
  - the commit hex is a hashed, and kept in an almost-Merkle tree
- And, not surprisingly, Bitcoin's blockchain

## Merkle Tree use in practice

<img src='images/bitcoin/Hash_Tree.svg' style="width:300px;float:right;background:white;border-radius:10px">
<ul class=".reveal" style="width:unset;margin-top:20px">
<li>No need to actually build the tree</li>
<li>Pair up leafs to get 2nd level hashes
  <ul><li>If odd #, then concatenate that<br>hash with itself</li></ul></li></ul>

- Pair up 2nd level hashes for 3rd level hashes
  - Again, if there is an odd number, then concatenate that last odd leaf with itself
  - (Some implementations: instead of concatenating an odd leaf with itself, but just propagates it up; Bitcoin does the former)
- Keep repeating until you have the root hash

<h2>Merkle Tree use in practice</h2>

<p>Consider an array of 10 leaf elements of a Merkle tree</p>
<img src='images/bitcoin/merkle/merkle.dot.5.png' class='fragment' data-fragment-index='5'>
<img src='images/bitcoin/merkle/merkle.dot.4.png' class='fragment' data-fragment-index='4'>
<img src='images/bitcoin/merkle/merkle.dot.3.png' class='fragment' data-fragment-index='3'>
<img src='images/bitcoin/merkle/merkle.dot.2.png' class='fragment' data-fragment-index='2'>
<img src='images/bitcoin/merkle/merkle.dot.1.png'>
<p class='fragment' data-fragment-index='6'>Requires $n-1$ or $\Theta(n)$ hashes</p>

## However...
Given a Merkle tree:

- If L1 changes, we only want to change the hashes up to the root
  - That's a logarithmic length path
- This means keeping all the others hashes in memory

Merkle Trees in Arrays

Just like binary heaps!

From node i:

left child: $2 \ast i$
right child: $(2 \ast i)+1$
parent: $\lfloor i/2 \rfloor$

Array representation:

∅	h(1‑8)	h(1‑4)	h(5‑8)	h(1‑2)	h(3‑4)	h(5‑6)	h(7‑8)	h(1)	h(2)	h(3)	h(4)	h(5)	h(6)	h(7)	h(8)
0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15

## Hash Algorithms Used
- You can use any [cryptographic hash function](https://en.wikipedia.org/wiki/Cryptographic_hash_function)
- Bitcoin uses *double* SHA-256:
  - Take the SHA-256 of the (binary output) of the SHA-256 of the data block
- All this hashing causes a significant performance hit
- Ethereum uses a somewhat similar tree, and uses SHA-3 (aka Keccak-256)

## Problems with Merkle Trees
- Bitcoin uses the hash functions "to an excessive degree" ([Wikipedia](https://en.wikipedia.org/wiki/Merkle_tree))
- The Merkle Tree construction is thus rather slow
- Also their use in Bitcoin had a vulnerability: [CVE-2012-2459](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2459)
  - Problem was with duplicating transactions
  - Easy solution: ensure that the bitcoin software does not record these duplicate hashes
  - Harder solution: redesign the Merkle Trees to disallow this
- Thus, [BIP0098](https://github.com/bitcoin/bips/blob/master/bip-0098.mediawiki) was proposed to use *Fast Merkle Trees*

<aside data-markdown class="notes">
- If you duplicate transactions in the Merkle tree, then you have duplicate hashes, as you have the same input
- This is invalid, but if recorded, will prevent recording of data with the same hash
</aside>

## Fast Merkle Trees
- The only difference is that *internal nodes* have their hash computed slightly differently
  - Concatenate the two (32-byte) hashes of the children
  - Add a pre-defined *initialization vector* (IV)
  - Take only *one* SHA-256 hash of that concatenated value

## Endian-ness
- Everything in Bitcoin's blockchain is little-Endian
- The hash for Bitcoin block 0 is:
    - Little-Endian: 0x6fe28c0ab6f1b372c1a6a246ae63f74f931e836 5e15a089c68d6190000000000
	- Big-Endian:    0x000000000019d6689c085ae165831e934ff763a e46a2a6c172b3f1b60a8ce26f
- When presenting block hashes:
    - Either it won't matter the format, or...
	- We'll carefully specify, or...
	- You can tell based on which end all the 0x00 bytes are

## compactSize unsigned integer
- An unsigned int that can be up to $2^{64}-1$ in size
- Varies in size from 1-9 bytes
- Algorithm to decode: read first byte as $b$:
  - If $0x00 \le b \lt 0xfd$       or:       $0 \le b \lt 253$
    -  Use that value as-is (range: 0->252)
  - If $b=0xfd=253$
    - Read the next two bytes as a (little-Endian) 2-byte unsigned int (a typical `unsigned short`)
  - If $b=0xfe=254$
    - Read the next four bytes as a (little-Endian) 4-byte unsigned int (a typical `unsigned int`)
  - If $b=0xff=255$
    - Read the next eight bytes as a (little-Endian) 8-byte unsigned int (a typical `unsigned long`)

## Unix time
- The number of seconds since January 1st, 1970 UTC
- Example:
  - 1,641,013,200 is midnight (0:00:00) on January 1st, 2022 EST
  - 1,640,995,200 is midnight (0:00:00) on January 1st, 2022 GMT
  - A difference of 18,000 seconds = 5 hours, as GMT-5 = EST
- All programming languages have conversion routines
  - Use those!!!
- In general, if no timezone was set, it will default to GMT

## Unix time conversion
- In Python:
```
import datetime
print(datetime.datetime.utcfromtimestamp(1640995200).\
        strftime('%Y-%m-%d %H:%M:%S'))
```
- In Java:
```
import java.util.Date;
...
Date d = new Date(1640995200);
System.out.println(d);
```
- In C/C++:
```
#include <time.h>
...
  time_t t = 1640995200;
  cout << asctime(gmtime(&t)); // or use printf() in C
```

## Blockchain types used
- Bitcoin's blockchain only has 5 types:
  - 4-byte (mostly) unsigned integers
    - Some of which are unix timestamps
  - 8-byte unsigned integers (aka long)
  - compactSize unsigned integers
  - 32 byte hashes
  - variable-length strings
- That's it!
- The first four of those are in little-Endian
  - Only the variable-length strings are in big-Endian
  - Note that many programming language routines will convert the Endian-ness for you
    - Some without tell you, others you have to tell it to do so

## History
- The first viable cryptocurrency, white paper released in 2008 by "Satoshi Nakamoto"
  - That's a pseudonym; nobody knows who the real person (or group) that created it
  - Although the person is [likely British](https://en.wikipedia.org/wiki/Satoshi_Nakamoto#Characteristics_and_identity)
- Genesis block created on January 3rd, 2009
- It is now fully open source
  - https://github.com/bitcoin/bitcoin
- It was also one of the first digital-only currencies that didn't bankrupt the creator

## Genesis block
- Created on January 3, 2009 ([hi-res version](https://upload.wikimedia.org/wikipedia/commons/2/2e/Bitcoin-Genesis-block.jpg))

Text: "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"

## Symbols and conversions
- ₿ is the symbol for BTC
  - Both ₿ and 'BTC' are used interchangably
- A *satoshi* is the smallest amount of BTC that can be transacted
  - 1 BTC = $10^8$ sat
  - No standardized symbol for satoshi; *"sat"* is often used
- All BTC transaction amounts are represented as a integer number of satoshis
  - As an 8-byte unsigned little-Endian (long) int

## Wallets
- A wallet is one (or more) ECDSA public/private key pairs
  - Each transaction can have a separate key pair
- The public key of the key pair is hashed to get the BTC address
  - Thus a wallet can have *multiple* BTC addresses
  - A single such address is called the *invoice address*

## Funding
- Bitcoins are only created by mining
- Initially 50 BTC per mined block
  - A block is mined every 10 minutes (ideally)
- Reward halves every 210,000 blocks mined (about every 4 years)
  - Current reward: 6.25 BTC
  - Current circulation: about 19M BTC (90% of final amount)
- [Next halving](https://www.bitcoinblockhalf.com/) is expected in April 2024
- Last halving is around 2140
  - 32 total halvings by then
  - Mining reward then will be $\frac{50}{2^{32}}$ = 0.00000001 1641532 BTC
    - Or 1 satoshi
- Total (and final!) BTC in circulation will be 21M

## Transaction
- Any transaction has one or more inputs...
  - Where the BTC comes from
- ... and one or more outputs
  - Where the money goes
- Every transaction always spends ALL of the money of the inputs
  - Any difference is the transaction fee
  - TXN fee = sum(inputs) - sum(outputs)
- Only want to spend some of the input(s)?
  - Send the rest back to yourself as a separate output
  - Either:
    - Send it back to the same key that just spent it (less common)
    - Generate a *new* key pair in your wallet to send the money to

## UTXO
- UTXO = Unspent Transaction Output
- Every transaction specifies which UTXO(s) provides the source of the BTC
  - Again, all the BTC must be spent else it's a fee
  - But some of that can go back to the same key pair
  - But, for security, it usually goes to a separate (and newly created) key pair in the wallet
- Key pairs (and thus wallets) are funded by one or more UTXOs
- A UTXO can have the funds separated into different index values

## Voting
- A mining device is not (necessarily) a node
  - A node needs to hold the entire blockchain
  - A miner needs lots of processing power and only the current UTXOs
    - aka the DAG
- A miner batches transactions into blocks, find the right nonce, and then presents the block to a node on the peer-to-peer network
- The nodes vote on whether to accept the block
- But what if some nodes are untrustworthy?
  - This is the issue of consensus
    - An [entire lecture](consensus.html#/) in and of itself

## Peer-to-peer
- When a node starts up, it connects to some well-known Bitcoin nodes
  - And uses those to find its peers
  - It doesn't need those well-known nodes, but it's much faster with them
- A wallet sends a (signed) transaction to any node
- That node propagates it to other nodes via the [gossip protocol](https://en.wikipedia.org/wiki/Gossip_protocol)
  - Basically: each node checks it, sends it to a few others, who check it, send it to a few others, etc.
- Miners get the transactions from either a node or the mining pool

## Node stats from [bitnodes.io](https://bitnodes.io/)
- As of Sep 12, 2023, there are 16,391 nodes in the Bitcoin network

![](images/timely/btc-nodes.webp)

## How to represent binary as text?
- Perhaps for printing
- Or for email
  - Many email systems can only transmit text, not binary
  - So images need to be suchly encoded
- Example: the Bitcoin genesis block has hash 0x000000000019d6689c085ae165831e934ff763ae46a2a6 c172b3f1b60a8ce26f
- Hex encoding: each byte becomes 2 hex digits
  - Each (8-bit) text character represents 4 bits: 200% increase in size

## Base 64 encoding
- Given binary data, split it into 6 bit chunks
- Each 6-bit chunk maps to a given printable letter
  - 0 -> A ... 25 -> Z
  - 26 -> a ... 51 -> z
  - 52 -> 0 ... 61 -> 9
  - 62 -> +
  - 63 -> /
  - = is a pad character if the total number of bits is not evenly divisible by 6
- Each text character represents 6 bits: 133% increase in size

## Base 64 encoding example
<pre style="margin:0;width:103%"><code style="font-size:smaller">$ cat lorem-ipsum.txt 
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor
incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis
nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
$ base64 lorem-ipsum.txt 
TG9yZW0gaXBzdW0gZG9sb3Igc2l0IGFtZXQsIGNvbnNlY3RldHVyIGFkaXBpc2NpbmcgZWxpdCwg
c2VkIGRvIGVpdXNtb2QgdGVtcG9yCmluY2lkaWR1bnQgdXQgbGFib3JlIGV0IGRvbG9yZSBtYWdu
YSBhbGlxdWEuIFV0IGVuaW0gYWQgbWluaW0gdmVuaWFtLCBxdWlzCm5vc3RydWQgZXhlcmNpdGF0
aW9uIHVsbGFtY28gbGFib3JpcyBuaXNpIHV0IGFsaXF1aXAgZXggZWEgY29tbW9kbyBjb25zZXF1
YXQuCg==
$ 
</code></pre>

- Note that this particular text did not produce a `+` or `/` in the base 64 encoding
  - But the [PEM-encoded RSA key from the encryption slide set](encryption.html#/rsapem) did

## [Base 58 encoding](https://en.bitcoin.it/wiki/Base58Check_encoding)
- Convert to a base-58 number, and map each base-58 digit to one of 58 characters
- Why?  The stated reasons:
  - Avoid using 0/O and I/l, which look similar in some fonts
    - That's zero / capital-Oscar and capital-India / lower-Lima
  - Avoid non-alphanumeric characters, which will cause line-breaks
  - Double-click will select entire string (not the case with + or /)
- Base 58 digit conversion:
  - 0 -> 1, ..., 8 -> 9 (skips 0 (zero))
  - 9 -> A, ..., 32 -> Z (skips I (India) and O (Oscar))
  - 33 -> a, ..., 57 -> z (skips l (Lima))
- Each text character represents 5.86 (!) bits: 137% increase in size

## RIPEMD-160 hash
- A 160 bit hash that is different in how it works from SHA-256, but with the same general concepts

```
$ openssl rmd160 lorem-ipsum.txt 
RIPEMD160(lorem-ipsum.txt)= 
        495822918fc2fd2cceb626b637da4cca984b39c4
$
```

## Bitcoin Address Example
Example is from [here](https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses)

<pre style="margin:0;width:100%"><code style="font-size:smaller"
>- Given an ECDSA private key:
  18e14a7b6a307f426a94f8114701e7c8e774e7f9a47e2c2035db29a206321725
- And an ECDSA public key (0x02 is y-coord, rest is x-coord)
  0250863ad64a87ae8a2fe83c1af1a8403cb53f53e486d8511dad8a04887e5b2352
- SHA-256 on the public key:
  0b7c28c9b7290c98d7438e70b3d3f7c848fbd7d1dc194ff83f4f7cc9b1378e98
- RIPEMD-160 on that: f54a5851e9372b87810a8e60cdd2e7cfd80b6e31
- Prefix that with 0x00 for a "standard" (P2PKH) address:
  00f54a5851e9372b87810a8e60cdd2e7cfd80b6e31
- Generate the checksum:
  - Perform SHA-256 twice on RIPEMD-160 result: 
    c7f18fe8fcbed6396741e58ad259b5cb16b7fd7f041904147ba1dcffabf747fd
  - Take the first 4 bytes: c7f18fe8
- Concatenate together (spaces for clarity only): 
  00 f54a5851e9372b87810a8e60cdd2e7cfd80b6e31 c7f18fe8
- Convert that (binary) hex value to base 58: 
  1PMycacnJaSqwwJqjawXBErnLsZ7RkXUAs

## Bitcoin address -> hash
- Given a Bitcoin invoice address
  - Base-58 decode it
  - Verify the correct network (first byte)
  - Verify the checksum (last 4 bytes)
- What's left is the hash of the public key
  - Formally the RIPEMD160 of the SHA256 of the public key

## Confirmations
- As the blockchain grows, it becomes harder to change transactions many blocks in the past
- Each additional block since a given transaction is a "confirmation" that the given transaction is "permanent"
  - Formally: the number of confirmations of a block is the number of successive blocks since then in the blockchain
- The more confirmations, the more confident you are that the transaction will not change
  - We'll talk later about how many confirmations, how to attack this, etc.

## Difficulty / target
- The target (and thus difficulty) is *deterministically* computed by each node
  - Based on the average time taken every 2016 blocks (2 weeks)
  - Each node computes it separately
- The `nBits` field encodes this
  - We'll see how later
</code></pre>

Overview

## Section: Preamble
Size: 8 bytes; how many: 1

- Magic number: meant to be able to easily identify the start of a block
- Technically, this is not part of the block itself, but it is before each block in the files that hold multiple blocks

## Section: Header
Size: 80 bytes; how many: 1

## Transaction Count
- A compactSize unsigned int (1-9 bytes)
- There must be at least one transaction
  - The so-called 'coinbase' transaction -- who gets the mining reward

## Section: Transaction
Size: varies; how many: txn_count

## Section: Transaction input
Size: varies; how many: txn_in_count

## Section: Coinbase input
- Always the first transaction in a block
- It's the miner who gets the reward
- Just like a regular transaction input, except...
  - The TXID hash is null (32 null (0x00) bytes)
  - Index is 0xffffffff
- A height field was added in [BIP34](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki)
  - Starting with block [227,836](https://www.blockchain.com/btc/block/227836) (March 24, 2013)
  - This created version 2 of the transaction `version` field

## Section: Transaction output
Size: varies; how many: txn_out_count

## Overview
- A Bitcoin transaction contains scripts of various opcodes and values
  - Uses a stack
  - Only 1 byte for the opcode, so a max of 256 instructions
  - This is like [IBCM](https://uva-cs.github.io/pdr/slides/07-ibcm.html#/)!
- Reference: the [Script page](https://en.bitcoin.it/wiki/Script) of the Bitcoin developer wiki

## BTC Stack
- It's like the stack we all know and love, with some differences:
  - It has *many* more operations
    - Pop 2, pop second, swap top two, etc.
  - Each value on the stack can be a different size
  - It keeps track of the *type* of each value as well

## Bitcoin Output Script
- Each TXN has a *output script*
  - Specifies the commands that are executed to verify who can spend these coins
  - The most common states that any transaction that provides a public key that matches the given signature
  - Typically involves public key *signatures*, not the public keys themselves
- This is commonly called the *pubkey script*
  - Because it often (but not always!) states the (hash of the) public key required to spend the TXN

## Bitcoin Input Script
- If a TXN's output script says one must provide a public key...
- ... then we provide it in the *input script*
- One can provide more than just the keys, though
- This is commonly called the *sig script*
  - Because it provides the signature (and public key) required by the output (pubkey) script

## How a Bitcoin TXN is verified
- To spend a UTXO:
  - Take the input script (aka sig script) from the TXN that is trying to spend the UTXO
  - Take the output script (aka pubkey script) that created the UTXO
  - Concatenate these together (sigscript before pubkey script), and execute
  - If the result of these is true, then the coins can be spent (transferred)
    - Formally, if the top value on the stack is true after execution

## Output scripts
- A typical output script will state:
  - The redeemer must provide a public key that matches the hash listed in the output script
    - Recall that a BTC address is a hashed public key
  - The redeemer must sign the entire UTXO transaction with that public key
  - Called the 'pubkey script' because it (typically) requests a public key (or hash of one)
- A typical input script will provide:
  - The public key that matches the hash in the output script
  - A signature of the entire transaction
  - Called the 'sig script' because it provides the signature of the TXN

## Input scripts
- An input script provides the data the output script needs to be valid
  - Typically that is just two data items:
- The signature of the *entire* UTXO transaction
  - Meaning the transaction that created the BTC that is trying to be spent
  - The signature is created by the private key of the Bitcoin key pair
  - This is the sender verifying that this transaction really came from the key pair's private key
- The public key of the sending Bitcoin key pair
  - The hash of this key is in the UTXO's output script
  - This will shortly be verified to match with the private key that signed the signature

## Selected Bitcoin Opcodes

| Hex value(s) | Name | Description |
|--|--|--|
| 0 | OP_0 | Push 0 (false) onto the stack |
| 81-96 | OP_1 → OP_16 | Push that number onto the stack |
| 1-75 | (push) | Push that many (following) bytes onto the stack |
| 118 = 0x76 | OP_DUP | s.push(s.top()) |
| 169 = 0xa9 | OP_HASH160 | s.push(RIPEMD160(SHA256(s.pop()))) |
| 136 = 0x88 | OP_EQUAL_ VERIFY | OP_EQUAL: s.push(s.pop()==s.pop()); OP_VERIFY: abort if s.top() is false |
| 172 = 0xac | OP_CHECKSIG | Check the sig of the *previous* TXN |

## OP_CHECKSIG
- It's a signature of the *previous* UTXO transaction, not the current one
- Pops two values off the stack: first the public key $k_{pub}$ and then the signature $s$
  - The signature $s$ was by the redeemer: the hash $h'$ of the *previous* UTXO transaction encrypted with the private key $k_{pri}$
- Hashes the *previous* UTXO transaction to get $h$
- Decrypts $s$ with $k_{pub}$ to get $h'$
- Verifies $h == h'$, and pushes result (true (1) or false (0)) onto stack
- OP_CHECKSIGVERIFY will run OP_VERIFY after
  - OP_VERIFY: abort if stack top is not true (1)

Execution of the P2PKH Script

Stack

Script

`<sig>`	←
`<pubKey>`	←
`OP_DUP`	←
`OP_HASH160`	←
`<pubKeyHash>`	←
`OP_EQUALVERIFY`	←
`OP_CHECKSIG`	←

As the top of the stack has true at the end, the script is verified and the transaction is valid

## P2PKH Execution

</div>

## P2PKH Execution

</div>
As the top of the stack has true at the end, the script is verified and the transaction is valid

## Bitcoin TXN verification
- A Bitcoin transaction is valid ONLY if ALL of the following are true:
  - The result of executing the concatenated script yields true (1) as the top value of the stack; AND
  - No opcode that marks the transaction as invalid was executed (such as OP_RETURN); AND
  - There was no abort() called by any of the script opcodes; AND
  - There were no invalid (disabled) opcodes attempted to be executed
- If any one of these are false, the TXN is invalid, and the node will not process it (or add it to a block)

## Bitcoin multiple outputs
- Lets say that Alice (A) wants to redeem a UTXO for BTC to send 1 BTC each to Bob (B), Charlie (C), and Dani (D)
  - We'll ignore fees here
- Her transaction has *three outputs*
  - Each output has a separate P2PKH output script based on the BTC addresses of B, C, and D
  - This transaction creates 3 UTXOs, indexed 0 (for B) through 2 (for D)

OP_CHECKMULTISIG Example

If the current key matches the current signature, advance both; otherwise, only advance the key index

(reference)

Initial state of the stack with indices
Does ikey match isig?
- If so, advance both indices
Back to start...
If ikey does not match isig...
- Only advance ikey
Pushes true (1) if all signatures match a public key
- One possible successful end (assuming pubKey2 matches sig1)
- Another possible successful end (assuming pubKey1 matches sig1)

## OP_CHECKMULTISIG example
![](images/bitcoin/multisig/multisig.dot.1.svg)
- To enforce some agreement, Alice (A) wants to allow Bob (B), Charlie (C) and Dani (D) to redeem a UTXO if 2 of the 3 agree
- The pubKey script from A will push onto the stack: `OP_2`, each of the public key hashes of D, C, then B, and then `OP_3`
  - The top 5 values in the diagram
  - It will then call `OP_CHECKMULTISIG`
- The sigScript that B, C, and D jointly provide must then first push onto the stack `OP_0` and two signatures
  - The bottom 3 values in the diagram
- The entire script will be longer (have an `OP_CHECKSIG`, for example); this is just showing the use of `OP_CHECKMULTISIG`

## Full List of Opcodes
See the [Script page](https://en.bitcoin.it/wiki/Script) of the Bitcoin developer wiki

## Obsolete P2PK transaction
- P2PK; Pay to Public Key
  - From when Bitcoin started in 2009
- Input script: `<sig>`
  - The signature of the TXN with a given public key
- Output script from the UTXO: `<pubKey> OP_CHECKSIG`
- Combined script (with separator):

```
<sig>
--------
<pubKey>
OP_CHECKSIG
```

- Problem: the public key needs to be known (and displayed) in advance!

## Problems with P2PK transactions
- This is the public key version, not the hash of the public key version
- The public key needs to be known (and displayed) in advance
  - One could (theoretically) determine the private key with a quantum computer and spend the UTXO
  - But you can't determine the keys from the hash of the keys
- Public keys are longer
  - A secp256k1 ECDSA public key is 512 bits = 64 bytes
  - RIPE-160 Hashes of public keys are shorter
    - 160 bits == 20 bytes

<aside data-markdown class="notes">
- If both x and y are being encoded in the ECDSA public key, then -- at 32 bytes each -- it's 65 bytes (1 byte for the format)
- If only x is being encoded, then it's 33 bytes (1 byte for the format)
- A RIPE-160 hash is 160 bits
</aside>

## Pay to Script Hash (P2SH)
- From [BIP 0016](https://en.bitcoin.it/wiki/BIP_0016) from 2012 (here is [another reference](https://en.bitcoin.it/wiki/Pay_to_script_hash))
- The third of the "standard" transactions
  - Along w/P2PK & P2PKH
- Instead of requiring a hash of the public key, you require a hash of the *sigScript*
  - Rephrased: The redeemer must provide a script that matches the hash, not just a key that matches the hash
- Why?
  - Perhaps you want a specific way to redeem it
  - Or the redeeming sigScript is known ahead of time and very involved
- If the private key becomes known, the TXN can't be as easily redeemed (necessarily)

## P2SH: Simple version:
- pubKey script:
```
OP_HASH160 <pubKeyHash> OP_EQUAL
```
- sigScript: `<sig>`
- Combined scripts:

```
<sig>
--------
OP_HASH160
<expectedScriptHash>
OP_EQUAL
```
- This is a *special form*
  - When miners and nodes see that *exact* pubKey script, they know that the `OP_HASH160` is for the *entire* sigscript, not just the top value

## P2SH: Complicated version
- pubKey script:
```
OP_HASH160 <pubKeyHash> OP_EQUAL
```
- sigScript is much more complicated:
  - Can require that it's redeemed by multiple signatures
  - Or via a custom script you wrote that you distribute
  - Or when other conditions are met
- Combined scripts:

```
<sig>
... many more opcodes in this script
--------
OP_HASH160
<expectedScriptHash>
OP_EQUAL
```

## Determining nonces
- The `nonce` is a 32-bit field
  - Total of $2^{32} \approx 4.3$ billion $=4.3 \ast 10^9$ possibilities
- But Bitcoin currently needs about 200 EH/s $=200 \ast 10^{18}$ H/s
  - In 10 minutes, that's $1.2 \ast 10^{23}$ H/s for a block
- So other things have to change other than the nonce:
  - Transaction order: given 2,000 transactions in a block, that's about $2000! \approx 3.3 \ast 10^{5735}$ possible orderings
  - Transaction input or output ordering
    - This modifies the transaction itself!
      - And thus the transaction hash
    - But does not *invalidate* the transaction

## Transaction Malleability
- Problem: a small change to non-important part of the TXN changes the TXN hash
  - Example: transaction input order or output order
- Some of these things might change as a transaction is mined into a block
  - Then the transaction hash changes!
  - This doesn't happen often, but it can occur
- These changeable fields are *malleable*
- This was used in an [attack in 2015](https://cointelegraph.com/news/the-ongoing-bitcoin-malleability-attack)
  - If you change the malleable data, it creates a different transaction hash, and then that can be resubmitted and (possibly) double-spent

## Witness structure

<table class='transparent'>
  <tr>
    <td>
      <img src="images/bitcoin/blocks/blocks.dot.3.svg" style="border-radius:10px;margin-top:0;margin-bottom:0;width:80%">
    </td>
    <td style="vertical-align: middle;">
      <p style="text-align: center;">... becomes ...<br> <br> <br> <br>(new parts<br>are colored<br>differently)<br> <br> <br> </p>
    </td>
    <td>
      <img src="images/bitcoin/blocks/blocks.dot.6.svg" style="border-radius:10px;margin-top:0;width:80%">
    </td>
  </tr>
</table>

## Witness structure
- Current TX hash (aka *txid*) is:
```
sha256(sha256(<version><txins><txouts><locktime>))
```
  - (assume that tx_in_cout & tx_out_out are in txins / txouts)
- Transaction *witness hash* (aka *wtxid*) is:
```
sha256(sha256(<version><marker><flag><txins><txouts>
                <witness><locktime>))
```
  - marker: 1 byte, always 0x00
  - flag: 1 byte, always 0x01
  - witness: more on that next
- Each transaction now has two hash IDs!

## The Witness
- A witness is not a script, but only data to push onto the stack
- Witness format:
  - count: compactSize unsigned int indicating how many data items
  - for each i in count:
    - compactSize unsigned int containing the size of the data
    - that many data bytes
- Validation:
  - Witness data is pushed onto the stack
  - There may or may not be a sigScript
  - The pubKey script then validates, using the data from the witness

## Witness Benefits
- Even if the TX hash changes, the witness hash does not
  - Miners / nodes do not recompute the witness hash
- If there are many UTXOs being spent...
  - ... and all are P2PKH transactions ...
  - ... then the witness data applies to *each* one
  - This means each transaction input does not have to list the signature and key separately
  - This increases the transaction per block by a factor of about 2
    - And decreased transaction times

## Witnesses
- The hashes of the witnesses of the transactions are kept in a Merkle tree
- If a transaction's hash changes, the witness hash will stay the same
  - Thus, we can prevent this type of double spending attack
- Consider [this Bitcoin transaction from August 2021](https://www.blockchain.com/btc/tx/218f1f03781366e932524007a436024cf9d80ca1681a2ee110636d797ee2959b)
  - That was for 11,325 BTC, worth `$`430 million at the time
  - That has a witness field listed

## Witness transactions
- This led to...
  - P2WPKH: Pay to Witness Public Key Hash
    - Like P2PKH, but the signature and public key hash are taken from the witness
  - P2WSH: Pay to Witness Script Hash
    - Like P2SH, but the script hash is taken from the witness
- The change to include witnesses also increased the block size
  - Which decreased transaction times

## Bitcoin block size
- A bitcoin block can only be 4 Kb in size
  - But how many transactions is that?
- A Bitcoin block can also only have 20,000 signature operations (sigops) per block
  - OP_CHECKMULTISIG [uses 20](https://en.bitcoin.it/wiki/OP_CHECKMULTISIG)
- The witness changes allow 4 million weight units (WU) per block
  - Pre-segwit bytes weigh 4 WU (max of 1 Mb block size)
  - Segwit witness data bytes weigh 1 WU each (max of 4 Mb)
    - But there is typically data other than witness data in the block...
- Theoretical limit of 4 Mb block size (if all witness TXNs)
  - Typically between 1,500 and 2,000 TXNs per block
    - See the latest block [here](https://bitcoinblockexplorers.com/blocks)

## Problems with P2PKH transactions
- Back to the hash of the public key version
- Problem: once redeemed, the public key for the UTXO is thus known
  - This could also be cracked using a quantum computer
- Solution: if you want to keep funds in the UTXO, transfer that to a new address key pair
  - Again, only specified with the address (hash)

## Bitcoin transaction types
- Ones we've seen in detail
  - P2PK (pay to public key)
  - P2SH (pay to script hash)
  - P2PKH (pay to public key hash)
- Witness transaction types
  - P2WPKH: (pay to witness public key hash)
  - P2WSH: (pay to witness script hash)
- Others we haven't seen
  - [P2MS](https://learnmeabitcoin.com/technical/p2ms): Pay to multi-sig
- And, of course, custom scripts

## Transaction Puzzle
Output script of [this transaction](https://www.blockchain.com/btc/tx/a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31b) from 12/12/2012:
```
OP_HASH256
6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000
OP_EQUAL
```
- Input script must provide data that, when hashed with SHA256, equals the provided hash
- Redeemed the next day by [this transaction](https://www.blockchain.com/btc/tx/09f691b2263260e71f363d1db51ff3100d285956a40cc0e4f8c8c2c4a80559b1)
  - The data was the [Genesis block](https://en.bitcoin.it/wiki/Genesis_block)

## Finding SHA1 hash collisions
Output script from 2013:
```
OP_2DUP OP_EQUAL OP_NOT  OP_VERIFY 
OP_SHA1 OP_SWAP  OP_SHA1 OP_EQUAL
```
- Required input script: `<data1> <data2>`
- New opcodes:
  - `OP_2DUP`: duplicate top two items on the stack
  - `OP_EQUAL`: `s.push(s.top() == s.top())`
  - `OP_NOT`: If the input is 0 or 1, push the negation; else push 0
  - `OP_VERIFY`: abort if s.top() is false
  - `OP_SHA1`: `s.push(SHA1(s.pop()))`
  - `OP_SWAP`: swap top two items on the stack
- Redeemed in 2017 for 2.48 BTC

## Is Bitcoin Script Turing-complete?

<ul>
  <li class='fragment'>What would be required to make it Turing-complete?</li>
</ul>

## Motivation
- Alice has $w$ BTC to send to Bob
  - In exchange, Bob will send $v$ AltCoins to Alice
- How to do this?
  - Since AltCoin != BTC, they are on different blockchains

- Method 1: Central authority
  - Alice and Bob send to *bank*, and *bank* swaps them and sends back to Bob & Alice
  - Problem: no central authority in decentralized finance
  - Problem: can *bank* be trusted?

## Motivation
- Alice has $w$ BTC to send to Bob
  - In exchange, Bob will send $v$ AltCoins to Alice
- How to do this?
  - Since AltCoin != BTC, they are on different blockchains

- Method 2: Trust the other party
  - Alice sends BTC to Bob
  - Upon receipt, Bob sends AltCoins to Alice
  - Problem: what if Bob doesn't send them back and keeps both the BTC and AltCoins?

## Motivation
- Alice has $w$ BTC to send to Bob
  - In exchange, Bob will send $v$ AltCoins to Alice
- How to do this?
  - Since AltCoin != BTC, they are on different blockchains

- Method 3: Cross-chain Atomic Swap
  - Ensure that *either* the entire transaction completes OR it is fully reversible and refundable
  - [Reference](https://en.bitcoin.it/wiki/Atomic_swap)

## Cross-chain Atomic Swap
1. Alice creates TXN1 (payment) & B-signed TXN2 (refund)
2. Alice submits TXN1 to the network
3. Bob creates TXN3 (payment) & A-signed TXN4 (refund)
4. Bob submits TXN3 to the network
5. Alice spends TXN3, revealing $x$
6. Bob, now knowing $x$, spends TXN1 using $x$

Reversibility: Before (2), nothing has been broadcasted, so nothing happens

Reversibility: Between (2) & (4): if Bob doesn't proceed, then he submits nothing to the network, and Alice can use refund TXN2 to get her coins back

Reversibility: Between (4) & (5): If Alice doesn't proceed, Bob can get a refund in 24 hours; Alice has 24 more hours (48 total) to get her refund

Reversibility: After (5): 
   - Bob must redeem his new BTC within 24-48 hours or Alice can claim the refund and get her BTC back

Either side submitting a refund TXN early: the refund TXNs are time-locked, so the other party has time to submit their own refund TXN