Hash Power Slides Protocol Layer 01
Hash Power
The Cryptographic Foundation of Data Integrity
Version 1.0.4
Foundations of Trust
What is a Cryptographic Hash?
Deterministic
The same input always produces the exact same output.
Efficient
Fast to calculate for any given input size.
One-Way
Infeasible to reverse the function to find the input.
Input: "Genesis"
811b7b134812a2...
Input: "genesis"
65f4d8523c9a11...
Small change = Radical output change
Collision Resistance
"It is computationally infeasible to find two different inputs that hash to the same output."
\( 2^{256} \)
The total output space of SHA-256. More than the number of atoms in the visible universe.
Birthday Paradox
Why brute-forcing collisions is easier than finding a specific pre-image, but still impossible for SHA-256.
Avalanche Effect
Changing one bit in the input should change at least half of the bits in the output.
Inside SHA-256
Merkle–Damgård construction
SHA-256 processes data in 512-bit blocks through a compression function repeated 64 times (rounds).
Padding to 512-bit multiples
Logical operations (AND, OR, XOR, ROT)
Fixed constant addition
Message
Round 1
...
Round 64
256-bit
The "Glue" of the Ledger
Block IDs
The hash of the header serves as the globally unique identifier for that block.
Chaining
Each block contains the hash of the previous block, creating an immutable back-link.
Mining (PoW)
Finding a hash with specific properties (prefix zeros) proves computational work spent.
Lab: Fingerprinting
"Security is not a product, but a process." - Bruce Schneier. We will now move to the lab to attempt to create a collision manually (spoiler: you can't).
01
Theory
02
Lab Work
03
Validation
Fingerprint Lab Worksheet Fingerprint Lab
CS-602: Cryptographic Primitives & Ledger Structures
Name: __________________________________
Date: ___________________________________
Objective
In this lab, you will analyze the behavior of the SHA-256 cryptographic hash function. You will explore the Avalanche Effect , demonstrate Pre-image Resistance , and calculate the mathematical probability of a random collision.
Part 1: The Avalanche Effect
Use a SHA-256 tool (terminal command echo -n "text" | shasum -a 256 or a Python script) to generate hashes for the following inputs. Record the full hexadecimal digest.
Input A: "Blockchain is the future."
Input B: "blockchain is the future." (lowercase 'b')
Analysis Task:
Compare the two digests above. How many hex characters are identical in the same position? What percentage of the total digest changed?
Part 2: Pre-image Resistance Challenge
Below is a SHA-256 digest. Your task is to find the original input. The input is a 4-digit numeric string (e.g., "0421").
9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
Your Approach:
Briefly describe the script or method you would use to "reverse" this hash.
The Solution:
Input found:
How many attempts did it take (roughly)?
Part 3: Mathematical Analysis
Calculate the theoretical limits of SHA-256. Show your reasoning or the formula used.
1. If you can perform \( 10^{15} \) hashes per second, how many years would it take to guarantee a collision by brute-forcing a specific 256-bit hash (Pre-image attack)?
2. Why is a "Birthday Attack" significantly more dangerous than a standard pre-image attack, and how does it change the required search space for SHA-256?
PROPERTY OF CYBERNETIC LEDGER LABS
MODULE 01: DATA INTEGRITY
Integrity Manual Teacher Guide Instructional Resource
Integrity Manual
Facilitator's Guide for Lesson 01: Hash Functions
Topic Focus
SHA-256 Analysis
Lesson Overview
This lesson moves graduate students from the conceptual "black box" understanding of hashing to a rigorous analysis of its properties. The goal is to establish mathematical trust in the ledger's immutability. Students should leave understanding exactly why a blockchain is difficult to tamper with, rather than just knowing that it is.
Key Technical Takeaways
Avalanche Effect: Minimal input changes yield non-correlated output changes.Pre-image Resistance: The computational cost of \( 2^{256} \) makes reversal impossible.Data Binding: How hashes serve as "commitments" to specific data states.
Common Pitfalls
"Confusing a hash with encryption (hashing is not reversible)."
"Underestimating the scale of \( 2^{256} \) (students often think a supercomputer could solve it)."
"Ignoring the null character or newline handling in different programming languages."
Fingerprint Lab: Answer Key
Part 1: The Avalanche Effect
Input A: 811b7b134812a2... (Full: 811b7b134812a297e704172449767f33d71221f421f158586047ef0398642a8b)
Input B: 65f4d8523c9a11... (Full: 65f4d8523c9a11e1f822896587c6767571618779907106721067167167167107)
Note: Students should observe that no hex characters are in the same position and roughly 100% of the bits (50% on average statistically) have flipped.
Part 2: Pre-image Resistance
Target Hash: 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08
Solution: "test"
Instructor Tip: If students find "test" too quickly, have them try to find a hash that starts with four zeros "0000...". This simulates the Proof of Work difficulty.
Part 3: Mathematical Analysis
Pre-image brute force: \( 2^{256} \) operations. At \( 10^{15} \) hashes/sec, it takes approx \( 3.6 \times 10^{54} \) years. (Effectively infinite).Birthday Attack: The search space drops to \( 2^{128} \) (square root of the total space) to find any two inputs that collide. Still \( \approx 10^{23} \) years at current speeds.
Facilitation Notes
Socratic Questions
Signature Logic Slides Protocol Layer 02
Signature Logic
Elliptic Curves and Digital Authorization
Version 1.1.0
Identity & Ownership
The Key Pair Principle
Private Key
A 256-bit random number. The absolute secret. Losing this means losing control of all associated assets.
Public Key
Derived from the private key via a trapdoor function (ECC). Shared globally as an "address."
Mathematical Trapdoor
PrivKey \(\rightarrow\) PubKey
PubKey \(\not\rightarrow\) PrivKey
The "One-Way" property of Elliptic Curve multiplication.
Why secp256k1?
Efficiency
Smaller key sizes (256-bit) provide security equivalent to much larger RSA keys (3072-bit).
Scalar Mult
Based on the algebraic structure of elliptic curves over finite fields. \( Q = kG \)
Proven Strength
Specifically chosen for Bitcoin/Ethereum for its non-backdoored, Koblitz curve properties.
\( y^2 = x^3 + 7 \pmod p \)
The ECDSA Workflow
Phase 1: Signing
1. Hash the message (Transaction Data).
2. Select a random number \( k \) (nonce).
3. Calculate a point on the curve.
4. Produce the signature pair: (r, s) .
Phase 2: Verifying
The verifier needs:
The Original Message
The Signature (r, s)
The Public Key
Result: Boolean (Valid/Invalid)
Critical Failure Points
Nonce Reuse
If the same random value \( k \) is used to sign two different messages, the private key can be mathematically extracted.
\( d = (s_1 z_2 - s_2 z_1) / (r (s_2 - s_1)) \pmod n \)
Private Key Exposed
Lab: Identity Forgery?
"Math doesn't care about your password." We will now implement key generation and signature verification in the lab.
Generate Keys
Sign Message
Verify Truth
Keypair Lab Worksheet Keypair Lab
CS-602: Cryptographic Primitives & Ledger Structures
Name: __________________________________
Date: ___________________________________
The Mathematics of Authorization
The secp256k1 curve used in Bitcoin is defined by \( y^2 = x^3 + 7 \) over the finite field \( \mathbb{F}_p \). In this lab, you will generate a private key, derive a public key, and verify a digital signature using the Elliptic Curve Digital Signature Algorithm (ECDSA).
Part 1: Generating the Secret
Generate a random 256-bit number. In practice, this should be generated by a cryptographically secure pseudo-random number generator (CSPRNG).
Private Key (Hexadecimal):
Compressed Public Key (Hexadecimal):
Remember: This is a coordinate (x, y) on the curve, often compressed to just X plus a parity bit.
Check Your Understanding:
If you add the generator point \( G \) to itself \( k \) times (where \( k \) is your private key), what resulting point do you obtain? Explain why calculating \( k \) given the resulting point is computationally difficult.
Part 2: The Signature Handshake
Using a Python library (like ecdsa or cryptography), sign the message "TRANSFER 1.0 BTC TO ALICE".
Signature component (r):
Signature component (s):
Warning: If you sign the exact same message twice, will (r, s) be the same? Why or why not?
The Verification Challenge
I provide you with a Public Key and a Signature. Prove that the signature is invalid for the message "TRANSFER 1.0 BTC TO EVE".
PubKey: 0283bdec84b39e65839b2a7...
r: 5a8e...
s: 21c4...
z: (hash)
Logic for Rejection:
Part 3: Final Synthesis
If Alice wants to send a transaction but her private key is stored on an offline "Hardware Wallet," how does the signature reach the blockchain without the private key ever touching the internet?
PROPERTY OF CYBERNETIC LEDGER LABS
MODULE 02: IDENTITY & AUTHORIZATION
ECC Theory Teacher Guide Technical Facilitator's Guide
ECC Theory Manual
Instructional Support for Lesson 02: Public Keys & Signatures
Mathematical Focus
secp256k1 & ECDSA
Concepts for Deep Dive
In this module, students transition from general asymmetric crypto (like RSA) to Elliptic Curve Cryptography (ECC) . The primary pedagogical challenge is the abstraction of "addition" and "multiplication" on a curve. Guide them to see that these are algebraic operations on a group, not simple arithmetic.
Crucial Proof Points
Discrete Log Problem: Explain why given \( Q = kG \), finding \( k \) is hard. This is the "Trapdoor."Deterministic Signatures: Mention RFC 6979. It solves the nonce reuse problem by deriving \( k \) from the message and the private key.Key Compression: Explain that since the curve is symmetric about the x-axis, storing X and the parity of Y is enough to recover the point.
Student Obstacles
"Why not RSA?"
"The Nonce Problem"
Keypair Lab: Solution Guide
Part 1: Key Generation
Answer: Adding \( G \) to itself \( k \) times yields the Public Key point \( Q \) .
The difficulty lies in the fact that point addition does not follow a linear path on the graph; it "jumps" across the curve, making it impossible to "divide" back to find \( k \).
Part 2: The Signature Handshake
Warning Answer: No, (r, s) will be different every time if a random nonce \( k \) is used. This is why the same transaction signed twice looks like two different data blobs.
Verification Failure Logic:
The signature was generated using a hash of Message A. When the verifier hashes Message B, the internal math \( s^{-1}(z + re)G \) will point to a location on the curve that does not match the public key. The point verification fails.
Discussion Topic: Quantum
ECDSA is not post-quantum secure. Shor’s algorithm can solve the elliptic curve discrete logarithm problem in polynomial time. Ask students: "If a quantum computer were built today, how would you migrate the entire blockchain to a new signature scheme?"
Tree Verification Slides Protocol Layer 03
Tree Verification
Efficient State & Membership Proofs
Version 2.0.1
Distributed Data Structures
What is a Merkle Tree?
The Binary Hash Tree
A data structure where every leaf node is the hash of a data block, and every non-leaf node is the hash of its children.
Integrity
Changing one byte in one transaction changes the entire Root Hash.
Efficiency
Verify a single transaction without downloading the whole tree.
ROOT
HASH(A+B)
HASH(C+D)
H(A)
H(B)
H(C)
H(D)
O(log n) Verification Path
The Power of log(n)
Scalability Comparison
To prove a transaction exists in a block of 1,000,000 transactions:
Linear Scan
1,000,000 items to download/verify.
Merkle Proof
Only 20 hashes to download/verify.
Proof for Leaf A
Need: H(B), H(CD), H(EFGH)...
\( \approx 1024 \text{ bytes} \)
Total size for 1M transaction proof
State Management: Patricia Tries
While Bitcoin uses Merkle Trees for Transactions , Ethereum uses Merkle Patricia Tries (MPT) for State (Account Balances).
Prefix-based: Common paths are shared.Deterministic: The same set of (key, value) pairs always results in the same root, regardless of insertion order.Efficient Updates: Only logarithmic changes for inserts/deletes.
Node Types in MPT
Extension Node: Shared key prefix
Branch Node: 16 hex children + value
Leaf Node: Unique key suffix + value
Root Hash = Digest of the top node
SPV & Light Clients
Light Client
Headers Only (80 bytes)
Full Node
Whole History (TB+)
Simplified Payment Verification (SPV) allows the phone to ask:
Lab: Building the Tree
You will now implement a binary Merkle Tree in Python. Can you generate a proof for the 3rd transaction that the root hash accepts?
Hash(Left + Right)
Merkle Root Worksheet Merkle Root Lab
CS-602: Cryptographic Primitives & Ledger Structures
Name: __________________________________
Date: ___________________________________
The Anatomy of a Commitment
A Merkle Tree allows for the commitment of a large dataset into a single 32-byte hash (the root). In this lab, you will manually compute a tree and then implement the get_proof() and verify_proof() functions.
Part 1: Manual Hashing
Given the following four transaction hashes (first 8 hex chars), calculate the intermediate hashes and the Merkle Root. Use the rule: Intermediate = Hash(Left + Right).
Root: ________________
Hash(TX1 + TX2)
Hash(TX3 + TX4)
TX1: 8a3f2b1d
TX2: f9e2c4a0
TX3: d5b1e8a7
TX4: c2a9d3b4
Part 2: The Audit Path
To prove that TX1 is in the tree, what specific hashes must the server provide to the client? List them in the order they would be hashed.
Implementation Sketch (Python)
Logic for Odd Leaf Counts:
If a block contains an odd number of transactions (e.g., TX1, TX2, TX3), how does Bitcoin handle the "lonely" leaf at the end of a level? What is the potential vulnerability if this is handled incorrectly (look up CVE-2012-2459)?
Part 3: Tries vs Trees
Property Binary Merkle Tree (Bitcoin) Merkle Patricia Trie (Ethereum) Primary Use Case ________________________ ________________________ Node Order Dependency ________________________ ________________________ Verification Efficiency ________________________ ________________________
Synthesis Question:
Why is it essential that the State Trie be deterministic ? What would happen if two nodes inserted the same accounts in a different order and arrived at different Root Hashes?
PROPERTY OF CYBERNETIC LEDGER LABS
MODULE 03: DISTRIBUTED DATA STRUCTURES
State Tries Teacher Guide Technical Facilitator's Guide
State Tries Manual
Instructional Support for Lesson 03: Merkle Trees & Tries
Complexity Level
High: State Serialization
Pedagogical Context
In this lesson, we pivot from stateless primitives (hashes, signatures) to stateful data structures. The challenge is explaining why "ordering" matters in a distributed system. A Merkle Tree provides a snapshot of events (transactions), while a Patricia Trie provides a snapshot of status (balances).
Key Differentiators
Merkle Trees: Insertion order dependent. If TX1 and TX2 swap places, the Root Hash changes.Patricia Tries: Key-value based. The structure is determined by the keys, making it order-independent (deterministic).Proof Verification: Emphasize that the client only needs the "Audit Path" + Root Header, not the whole tree.
Critical Bug: CVE-2012-2459
In early Bitcoin implementations, odd leaf counts were handled by duplicating the last hash. This allowed an attacker to create a second, different list of transactions that resulted in the same Merkle Root. This is a "collision" caused by poor structure design.
Merkle Root Lab: Solution Key
Part 1: Calculations
H12 = Hash(8a3f2b1d + f9e2c4a0)
H34 = Hash(d5b1e8a7 + c2a9d3b4)
Root = Hash(H12 + H34)
Note: Root value depends on the hashing library/padding used. Focus on the process.
Part 2: The Audit Path
To prove TX1 , the client needs:
TX2 (The sibling of TX1)H34 (The sibling of H12)
Computation: Hash(Hash(TX1 + TX2) + H34) == Root
Light Client Mechanics
SPV (Simplified Payment Verification) is the reason crypto works on phones. Without Merkle Proofs, a mobile wallet would need to download 500GB+ of data.
Challenge: How do light clients know which headers to trust? (Pre-lesson for Lesson 4)
Eth-State vs Bit-State
Ethereum's state trie stores not just balances, but contract storage and nonces . This allows the network to prove "account X had exactly Y balance at block Z" without replaying the whole chain.
Chain Building Slides System Synthesis
Chain Building
Architecture, Linking, and Immutability
Module 04
Data Synthesis
The Block Header
The header is the "ID card" of the block. It contains all the necessary metadata to link the block into the chain.
Version 4 bytes
Prev Block Hash 32 bytes
Merkle Root 32 bytes
Timestamp 4 bytes
Difficulty/Nonce 8 bytes
Header Hash
00000000000000000003b5...
The Prev Block Hash is the cryptographic link that makes the chain immutable.
The Immutable Chain
BLOCK 101
ID: ABC
BLOCK 102
Prev Hash
ABC
Data...
BLOCK 103
If Block 101 is changed, its Hash changes.Prev Hash no longer matches.
Chain Validation Logic
// Validation Algorithm
for block in chain:
1. Re-calculate Merkle Root
2. Validate Block Hash < Difficulty
3. Check: block.prev == prev_block.hash
4. Validate timestamps (monotonic)
return True
The Genesis Block
The only block with no predecessor. Its prev_hash is typically 00...00.
Computational Cost
Validating the chain is \( O(n) \). Why is this sustainable for a global network?
Lab: The Chain Forge
We are synthesizing everything. You will create a Block class and a Blockchain class. Can you detect a single bit change in block 2?
Objects
Linking
Validation
Block Architecture Worksheet Chain Forge Lab
CS-602: Cryptographic Primitives & Ledger Structures
Name: __________________________________
Date: ___________________________________
The Immutable Skeleton
You are now the architect. You must define a Block Header that is compact yet contains enough cryptographic commitment to ensure the entire history of the ledger is tamper-evident.
Part 1: Header Specification
Define the fields for your block header. Consider the byte-size and the purpose of each field.
Field Name Data Type Size (Bytes) Description / Role Previous Hash ________________ 32 Commitment to the previous block. Merkle Root ________________ 32 Commitment to the transactions. Timestamp ________________ ___ Nonce ________________ ___ TOTAL HEADER SIZE: ______
Part 2: Validation Algorithm
Write the pseudocode for a function is_chain_valid(chain). It should return True only if every block is correctly linked and the data is consistent.
Part 3: Tamper Simulation
Attack Vector
Suppose an attacker changes a single bit in Block #4 's Merkle Root to redirect a payment to their address. Explain exactly how this affects Block #5 , Block #6 , and the final validation check.
Architectural Challenge
Why do we hash only the header and not the entire block (including all raw transaction data)? What are the performance and scalability implications of hashing 1MB vs 80 bytes for every mining/validation operation?
PROPERTY OF CYBERNETIC LEDGER LABS
MODULE 04: SYSTEM SYNTHESIS
Chain Integrity Teacher Guide Engineering Facilitator's Guide
Chain Integrity Manual
Instructional Support for Lesson 04: Block Architecture
Implementation Focus
Synthesis & Linking
Synthesis Framework
This lesson is the climax of the cryptographic foundations section. Students are now moving from isolated primitives to a coupled system . The primary objective is to demonstrate that the ledger's security is emergent: it comes from the way the data is structured, not just the hashes themselves.
Key Project Milestones
Header Serialization: Ensuring the header is converted to a byte-string consistently before hashing. (Watch for endianness!)The Prev-Hash Link: Correctly assigning new_block.prev = chain[-1].hash.The Validation Loop: Iterating through the chain and re-verifying every cryptographic proof.
Instructor Tip: Monotonicity
Remind students that timestamps are not just for display. In a decentralized system, they must be monotonic (increasing). A block with a timestamp earlier than its predecessor should be rejected. This prevents certain "time-warp" attacks.
Lab Guide: Solution Discussion
Part 1: Header Spec
Bitcoin headers are exactly 80 bytes . A common student mistake is to include the full transaction list in the header. Emphasize that the Merkle Root is the proxy for the data.
Part 2: Validation Pseudocode
for i from 1 to chain.length - 1:
curr = chain[i]
prev = chain[i-1]
if curr.prev_hash != hash(prev.header): return False
if curr.merkle_root != calculate_merkle(curr.data): return False
if hash(curr.header) does not meet difficulty: return False
Facilitation Notes
Discussion Prompts
"What happens to the chain if we delete the Genesis block?"
"Can we have two valid blocks at the same height? (Introduce the concept of a fork)."
"Why do we need the Nonce? If we didn't have it, and the data didn't change, would the hash ever change?"
Synthesis Observation
"The chain is a chronological record where every block commits to the state of the one before it. It is not just a database; it is a graph of dependencies . To change one record is to attempt to rewrite the entire graph."
State Machine Slides Protocol Layer 05
State Machines
Double-Spending & The UTXO Model
Module 05
Transaction Logic
The Double-Spend Problem
Digital data is infinitely reproducible. If digital "cash" is just a file, how do we prevent Alice from sending the same file to both Bob and Charlie?
The Challenge
"In a decentralized network, there is no central authority to check the balance. How do we reach consensus on which transaction happened first?"
1
Ordering: Blocks establish a linear time-sequence.
2
Verification: Nodes check every transaction against the current state.
3
Immutability: Once confirmed, a spend cannot be undone.
UTXO vs. Account Model
UTXO (Bitcoin)
"Unspent Transaction Output"
Balance is the sum of unspent "coins."
Transactions consume inputs and create outputs.
Highly parallelizable; stateless.
Account (Ethereum)
"Balance-based Ledger"
Balance is a single number in a database.
Transactions decrement Alice and increment Bob.
Easier for complex smart contracts.
The UTXO Lifecycle
TX_0: OUT 0
Unspent
TX_1
INPUT
Spending
NEW UTXO (Bob)
NEW UTXO (Alice Change)
"Total Inputs = Total Outputs + Fees"
Enforcing the Rules
Existence Check
The input UTXO must exist in the current UTXO Set (database of all unspent outputs).
Authorization
The spender must provide a digital signature that matches the Public Key script in the output.
Solvency
The total value of new outputs must not exceed the total value of consumed inputs.
Lab: The Ledger's Final Test
You will now implement a UTXOSet class. Your mission: reject a transaction that tries to spend a "coin" that has already been used in a previous block.
Build. Secure. Deploy.
UTXO Logic Worksheet UTXO Logic Lab
CS-602: Cryptographic Primitives & Ledger Structures
Name: __________________________________
Date: ___________________________________
The Finite State Machine
A blockchain is a shared state machine. Each block contains State Transitions (Transactions). In this lab, you will manage a UTXO Set and write the logic to validate transactions against it.
Part 1: The Transaction Schema
Define a Transaction object. It must reference specific Inputs (previous transaction ID + output index) and define new Outputs (amount + public key script).
// Object Structure Design
class Transaction:
inputs = [
# List the required data fields for a secure input:
]
outputs = [
# List the required data fields for a new output:
]
Part 2: Managing the Global Set
Describe the process for updating the UTXOSet when a new block is added to the chain.
Step 1: Verification
How do you check if the inputs are valid against the current set?
Step 2: Consumption
What happens to the input UTXOs after the transaction is processed?
Step 3: Creation
Where do the new outputs go?
Part 3: Conflict Resolution
Scenario: The Race Condition
Alice has 10 BTC (one UTXO). She broadcasts two transactions at the exact same time:TX_A: Alice sends 10 BTC to Bob.TX_B: Alice sends 10 BTC to Charlie.
1. If a node receives TX_A first, what is the status of TX_B when it arrives a second later?
2. What role does the "Block Height" or "Block Timestamp" play in resolving this if both transactions are picked up by different miners at the same time?
Part 4: Final System Architecture
Why is the UTXO model considered "stateless" compared to the Account model? (Hint: Think about what data you need to verify a single transaction in isolation).
PROPERTY OF CYBERNETIC LEDGER LABS
MODULE 05: TRANSACTION LOGIC & STATE
Double Spend Teacher Guide Technical Facilitator's Guide
Double Spend Manual
Instructional Support for Lesson 05: State Transitions
System Logic
Solvency & Consensus
State Transition Framework
In the final lesson, students move from "How is it built?" to "How does it function safely?". The Double-Spending Problem is the reason blockchain exists. Guide students to realize that the *ledger* isn't just a list; it is a validated path through possible state transitions.
Crucial Concepts
The UTXO Set: Emphasize that nodes don't search the whole chain to find a balance; they maintain a cache of unspent outputs.Solvency Check: Input_Value >= Output_Value. The difference is the implicit miner fee.Atomic Operations: A transaction must be fully valid or fully rejected. No partial spending.
Common Misconception
"Students often think of 'sending coins' as a balance transfer between accounts. Clarify that in Bitcoin, you are actually destroying old outputs and creating new ones. It is more like melting down a gold coin and minting two smaller ones."
UTXO Lab: Facilitation Key
Part 1: Transaction Schema
Inputs must contain: Prev_TX_ID and Output_Index (vout). This unique pair allows the node to look up the specific "coin" in the UTXO set.
Outputs must contain: Value and PubKeyScript (The locking script that defines the new owner).
Part 3: Conflict Resolution
Resolution Logic: The miner decides which transaction enters a block. Once a transaction is in a valid block, its inputs are marked as "spent" in the global UTXO set. Any subsequent transaction using the same inputs is rejected as invalid.
Sequence Synthesis Discussion
"We started with a single comma (Lesson 1: Hashing) and ended with global financial consensus. If you were to add one thing to our local blockchain to make it a real-world competitor, what would it be?"
Network
P2P Propagation
Consensus
Proof of Stake/Work
Governance
Hard Forks/Soft Forks
